Solution Architecture and Enterprise Delivery

This page teaches the architect's side of the Claude certifications once: how to run discovery, choose the surface Claude runs on, design retrieval, integrate with enterprise systems and plan platforms and capacity, followed by cost modeling, program-level evaluation, governance, stakeholder work and the Claude Code rollout. It is the core reference for the Claude Certified Architect, Professional (CCAR-P) exam, whose guide describes practitioners who "select appropriate models, architectures, and API patterns; apply prompt and context engineering; integrate Claude into enterprise systems; and incorporate evaluation, security, compliance, and governance considerations into their designs" (CCAR-P exam guide). Product facts are as of September 2026; where the documentation has moved since the July 2026 exam guides, a section shows both versions and which wording to expect on the exam (the guide's).

Discovery and requirements

Tested in: CCAR-P 1.1 (translate business problems into Claude-based solutions), 6.1 (structured discovery and requirement gathering), 6.5 (lifecycle phases, starting with discovery) · CCDV-F 2.1 Understanding Requirements · CCAO-F D4.1 (analyze requirements and use cases)

Discovery turns an ambiguous request into requirements that a design can be traced back to. The official CCAR-P prep course states the skill in one sentence: "Translate an ambiguous business problem into a scoped Claude solution, selecting the reference architecture, model, context strategy, and entry point that keep it accurate and cost-conscious" (CCAR-P prep course). Its stakeholder module adds the discipline that makes the result defensible: "translate what you learn into architectural requirements and documented assumptions, so the design traces back to the business case rather than to your own technical preference" (Stakeholder Engagement, Lifecycle & GTM). The CCDV-F guide frames the developer's version as "Functional and infrastructure requirements based on business requirements and solution architecture." (CCDV-F exam guide)

What discovery must produce

Two of these outputs are taught in depth later on this page: the size estimate feeds the lightweight total cost of ownership model the pilot-to-production guide asks for before the pilot, taught in Cost modeling, and the go/no-go process and ownership questions are in Stakeholder communication and lifecycle.

The discovery questions, in order

1. What is ruled out? Governance comes first. The solution-design module asks you to "identify which are ruled out by governance or regulated-industry constraints before any other trade-off applies" (Claude Platform & Solution Design). A concrete case: Claude Managed Agents is stateful by design, so it is not currently eligible for Zero Data Retention (ZDR) or HIPAA Business Associate Agreement coverage. The pilot-to-production guide says to involve legal, compliance and security stakeholders before a pilot launches and to treat compliance as a design constraint surfaced pre-pilot.
2. What is actually required, not assumed? The pilot-to-production guide gives three pre-pilot infrastructure questions: the simplest architecture that meets the actual requirements rather than the assumed ones; "What level of model customization is genuinely necessary versus assumed?"; and "What data residency and security requirements will Legal and Compliance actually enforce?" Its cross-functional "work out" questions add build versus buy (including engineering and maintenance cost), residency and sovereignty, model fit per use case, and cloud, hybrid or on-premises hosting.
3. Is the data ready? Pilots usually run on curated data from one system, while production runs on the real data estate, and the pilot-to-production guide warns that "data causes more programs to stall than almost any other factor." Audit before setting timelines. Early audits find two kinds of issue: access (the data exists but cannot be reached programmatically, or reaching it needs permissions that take months to get through IT and Legal) and quality (it is reachable but inconsistent, incomplete or formatted in ways that produce unreliable outputs). Production needs data flowing in both directions, reliably and at volume, and in many cases vendor API conversations need to start several months earlier than the pilot team typically thinks to start them.
4. Who may see what? Classify the data by sensitivity (public, internal, customer PII, financial, clinical) before setting the pilot architecture, because, in the same guide's words, "AI systems inherit the access control requirements of the data they touch, so those requirements need to be mapped before the pilot is built." In the guide's Novo Nordisk example, the team established exactly what data could flow to and from the model, and what controls were needed, before building; clinical study report production then fell from more than 10 weeks to under 10 minutes.
5. How big and how often? Estimate call volume, token consumption and cost. Frequency matters: the guide says to start with high-frequency, high-value workflows where ROI compounds, because a process that runs hundreds of times a day scales differently from one that runs once a quarter.

From a business need to a testable requirement

A functional requirement describes "the functions that the software is to execute", and it can be validated by a finite set of test steps. Non-functional requirements constrain the solution; SWEBOK also calls them constraints or quality requirements, with types such as performance, maintainability, safety, reliability, security and interoperability (SWEBOK v3, Software Requirements). Requirements should be stated clearly and, where appropriate, quantitatively. SWEBOK warns against vague, unverifiable requirements such as "the software shall be reliable". System requirements cover the users' needs and those of other stakeholders, regulators included, and NIST's glossary defines security requirements as derived from applicable laws, directives, policies, standards, regulations or organizational mission and business needs (NIST glossary: security requirement).

The CCDV-F description pairs functional requirements with infrastructure requirements. In this page's mapping (ours, not the guide's), the infrastructure side is the set of non-functional requirements that decide where and how Claude runs: residency, retention, capacity, latency and hosting. The pilot-to-production questions above and the lever table below turn each one into a design choice.

Anthropic's version of the same discipline is success criteria that are specific, measurable, achievable and relevant, with targets based on industry benchmarks, prior experiments, AI research or expert knowledge; most use cases need several criteria at once (Define success criteria and build evaluations). Rewrite every vague requirement before designing anything:

How to build and grade the test sets behind these criteria is in Success criteria and test sets and, at program level, in Evaluation strategy for a program.

Map each requirement to a design lever

As of September 2026:

Choosing the first use case

Anthropic's enterprise guide lists the traits of a good first use case: suited to what LLMs do well, measurable success metrics, clear ROI, business critical but low in security risk, abundant data, minimal disruption, and scalable. One way to keep disruption low is to run the AI process in parallel with the existing workflow until it proves reliable (Building trusted AI in the enterprise); the parallel run is one of the instruments in From pilot to production.

For individual and team workflows, which is the CCAO-F angle, Anthropic Academy's advice is to start with Problem Awareness: "Before touching any AI tools, analyze your actual workload." List 5 to 10 repetitive or time-consuming tasks from the past week with how often each happens, how long it takes and how standardized it is (AI Fluency for nonprofits). Then ask what an imperfect result would cost, and pick the top-priority task by time saved, frequency and how straightforward the automation would be (AI Fluency for small businesses). The deciding test is "should AI do this?" and not just "can AI do this?": answering documented questions is a good candidate, while complaints and high-stakes requests stay with people.

Running discovery with Claude

Claude can run the requirements conversation itself. In Anthropic Academy's AI-native SDLC playbook, the person with the idea describes the problem in their own words; Claude asks "the questions an analyst would ask: scope, users, constraints, and what success looks like"; Claude drafts an intent document covering the problem, proposed outcome, affected users and systems, constraints and open questions; and the originator corrects anything Claude misunderstood. People who are not engineers can do this from claude.ai or Cowork. Three habits keep the output honest:

• Ask Claude to flag concerns, especially policies that contradict each other, and work through those first, since they are what an analyst would have escalated (Requirements and design).
• State goals and non-goals: "Calling out goals and non-goals keeps scope honest" (PRD from a one-pager).
• Hunt for guesses. The same use case warns that Cowork "fills gaps with reasonable guesses", so fix what you did not decide before the draft goes to review.

When the input is many stakeholders' requests, ask whether different requests point to the same underlying need, and check whether the sample represents the real user base (Analyze patterns in user feedback). The CCAO-F guide page applies this to the exam's scenarios in Domain 4: Workflow Integration and Solution Design.

Decide

• If a regulatory or data-handling constraint applies (ZDR, HIPAA, residency), choose to apply it first and strike out what it excludes; not after comparing cost and latency, because the prep course places governance constraints before any other trade-off.
• If a requirement is vague ("fast", "safe", "reliable"), choose to rewrite it as a measurable criterion; not to pick a model or feature straight away.
• If quality passes but latency or cost fails, test a model or effort change; not only more prompt engineering, because Anthropic notes that latency and cost are sometimes easier to improve by selecting a different model, and that tuning effort is often a better lever than switching models.
• If the work is high volume and straightforward, and speed and cost matter more than deep reasoning, choose a faster, lower-cost model; not the most capable model for every call. The CCAO-F Sample 2 rationale states the rule: "Aligning model selection with task requirements means matching a faster, lower-cost model to straightforward, high-volume work, reserving the most capable model for complex reasoning." (CCAO-F exam guide)
• If a requirement is latency-tolerant (an overnight report), record that in the requirement, because it decides whether Message Batches is an option; the realtime-versus-batch rule is taught in Invocation modes.
• If the data exists but cannot be reached programmatically, or is inconsistent, choose to fix access and quality before committing to a timeline; not to start the build on curated pilot data alone.
• If two designs both meet the stated requirements, choose the simpler one; the pilot-to-production guide asks for the simplest architecture that meets the actual requirements and says to add complexity only when the simpler approach has demonstrably hit its limits.

Traps

• Designing for assumed requirements, such as a regional deployment nobody asked for, instead of asking Legal and Compliance what they will actually enforce.
• A goal with no threshold. Anthropic's enterprise agents guide warns that vague goals such as improving productivity produce vague results that are easy to dismiss; its examples of good criteria are concrete, such as call prep time cut by 50 percent.
• Scoping on the pilot's clean data and discovering the real data estate at production time.
• Treating access control as a later security review when the system inherits the access rules of every source it touches.
• Accepting a polished requirements draft without checking which assumptions Claude supplied.
• Assuming a ZDR arrangement covers every API feature. Message Batches, the Files API, code execution, the MCP connector and Managed Agents are marked not eligible, and the API does not block them under ZDR.

Choosing the surface

Tested in: CCAR-P 1.1 and 1.3 (entry point and architectural pattern), 7.1 (configure Claude tools for teams) · CCDV-F 1.2 Agent Construction with Claude (Agent SDK, managed agent deployment models), 2.5 Claude Application Design (instructions across Claude Code, Desktop, claude.ai, API and SDKs) · CCAO-F D3.1 (select product features) · CCAR-F: the six scenario settings (three built on the Agent SDK, two on Claude Code including CI/CD, one structured extraction system) and the Appendix technologies list (Agent SDK, Claude Code, Claude Code CLI, Claude API, Message Batches API)

The surface is where Claude meets its user and who runs the agent loop. Anthropic's prep courses and documentation each frame this decision in their own words: the CCAR-P prep course says "entry point", and the CCAO-F prep course names entry point as the first of four decisions made before any prompt is written (with capability features, model and context). The Agent SDK documentation frames the developer version: "The Agent SDK, the CLI, the Client SDK, and Managed Agents differ in who runs the agent, what comes built in, and how you reach it." (Agent SDK overview). Anthropic's platform introduction describes two ways to build on the API: the Messages API, for custom agent loops and fine-grained control, and Claude Managed Agents, a pre-built harness in managed infrastructure for long-running and asynchronous work (Intro to Claude).

The CCAR-P solution-design module splits the decision into layers. It asks you to "Distinguish between the Claude entry points a user sees, the build-time interfaces an engineer codes against, and the delivery routes an enterprise procures", to know where each entry point (Claude.ai, the API, an SDK, Claude Code, or an MCP server) fits and what customization belongs at each layer, and to "Choose between an augmented call, a workflow, and an agent by naming what each choice costs" (Claude Platform & Solution Design). In this page's terms (our mapping): the table below covers entry points and build-time interfaces, and delivery routes are in Deployment platforms and capacity. The same module asks you to identify which options governance or regulated-industry constraints rule out before any other trade-off applies, which is why the ZDR and HIPAA checks come first in the rules below.

The surfaces side by side

As of September 2026:

Amazon Bedrock, Google Cloud, Microsoft Foundry and Claude Platform on AWS are not further surfaces in this sense. They are delivery routes: they decide where the model runs, how you are billed and which features exist, for traffic from the Messages API, the Agent SDK or Claude Code. Comparing them on latency, compliance and cost, as the CCAR-P prep course asks, is taught in Deployment platforms and capacity.

A quick way to decide

Who is the user, and who should run the loop?

1. A person doing their own knowledge work
     turn by turn ................................. chat, with a Project for standing context
     hand off an outcome, return later ............ Cowork
2. A developer building or changing software
     interactive .................................. Claude Code
     unattended, in a pipeline .................... claude -p, or Claude Code GitHub Actions
3. Claude inside a product you ship
     one call, a fixed workflow, or your own loop . Messages API through a client SDK
     Claude Code's agent inside your process ...... Claude Agent SDK
     an agent you do not want to host ............. Claude Managed Agents
4. Nobody is waiting for the answer ............... Message Batches (a Messages API feature:
                                                     50% lower cost, up to 24 hours, no latency SLA;
                                                     Managed Agents has no batch mode)

Decision rules

• If ZDR or HIPAA BAA coverage is mandatory, rule out Managed Agents before comparing anything else, because it is stateful by design and not currently eligible. For ZDR, also rule out the Claude Team and Enterprise product interfaces, which are not ZDR-eligible; the documented exception is Claude Code used through Claude Enterprise with ZDR enabled.
• If a single well-built call meets the quality bar, choose the Messages API with that one call; not an agent. Anthropic's guidance reads: "For many applications, however, optimizing single LLM calls with retrieval and in-context examples is usually enough." The same post notes that agentic systems often trade latency and cost for better task performance (Building effective agents). Pattern selection itself is taught in Workflows or agents.
• If the loop needs human-in-the-loop approval, custom logging or conditional execution, write it yourself on the client SDK; not the beta tool runner, whose documentation sends those cases to the manual loop.
• If you want Claude Code's built-in tools, permissions, sessions and hooks inside your product, choose the Agent SDK. If you do not need to run the loop on your own infrastructure, the Agent SDK hosting guide itself points to Managed Agents.
• If the calling service is written in a language other than Python or TypeScript and needs Claude Code's agent loop, run the CLI as a subprocess with -p and --output-format json.
• If the users are knowledge workers whose needs are met by chat, Projects, connectors or Cowork, choose the apps. The CCAO-F guide places enterprise-scale architecture and integration design with the Architect and Developer credentials, to which Associates escalate more technical work. The CCAO-F choice among the guide's named features (Projects, research mode, chat, artifacts) is taught in Projects, Search, Research and connectors and Artifacts, files and code execution.
• If you are rolling Claude Code out to an organization, Claude for Teams or Enterprise is the documented default; the provider comparison and the rest of the rollout are in Choose the provider.
• If a framework is on the table, start with the API directly: Anthropic suggests "developers start by using LLM APIs directly" and, if a framework is used, understanding its underlying code, then reducing abstraction layers as the system moves to production. Frameworks are compared in Agent frameworks.

What changes when the surface changes

How instructions behave on each surface is taught in XML tags, system prompts and roles. Hosting the Agent SDK yourself and running Managed Agents in a self-hosted sandbox are two different meanings of "self-hosted"; both are in Deployment models.

Traps

• An agent where one call would do. The added latency and cost buy nothing if a single call with retrieval and examples already meets the bar.
• Managed Agents for a ZDR or HIPAA workload. It is not eligible for either.
• Expecting a batch discount from Managed Agents. Sessions are stateful and interactive, and there is no batch mode.
• Assuming cloud-provider credentials give access to every Claude Code feature. Cloud sessions, Routines, Code Review, Remote Control and the Chrome extension need a claude.ai account.
• Offering claude.ai login in a product built on the Agent SDK. Anthropic does not allow it unless previously approved.
• Scaling the Agent SDK like a stateless web service. Session transcripts, CLAUDE.md memory files and working-directory artifacts live on local disk and do not survive a container restart, a scale-down or a move to another node; a SessionStore mirrors transcripts only.
• Assuming an API ZDR agreement covers the Claude apps. The Team and Enterprise product interfaces are not ZDR-eligible; the documented exception is Claude Code used through Claude Enterprise with ZDR enabled.

Retrieval-augmented generation

Tested in: CCAR-P 3.5 (RAG pipeline with chunking and indexing), 3.6 (retrieval strategies matched to data shape and query pattern), 3.8 (progressive discovery vs. monolithic context), 4.4 (diagnose system issues; Sample 3 is tagged to Domain 4) · CCDV-F 2.3 Claude API Mechanics (Messages API data access patterns) · CCAO-F D5.1 (Projects with knowledge sources) · CCAR-F: embedding models and vector database implementation details are out of scope

Anthropic's glossary defines retrieval-augmented generation as retrieving data from an external knowledge base at the moment a query is sent and passing it into the context window; the model does not necessarily do the retrieving itself, although it can through tool use (Glossary). The CCAR-P guide expects hands-on experience: its preparation list says to "Build and operate at least one end-to-end Claude solution, including RAG, evaluation, and observability", and its Sample 3 rationale says confident wrong answers after a document refresh "point to retrieval feeding the model poor context, for example a broken re-index or mismatched embeddings" (CCAR-P exam guide). The sample itself, with its options, is reproduced on the CCAR-P exam page.

First decide whether you need a pipeline

The pipeline, stage by stage

INGEST (once per document version)
  1. Split each document into chunks (usually no more than a few hundred tokens)
  2. Contextualize each chunk: Claude writes 50 to 100 tokens that situate it in its document
  3. Index twice: embeddings in a vector index, and BM25 in a lexical index

QUERY (every request)
  4. Retrieve candidates from both indexes; merge and deduplicate with rank fusion
  5. Rerank the candidates (Anthropic's test: top 150 in, top 20 out)
  6. Give the chunks to Claude as search results or documents, citations on
  7. Generate the answer, citing the chunks it used

EVALUATE (continuously)
  8. Measure retrieval (recall@k, MRR) separately from end-to-end answer accuracy

Chunking

Standard preprocessing splits the corpus into chunks of "usually no more than a few hundred tokens", and "The choice of chunk size, chunk boundary, and chunk overlap can affect retrieval performance" (Contextual Retrieval). Anthropic's RAG cookbook chunks by heading, so each chunk holds the content of one subheading. Voyage's server-side auto-chunking resolves chunk_size to 512 tokens when it is omitted, chunk_overlap defaults to 0, and overlapping tokens are billed as input. Chunking also decides citation granularity: in the Citations feature, plain-text documents are split into sentences, while custom content documents are used as-is, so put each chunk in its own plain-text document if you want sentence-level citations.

Contextual Retrieval: the published numbers

A chunk such as "The company's revenue grew by 3% over the previous quarter." does not say which company or which quarter, so it retrieves poorly. Contextual Retrieval, published on Anthropic's engineering blog on September 19, 2024, prepends chunk-specific explanatory context to each chunk before embedding it (Contextual Embeddings) and before building the BM25 index (Contextual BM25). The generated context is usually 50 to 100 tokens.

original_chunk = "The company's revenue grew by 3% over the previous quarter."
contextualized_chunk = "This chunk is from an SEC filing on ACME corp's performance in Q2 2023; the previous quarter's revenue was $314 million. The company's revenue grew by 3% over the previous quarter."

The post's headline claim: "This method can reduce the number of failed retrievals by 49% and, when combined with reranking, by 67%." The measured results, on the post's metric of 1 minus recall@20 (the percentage of relevant documents not retrieved within the top 20 chunks):

The conditions behind those numbers matter as much as the numbers:

• Averaged across domains. The graphs average the knowledge domains tested (codebases, fiction, ArXiv papers, science papers) using the top-performing embedding configuration, Gemini Text 004, retrieving the top 20 chunks.
• Reranking setup. Initial retrieval took the top 150 chunks, the reranker kept the top 20, and the tests used the Cohere reranker; Voyage also offers one, which the post did not test. In the post's words, "There is an inherent trade-off between reranking more chunks for better performance vs. reranking fewer for lower latency and cost."
• How many chunks to pass. Anthropic tried 5, 10 and 20 chunks, and 20 performed best of those options.
• Embeddings. Contextual Retrieval helped every embedding model tested; Gemini and Voyage embeddings were particularly effective, and embeddings plus BM25 beat embeddings alone.
• Cost. With prompt caching, the post put the one-time cost to contextualize at $1.02 per million document tokens, assuming 800-token chunks, 8k-token documents, 50-token context instructions and 100 tokens of context per chunk. The post generated that context with Claude 3 Haiku, now retired, and the current cookbook repeats the same figure while using claude-haiku-4-5; recompute it at current prices before you budget. As of September 2026, Claude Haiku 4.5 lists $1 per million input tokens, $0.10 per million cache-hit tokens and $5 per million output tokens.
• What did not work as well. Adding generic document summaries to chunks gave very limited gains, and summary-based indexing performed poorly.
• Tuning. The post says the generic prompt works well and a prompt tailored to your domain or use case may do even better, for example one that includes a glossary of key terms that might only be defined in other documents.

The contextualizer prompt from the post:

<document>
{{WHOLE_DOCUMENT}}
</document>
Here is the chunk we want to situate within the whole document
<chunk>
{{CHUNK_CONTENT}}
</chunk>
Please give a short succinct context to situate this chunk within the overall document for the purposes of improving search retrieval of the chunk. Answer only with the succinct context and nothing else.

The same call through the Messages API, adapted from Anthropic's contextual embeddings cookbook. The whole document carries cache_control, so it is cached once and every later chunk from that document reads it from the cache (the cookbook's note: "Read the document from cache (90% discount on those tokens)"):

import anthropic

client = anthropic.Anthropic()

DOCUMENT_CONTEXT_PROMPT = """
<document>
{doc_content}
</document>
"""

CHUNK_CONTEXT_PROMPT = """
Here is the chunk we want to situate within the whole document
<chunk>
{chunk_content}
</chunk>

Please give a short succinct context to situate this chunk within the overall document for the purposes of improving search retrieval of the chunk.
Answer only with the succinct context and nothing else.
"""

def situate_context(doc: str, chunk: str) -> str:
    response = client.messages.create(
        model="claude-haiku-4-5",
        max_tokens=1024,
        messages=[
            {
                "role": "user",
                "content": [
                    {
                        "type": "text",
                        "text": DOCUMENT_CONTEXT_PROMPT.format(doc_content=doc),
                        "cache_control": {"type": "ephemeral"},  # cache the full document
                    },
                    {
                        "type": "text",
                        "text": CHUNK_CONTEXT_PROMPT.format(chunk_content=chunk),
                    },
                ],
            }
        ],
    )
    return response.content[0].text

The main changes from the cookbook: the model name is written inline instead of through its MODEL_NAME variable, the function returns the text rather than the whole response, and the cookbook's temperature=0.0 is left out. The model deprecations page explains the last one: "The Python SDK (v1.0 and later) removes temperature, top_p, and top_k, so passing them raises a TypeError", and at the API level, Claude 4.7 and later models (not the Claude Haiku 4.5 used here) return a 400 error for a non-default temperature. Keep one more constraint in mind: the minimum cacheable prompt is 4,096 tokens on Claude Haiku 4.5 (512 on Claude Fable 5.1 and Claude Opus 5.5), and a shorter prompt is processed without caching and without an error, so short documents get no caching benefit.

Embeddings

"Anthropic does not offer its own embedding model." Its embeddings page points to Voyage AI while telling readers to assess vendors on dataset size and domain specificity, inference performance, and customization. A selection of the Voyage models it lists, as of September 2026 (the page also lists voyage-4-nano, earlier general-purpose models, multimodal models and voyage-context-3, and it files the three domain models in its previous-generation table while still recommending them for their domains):

• Set input_type. Use "document" when indexing and "query" when searching: "Do not omit input_type or set input_type=None." (embeddings page)
• Similarity. Voyage embeddings are normalized to length 1, so cosine similarity equals dot product, and the dot product is faster.
• Storage. output_dtype quantization to int8 or binary cuts storage, memory and cost by 4x and 32x respectively; Matryoshka embeddings can be truncated by keeping the leading dimensions, and the embeddings page's example then re-normalizes the shortened vectors to unit length.
• Compatibility. All Voyage 4 series models produce compatible embeddings, so you can embed documents with one and queries with another (Voyage's Voyage 4 announcement calls this "asymmetric retrieval") and upgrade the query model without re-vectorizing documents.
• Price. As of September 2026, Voyage's pricing table makes the first 200 million tokens free for every account on voyage-4-large, voyage-4, voyage-4-lite, voyage-context-4 and voyage-code-4, and the first 50 million on voyage-finance-2 and voyage-law-2; after that voyage-4-large costs $0.12 and voyage-4-lite $0.02 per million tokens. Voyage's Batch API has a 12-hour completion window and a 33% discount, and the free tokens do not apply to it.
• Naming drift. Anthropic's page recommends voyage-code-3, while Voyage's own pricing table now lists voyage-code-4 and moves voyage-code-3 to its older models, which it says get no free tokens (the page's introductory paragraph still names voyage-code-3 among the 200-million-token models).

Embedding documents and a query, then scoring by dot product (from the embeddings page, where documents and query are defined):

import voyageai
import numpy as np

vo = voyageai.Client()  # reads VOYAGE_API_KEY

doc_embds = vo.embed(documents, model="voyage-4", input_type="document").embeddings
query_embd = vo.embed([query], model="voyage-4", input_type="query").embeddings[0]

similarities = np.dot(doc_embds, query_embd)
retrieved_id = np.argmax(similarities)

Contextualized chunk embeddings do the contextualizing inside the embedding model, capturing full-document context without manual metadata augmentation. With auto-chunking (enable_auto_chunking=True), you pass a flat list of whole documents and input_type must be document; this example is from Voyage's contextualized chunk embeddings page:

import voyageai

vo = voyageai.Client()

documents = [
    "This is the SEC filing on Leafy Inc.'s Q2 2024 performance.\nThe company's revenue increased by 15% compared to the previous quarter.",
    "This is the SEC filing on Elephant Ltd.'s Q2 2024 performance.\nThe company's revenue decreased by 2% compared to the previous quarter.",
]

result = vo.contextualized_embed(
    model="voyage-context-4",
    inputs=documents,
    input_type="document",
    enable_auto_chunking=True,
    chunk_size=512,
    chunk_overlap=0,
)

Lexical search, hybrid fusion and reranking

BM25 is a ranking function that uses lexical matching to find precise word or phrase matches, which suits unique identifiers and technical terms. The post's example is a query for error code "TS-999": an embedding model can return content about error codes in general and miss the exact match. Hybrid retrieval runs both searches and combines and deduplicates the results with rank fusion. The contextual embeddings cookbook takes the top 150 results from each and fuses them with weighted Reciprocal Rank Fusion, 80% semantic and 20% BM25 by default.

Rerankers are cross-encoders that score the query and each document together, which is why they run on the top candidates from a first-stage search rather than on the whole corpus. Anthropic's embeddings page lists rerank-2.5 ("Highest accuracy. Recommended for most applications.") and rerank-2.5-lite (latency and cost), both with a 32,000-token context and called with rerank(). Voyage's limits: a request can carry at most 1,000 documents, and the query can be up to 8,000 tokens for rerank-2.5 and rerank-2.5-lite. Claude can also act as the reranker: by default the RAG cookbook retrieves 20 candidates and has Claude pick the most relevant 3.

From Voyage's reranker page, where query and documents are the same six-document example used on the embeddings page:

import voyageai

vo = voyageai.Client()
reranking = vo.rerank(query, documents, model="rerank-2.5", top_k=3)
for r in reranking.results:
    print(f"Document: {r.document}")
    print(f"Relevance Score: {r.relevance_score}")

Voyage's own reranker page now labels a preview rerank-3 as "Highest accuracy" while still listing rerank-2.5 and rerank-2.5-lite as recommended options; Anthropic's page gives that label to rerank-2.5.

Handing retrieved content to Claude

• Search result blocks. A search_result content block lets Claude cite your own retrieved content with the source and title you supply, the same way it cites web search. It needs no beta header and can arrive in a tool result (dynamic RAG) or as top-level user content (pre-fetched content).
• Citations on documents. Put each chunk in its own plain-text document for sentence-level citations, or use a custom content document when you do not want any further chunking. The cited_text field does not count toward output tokens.
• Long documents. For tasks over long documents (more than 20k tokens), ask Claude to extract word-for-word quotes before doing the task, to reduce hallucinations.
• Untrusted text. Retrieved content is third-party content. Anthropic's injection guidance is to deliver it inside tool_result blocks, never in system prompts or plain user text blocks, so returning search_result blocks from a retrieval tool meets both the citation guidance and the injection guidance. See Prompt injection.
• An index you already run. In Claude Code, the large-codebase guidance is to expose an existing code search or RAG index as an MCP tool so Claude queries it instead of reading files directly.

{
  "type": "search_result",
  "source": "https://example.com/article",
  "title": "Article Title",
  "content": [
    { "type": "text", "text": "The actual content of the search result..." }
  ],
  "citations": { "enabled": true }
}

Field-level rules for search results, documents and citations are in Files, citations and search results.

Retrieval strategy by data shape and query pattern

Data shape is what the data is; query pattern is how people ask for it. Match the retriever to both:

The text-to-SQL cookbook builds the schema description it sends to Claude like this (SQLite; the cookbook's inline comments removed):

def get_schema_info(db_path):
    conn = sqlite3.connect(db_path)
    cursor = conn.cursor()
    schema_info = []
    cursor.execute("SELECT name FROM sqlite_master WHERE type='table';")
    tables = cursor.fetchall()
    for (table_name,) in tables:
        cursor.execute(f"PRAGMA table_info({table_name})")
        columns = cursor.fetchall()
        table_info = f"Table: {table_name}\n"
        table_info += "\n".join(f"  - {col[1]} ({col[2]})" for col in columns)
        schema_info.append(table_info)
    conn.close()
    return "\n\n".join(schema_info)

The cookbook also lists extra context that helps SQL generation (data samples, column statistics, data-quality notes, data-catalog details and business context) and, for growing schemas, suggests filtering the schema lookup to recently queried tables and ranking it by how often tables are queried in production.

Keeping the index correct

In the CCAR-P Sample 3 scenario (confident wrong answers right after a document refresh, with the model and latency unchanged), the keyed answer is the retrieval and indexing step, and the rationale dismisses the model, temperature and context-window options because they "would not be triggered specifically by a document refresh" (CCAR-P exam guide). The question to ask is what changed. Anthropic's RAG cookbook shows one way a refresh goes wrong: in this excerpt of its VectorDB.load_data method, the loader reuses a saved index from disk and skips re-embedding, so a refreshed corpus keeps serving the old chunks until the index is rebuilt.

def load_data(self, data):
    if self.embeddings and self.metadata:
        print("Vector database is already loaded. Skipping data loading.")
        return
    if os.path.exists(self.db_path):
        print("Loading vector database from disk.")
        self.load_db()
        return

    texts = [f"Heading: {item['chunk_heading']}\n\n Chunk Text:{item['text']}" for item in data]
    self._embed_and_store(texts, data)
    self.save_db()

• Re-index when documents change, and re-run retrieval metrics afterward.
• Keep documents and queries on compatible embeddings. The cookbook embeds both with the same model; Voyage documents compatibility within the 4 series. Switching the query model outside a compatible series without re-embedding the corpus is one way to get the "mismatched embeddings" of the CCAR-P Sample 3 rationale (CCAR-P exam guide).
• Watch input limits. If results get worse after contextualizing, the embedding model may be truncating the longer chunks; the cookbook's advice is a model with a larger context window.
• Update schema indexes when database schemas change.
• Keep project knowledge current in Claude Projects, because outdated documents can lead to outdated responses.
• Or avoid the index. Just-in-time retrieval with tools such as glob and grep bypasses stale indexing altogether.

Evaluating retrieval

"When evaluating RAG applications, it's critical to evaluate the performance of the retrieval system and end to end system separately." (RAG cookbook)

Many RAG systems favor recall, because the model can ignore less relevant chunks during generation. The RAG cookbook's eval set had 100 synthetic samples (question, expected chunks, correct answer), and moving from basic RAG to summary indexing to reranking with Claude raised MRR from 0.74 to 0.87 and end-to-end accuracy from 71% to 81%. The cookbook's summary indexing has Claude write a 2 to 3 sentence summary of each chunk, then embeds the chunk's heading, that summary and the original text together. The Contextual Retrieval post lists summary-based indexing among approaches that performed poorly in its evaluation, without describing how that index was built, so read the two results as separate experiments rather than a contradiction. Program-level evaluation design is in Evaluation strategy for a program.

Decide

• If the corpus is small, stable and open to every user, choose to put it in the prompt with prompt caching; if freshness or per-user access control drives the design, choose retrieval.
• If queries contain exact identifiers, choose hybrid retrieval with BM25; not embeddings alone.
• If chunks lose meaning outside their document, choose contextualized chunks (Contextual Retrieval, or contextualized chunk embeddings); not generic document summaries attached to chunks.
• If precision in the top results matters, choose to retrieve a wide candidate set and rerank; weigh the added latency and cost per query.
• If answers go wrong after a document refresh while the model and latency are unchanged, choose to investigate retrieval and indexing first; not the model, the temperature or the context window.
• If the answer is live state, choose a tool call to the system of record; not a vector index.

Traps

• Judging the pipeline only on end-to-end accuracy, so retrieval regressions stay invisible.
• Omitting input_type, or mixing embedding models between index and queries outside a compatible series.
• Quoting the 49% and 67% figures without their conditions: 1 minus recall@20, averaged across the post's domains, reranking 150 down to 20.
• Treating the 200,000-token threshold as current guidance.
• Letting a vector index stand in for the source of truth on fast-changing state.
• Putting retrieved text in the system prompt. Anthropic's guidance is to deliver third-party content inside tool_result blocks, never in system prompts or plain user text blocks.

Integration patterns

Tested in: CCAR-P 1.2 (end-to-end architectures: input, processing, output, feedback loops), 3.2 (authentication and authorization gaps), 3.7 (connection protocols: MCP, API/CLI, agent-to-agent) · CCDV-F 2.3 Claude API Mechanics (realtime vs. batch), 2.4 Software Engineering Foundations (REST APIs, JSON, asynchronous programming), 5.2 Technical Fundamentals (SDKs that wrap REST APIs, websockets) · CCAO-F D4.4 (integrate Claude into existing workflows) · CCAR-F 4.5 (the Message Batches API: 4.5-K1 to 4.5-K4, 4.5-S1 to 4.5-S4) and 3.6-K1, 3.6-K2 (Claude Code in CI/CD); CCAR-F lists deploying or hosting MCP servers and streaming API implementation as out of scope

An integration answers three questions: how a request reaches Claude and how long the caller waits (the invocation mode), how Claude reaches your systems (the connection mechanism), and where credentials and trust boundaries sit. The CCAR-P prep course puts the production version in one line: "Take a solution from proof of concept to production by mapping cost, latency, and reliability to a budget and specifying the integration patterns an enterprise will accept" (CCAR-P prep course).

A reference architecture, end to end

CCAR-P objective 1.2 asks for "input → processing → output → feedback loops" (CCAR-P exam guide). The arrangement below, including a separate ACTION stage, is ours; each control in it comes from Anthropic guidance:

INPUT        a user, an event, a schedule or a pipeline trigger
  |          screen untrusted input with a lightweight model such as Claude Haiku 4.5
  v
PROCESSING   assemble context: instructions, retrieved chunks, live data from tools
  |          run the call or the agent loop; authorize each tool call before it runs
  v
OUTPUT       validate structure and content; screen the output
  |          route by risk: automated, sampled, reviewed, or advisory to a human
  v
ACTION       write back to systems of record through narrowly scoped tools
  |
  v
FEEDBACK     log requests and outcomes; monitor for quality drift;
             feed production data back into the offline evaluation set

The official prep course describes the safety stack the same way: input screening, output screening and tool-call authorization, placed "so the system fails closed rather than open". Each stage is taught elsewhere: screening and review tiers in Governance and risk in delivery, output checks in Validation, retry and feedback loops, monitoring in Reliability engineering for Claude applications, and the evaluation loop in Evaluation strategy for a program.

Invocation modes

The CI side of the headless row (flags, structured findings, review loops) is taught in Claude Code in CI/CD.

CCDV-F Sample 1 (Domain 2) tests this choice and gives the rule in Anthropic's words: "The Message Batches API is designed for latency-tolerant, high-volume workloads at lower cost, which matches an overnight, non-urgent job." It also names the wrong answers: "Sending requests synchronously in parallel (A) does not reduce per-token cost; lowering max_tokens (C) or blindly downsizing the model (D) does not address the batch-versus-realtime tradeoff." (CCDV-F exam guide). Anthropic's cost guide says the same thing as a policy: "Route every request no one is waiting on through a batch, and keep the interactive path for the rest." (Optimizing for cost and intelligence)

A batch can still meet a service level if you schedule submissions around its window. The CCAR-F guide's example is "4-hour windows to guarantee 30-hour SLA with 24-hour batch processing": a document waits at most 4 hours for the next submission and then up to 24 hours for processing, 28 hours in the worst case, inside the 30-hour commitment (our arithmetic). A request still unprocessed when its batch reaches 24 hours comes back expired rather than completed, so the 28 hours bounds when you have either a result or an expired request to resubmit; batch itself has no guaranteed latency SLA. The same task statement also expects you to resubmit only the failed documents, identified by custom_id, and to refine the prompt on a sample set before a large batch. Batch request mechanics are in Message Batches and batch design in Batch processing design.

SDKs, REST and concurrency

The Claude API is a RESTful API at https://api.anthropic.com, and the official SDKs wrap it. The Python SDK supports synchronous and asynchronous operation, streaming, and the Bedrock, Claude Platform on AWS, Google Cloud and Foundry integrations; the TypeScript SDK is promise-based and consumes streams with for await. Both retry transient failures twice by default; the Python SDK lists connection errors, 408, 409, 429 and 500 and above. Messages API streaming is server-sent events, which are one-way from server to client; WebSockets, by contrast, are full-duplex after an HTTP Upgrade handshake. WebSockets appear in the Claude stack at the edges: an Agent SDK container can expose an HTTP or WebSocket endpoint in front of its sessions (the claude subprocess itself talks to the SDK over stdio), and Claude Code accepts WebSocket MCP servers for servers that push events; see MCP transports.

Fan-out is where integrations break. Rate limits can be enforced over intervals shorter than a minute, so an unbounded burst of parallel requests trips 429s, and the Agent SDK hosting guide lists large parallel-subagent fan-outs hitting rate limits as a known limitation, with the advice to break work into smaller batches rather than issuing one wide dispatch. Cap the requests in flight. The pattern below combines the Python SDK's AsyncAnthropic client and the promise-based TypeScript client with standard concurrency primitives (asyncio.Semaphore and asyncio.gather in Python, Promise.all over a fixed pool of workers in TypeScript). The limit of 10 is illustrative; size it from your rate limits.

import asyncio
from anthropic import AsyncAnthropic

client = AsyncAnthropic()
sem = asyncio.Semaphore(10)  # cap in-flight requests

async def classify(text: str):
    async with sem:
        return await client.messages.create(
            model="claude-opus-5-5",
            max_tokens=1024,
            messages=[{"role": "user", "content": text}],
        )

async def main(texts):
    return await asyncio.gather(*(classify(t) for t in texts))

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

async function classifyAll(texts: string[], limit = 10): Promise<Anthropic.Message[]> {
  const results: Anthropic.Message[] = new Array(texts.length);
  let next = 0;
  async function worker(): Promise<void> {
    while (next < texts.length) {
      const i = next++; // claim the next text
      results[i] = await client.messages.create({
        model: "claude-opus-5-5",
        max_tokens: 1024,
        messages: [{ role: "user", content: texts[i] }],
      });
    }
  }
  // at most `limit` requests in flight
  await Promise.all(Array.from({ length: Math.min(limit, texts.length) }, () => worker()));
  return results;
}

asyncio.gather returns results in the order the awaitables were given; by default it propagates the first exception immediately to the awaiting task while the other awaitables keep running, and Promise.all rejects on the first rejected promise. Either way one failure costs you the aggregate result, so catch errors per request (or pass return_exceptions=True to gather) when one failure should not discard the others. If the work is latency-tolerant, a batch is a better answer than any concurrency limit. And keep production on the Anthropic SDKs: the OpenAI SDK compatibility layer is "primarily intended to test and compare model capabilities, and is not considered a long-term or production-ready solution for most use cases"; through it the function-calling strict parameter is ignored and prompt caching is not supported (OpenAI SDK compatibility).

Connecting Claude to your systems

The three-way comparison of direct API calls, CLIs and MCP, with agent-to-agent alongside, is in Built-in tools, custom tools, Skills or MCP. Its architectural consequences, from Anthropic's post on agents that reach production systems:

• Direct integrations multiply into the M×N problem: every agent and service pair needs its own auth handling, tool descriptions and edge cases.
• The post's advice: "if your goal is to have production agents in the cloud reach your system, build an MCP server"; a remote MCP server is the only configuration that runs across web, mobile and cloud-hosted agents.
• Anthropic expects mature integrations to ship all three layers: the API as the foundation, a CLI for local-first environments, and MCP for cloud agents. Where a shell is available, Claude Code's best practices still call CLI tools the most context-efficient way to reach external services.
• Group tools around intent rather than mirroring endpoints. For very large APIs, a thin surface that accepts code works: Cloudflare's MCP server covers about 2,500 endpoints with two tools (search and execute) in roughly 1K tokens.

The pattern depends on the Claude surface and on where the system sits, including behind a firewall or an identity provider:

The connector request shape, the tool configuration inside mcp_toolset and deferred loading for large MCP tool sets are in MCP in the API and the Agent SDK.

Agent-to-agent integration

When the system on the other side is itself an agent, owned by another team, vendor or organization, the CCAR-P guide's third option applies. The guide names no protocol for this option; one open standard for it is A2A: "The Agent2Agent (A2A) Protocol is an open standard designed to facilitate communication and interoperability between independent, potentially opaque AI agent systems." Agents exchange information without access to each other's internal state, memory or tools (A2A specification). A2A is an open-source Linux Foundation project contributed by Google and licensed under Apache 2.0. As of September 2026 its specification page shows 1.0.0 as the latest released version, with bindings to JSON-RPC, gRPC and HTTP/REST.

A basic task over the HTTP+JSON binding, request then response body, from the specification's illustrative examples (section 6.1, Basic Task Execution):

POST /message:send HTTP/1.1
Host: agent.example.com
Content-Type: application/a2a+json
Authorization: Bearer token

{
  "message": {
    "role": "ROLE_USER",
    "parts": [{"text": "What is the weather today?"}],
    "messageId": "msg-uuid"
  }
}

{
  "task": {
    "id": "task-uuid",
    "contextId": "context-uuid",
    "status": {"state": "TASK_STATE_COMPLETED"},
    "artifacts": [{
      "artifactId": "artifact-uuid",
      "name": "Weather Report",
      "parts": [{"text": "Today will be sunny with a high of 75°F"}]
    }]
  }
}

Security follows ordinary web practice. Identity is handled at the HTTP layer, not inside A2A payloads; production deployments must use HTTPS (TLS for gRPC); clients read the required schemes from the Agent Card's securitySchemes, obtain credentials out of band and send them on every request; the server must authenticate every request; and moving a task to TASK_STATE_AUTH_REQUIRED does not by itself authorize anything. The A2A project's own summary of the split with MCP: "A2A connects the agents to each other; MCP connects each agent to its own tools." (A2A and MCP).

Where Claude meets A2A, the protocol support comes from the framework or runtime around the model. Google Cloud describes a registered Claude-powered agent on its Agent Platform delegating tasks to other agents over A2A, Google's Agent Development Kit supports Claude models in Python and Java, and AWS added A2A support to Amazon Bedrock AgentCore Runtime, naming Anthropic Claude among the models whose agents can interoperate. Anthropic and Google Cloud also presented a webinar, dated August 27, 2025, on multi-agent systems using MCP and A2A with Claude on Vertex AI. So the accurate statement is that Claude can power agents that interoperate over A2A through a framework or runtime that implements it. When every agent is your own and they can share one sandbox, Anthropic's first-party option is Managed Agents multiagent orchestration, taught in Multi-agent orchestration.

Credentials and trust boundaries

CCAR-P 3.2 asks you to find authentication and authorization gaps. At integration boundaries the recurring ones are:

The CCAR-P guide's Sample 1 is tagged to Domain 3 (Integration) and tests the tool side of the same boundary: a support agent holds refund and delete tools that its users never need, and the keyed answer removes them. The item and its rationale are worked through in Design the safety stack to fail closed.

Secrets handling and least privilege are taught in depth in Secrets and API keys and Least privilege for tools and agents. CCAR-F lists OAuth, API key rotation and authentication protocol details as out of scope. The CCAR-P guide publishes no such exclusion, and its objective 3.2 asks you to analyze authentication and authorization requirements to identify security gaps.

Fitting Claude into an existing workflow

For CCAO-F D4.4 the integration is a work process rather than an API. The workflow-augmentation lesson in Anthropic Academy's AI Fluency for nonprofits course sorts each task into three groups: AI can handle it; AI can assist and a human decides; or a human should handle it (high-stakes decisions, emotional situations, complex judgment calls). The same lesson says to test the new flow with real past examples and to review outputs before they go out, especially early on. Anthropic's research on productivity gains adds a caution: as AI accelerates some tasks, others may become bottlenecks, so watch the steps you did not change. Once a process works, Cowork can repeat it: do the task once, confirm the output, then type /schedule. Artifacts are for prototypes; the Academy says they are best for testing and demonstration, and that at some point you will likely want proper API key management and production-grade infrastructure. Before retiring the old process, run the new one alongside it until it proves reliable (the parallel run in From pilot to production). See Domain 4: Workflow Integration and Solution Design for the exam framing.

Decide

• If a caller is blocked waiting (a pre-merge check, a live chat), choose the synchronous API, streamed when a person is watching; if nobody is waiting, choose Message Batches; not parallel synchronous calls, which do not reduce per-token cost.
• If many requests must run at once, choose bounded concurrency or a batch; not an unbounded fan-out that trips short-interval rate limits.
• If production agents in the cloud must reach your system, choose a remote MCP server; if the integration is one agent and one service that will not be reused, direct API calls are proportionate.
• If a Managed Agents session or a Messages API application must reach an MCP server inside a private network, choose MCP tunnels (outbound-only, no inbound firewall ports); not opening the server to the public internet. If the design needs an uptime or support commitment, tunnels do not carry one while they are a research preview, so plan for that gap.
• If claude.ai or Cowork users need the internal system through a custom connector, the server must be reachable over the public internet from Anthropic's IP ranges. Tunnels are not documented as an option there: the MCP tunnels page lists Claude Managed Agents and the Messages API as the surfaces that reach tunneled servers, and notes that "MCP tunnels created through the Console are not available as connectors in claude.ai".
• If the counterpart is an independent agent from another team or vendor with stateful, multi-turn work, choose an agent-to-agent protocol such as A2A through a framework or runtime that implements it; if it is a well-defined capability, expose it as a tool.
• If a browser needs Claude, put a backend in front of the API; not an API key in client-side code.

Traps

• Batching a blocking workflow such as a pre-merge check. The CCAR-F guide calls batch inappropriate for blocking workflows and notes that it has no guaranteed latency SLA.
• Expecting batch results in submission order instead of matching on custom_id.
• Stacking your own retry loop on the SDK's automatic retries (two by default; max_retries in Python, maxRetries in TypeScript, and 0 disables them) without adjusting either, which multiplies attempts against a rate limit (our reasoning).
• Pointing the Messages API MCP connector at a local stdio server. It connects only to publicly exposed HTTP servers (Streamable HTTP or SSE). For an HTTP MCP server inside a private network, use an MCP tunnel; the tunnel changes how the server is reached, not its transport.
• Guarding a tool the role never needs with logging or a confirmation prompt. CCAR-P Sample 1 keys removing the tool; see Design the safety stack to fail closed.
• Saying the Claude API itself speaks A2A. A2A support with Claude comes from frameworks and runtimes such as Google's ADK and Bedrock AgentCore.
• Passing a user's token straight through an MCP server to a downstream API; token passthrough is forbidden by the MCP security guidance.

Deployment platforms and capacity

Tested in: CCAR-P 1.6 (performance SLAs as a value pillar), 3.3 (accuracy-latency trade-offs and configuration decisions), 6.3 (expectation alignment, including SLAs) · CCDV-F 2.3 Claude API Mechanics (invoking Claude through third-party vendors) · CCAR-F: out of scope (rate limiting, quotas and pricing calculations; specific cloud provider configurations) · CCAO-F: not listed

Two decisions finish the architecture: where the model runs, and how much traffic it can take. The CCAR-P certification page lists "Claude with Amazon Bedrock" and "Claude on Google Cloud" among its catalog prep courses, and the stakeholder module of the CCAR-P prep course has architects compare "the direct API, Bedrock, Vertex, and third-party routes on latency, compliance, and cost" (Stakeholder Engagement, Lifecycle & GTM). Client code for each platform is in Claude on cloud platforms and rate-limit mechanics (errors, headers, the tier table) in Errors, retries and rate limits; this section is about the architecture those facts produce.

Five places to run Claude

As of September 2026:

Three cross-platform facts shape failover and migration plans:

• Retirement dates differ. Bedrock and Google Cloud set their own retirement schedules, so the same model can be in a different lifecycle state on each platform; the lifecycle rules are in The model lifecycle inside the program lifecycle.
• Model IDs differ. Claude Platform on AWS uses the Claude API model IDs unchanged, but Bedrock IDs carry the anthropic. prefix, Google Cloud uses @ for dated models, and on Foundry model is your deployment name (by default the Claude API model ID), so a failover path that crosses those platforms needs a model-ID map, not just a second endpoint.
• Caches do not travel. Prompt caches are isolated per workspace on the Claude API, Claude Platform on AWS and Foundry, and per organization on Bedrock and Google Cloud. Plan a failover platform's capacity as if its cache starts cold (our inference from the isolation rules).

The same anthropic Python package ships the platform clients (AnthropicBedrockMantle, AnthropicBedrock, AnthropicVertex, AnthropicAWS, AnthropicFoundry). Contract terms follow the operator: Anthropic's privacy center says use through a third-party platform is governed by that platform's terms of service, while the Claude Platform on AWS and Foundry pages say customers there are subject to Anthropic's data use terms. What changes for Claude Code on each provider (usage visibility, and managed settings in place of the claude.ai organization's model and effort controls) is covered in Choose the provider.

Choosing the platform

Regulated-industry rules (FedRAMP authorizations by product, HIPAA and the BAA, GDPR and the DPA) are in Governance and risk in delivery.

Data residency by platform

A US-only request on the first-party API, from the data residency docs:

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 1024,
    "inference_geo": "us",
    "messages": [{
      "role": "user",
      "content": "Summarize the key points of this document."
    }]
  }'

On the Claude API and Claude Platform on AWS, a residency requirement can therefore rule out a model before price is considered: requests with inference_geo on Claude Haiku 4.5 (and on Opus 4.5, Sonnet 4.5 and earlier models) return a 400 error. The cloud platforms pin location through endpoints or deployment types instead (table above).

How capacity works on the Claude API

The API applies two kinds of limit: spend limits, a maximum monthly cost, and rate limits, measured per model class in requests per minute (RPM), input tokens per minute (ITPM) and output tokens per minute (OTPM). Both depend on the usage tier: Start, Build and Scale, plus an Evaluation tier with lower limits that new organizations may start in, and a Custom tier whose limits are arranged with the account team. Organizations move up tiers automatically as they build usage history. The docs are explicit that these numbers are ceilings: "All limits described here represent maximum allowed usage, not guaranteed minimums." (Rate limits). Four rules drive most sizing:

• Only uncached input counts toward ITPM on most models: input_tokens and cache_creation_input_tokens count, cache_read_input_tokens does not. The docs' example: with 2,000,000 ITPM and an 80% cache hit rate, you could process 10,000,000 total input tokens per minute.
• OTPM counts tokens actually generated. max_tokens does not factor into OTPM, so a generous max_tokens costs no capacity; a lower cap frees OTPM only by cutting responses short.
• Limits are per model. Different models can each run up to their own limits at once. Some models share a bucket: the Opus 4.x limit covers Opus 4.8, 4.7, 4.6 and 4.5 combined, Sonnet 4.6 and 4.5 share the Sonnet 4.x limit, and Fable 5.1 and Fable 5 share the Fable limit, while Opus 5.5, Opus 5 and Sonnet 5 each have their own.
• Limits bite over short intervals. The token bucket refills continuously, and 60 RPM might be enforced as 1 request per second, so a burst can return 429s even when the minute's total fits. Sharp increases in traffic can also trip acceleration limits; ramp up gradually.

Worked sizing example

An internal assistant sends each request an 8,000-token static prefix (instructions and reference text), 500 tokens of varying input, and gets about 500 tokens of output. The target is a peak of 600 requests per minute on Claude Opus 5.5 at the Start tier, whose limits are 1,000 RPM, 2,000,000 ITPM and 400,000 OTPM. All figures below are our arithmetic from those published limits.

Read it as an architect: without caching, input tokens cap the design at about 235 requests per minute, well short of the target; with the prefix cached, output tokens become the binding limit at 800 requests per minute, leaving 25% rate-limit headroom at the 600 peak (our arithmetic). At the Scale tier (10,000 RPM, 10,000,000 ITPM, 2,000,000 OTPM) the same shape allows 4,000 requests per minute, still bound by output (our arithmetic). Two details keep the cached case honest. Cache writes do count toward ITPM, and for concurrent requests a cache entry only becomes available after the first response begins, so the docs say to wait for the first response before sending the rest when parallel requests need cache hits. The 8,000-token prefix clears the 512-token minimum cacheable length on Opus 5.5; below the minimum, prompts are silently not cached.

Rate limits are not the only Start-tier ceiling. With the prefix cached, each request costs about $0.0136 on Opus 5.5 at list prices ($0.0016 cache read, $0.0020 varying input, $0.0100 output), so a sustained 600 requests a minute spends about $8.16 a minute and would reach the Start tier's $500 monthly spend cap in about an hour (our arithmetic). Size the tier on spend as well as on RPM, ITPM and OTPM. The cost side of the same request shape, at 100,000 requests a month, is worked in Cost modeling.

Levers when a limit binds

Anthropic's workspace docs suggest the same partitioning for environments: development with lower rate limits, staging with production-like limits, and production with full rate limits and monitoring (Workspaces). An organization can have up to 100 workspaces by default (archived ones do not count, and the account team can raise the limit), and batches are isolated to the workspace that created them.

Capacity on the cloud platforms

• Amazon Bedrock: the default quota is 2 million input tokens per minute, and you can request up to 5 million input TPM and 500,000 output TPM without additional Anthropic approval. AWS enforces requests-per-minute limits on the Bedrock side; RPM adjustments go through AWS support.
• Google Cloud: global and multi-region endpoints are pay-as-you-go only; provisioned throughput requires a regional endpoint, which carries the 10% premium. The docs' regional-endpoint samples note that specific regional endpoints serve Claude Sonnet 4.6 and earlier, so confirm a newer model is offered regionally before planning provisioned capacity for it.
• Microsoft Foundry: responses do not include Anthropic's rate-limit headers, so the docs say to manage rate limiting through Azure's monitoring tools and to request increases through the Azure portal or Azure support. Several deployments of the same model under different names can hold separate configurations or rate limits.
• Claude Platform on AWS: the first-party rate limits apply, but organizations start on the Start tier and move up as they build a history of paid AWS Marketplace invoices; higher limits come through the Anthropic account representative or support, and per-workspace rate limits and fast mode are not available. Its capacity pool is separate from both the first-party API and Bedrock, which is what makes it a failover target.

Priority Tier and the service_tier parameter

Three service tiers exist: Priority, Standard and Batch. Standard is the default and is served "with best-effort availability". Priority Tier targets 99.5% uptime and falls back to standard beyond the committed capacity, but "Priority Tier capacity commitments are no longer available for purchase" (Service tiers); it is available only to organizations with an existing commitment, each defined by input TPM, output TPM, a 1, 3, 6 or 12 month duration and a specific model version, and those commitments run to the end of their contracts. Priority requests also draw on the regular rate limits (a request that would exceed them is declined), and Priority Tier does not support Claude Fable 5.1, Mythos 5.1, Mythos 5, Mythos Preview, Opus 5.5, Opus 5 or Sonnet 5. A request chooses with service_tier: "auto" (the default) uses Priority capacity when available, "standard_only" never does, and the response reports which tier served it:

import anthropic

client = anthropic.Anthropic()

message = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude!"}],
    service_tier="auto",  # Automatically use Priority Tier when available, fallback to standard
)
print(message.usage.service_tier)

Server-side fallback is not a capacity tool either. Only a safety-classifier decline triggers it: "A rate limit, overload, or server error on the requested model is returned to you as-is." (Refusals and fallback). The fallbacks parameter is also unavailable on Bedrock, Google Cloud and Foundry, which point to a client-side fallback pattern instead. What the business can be promised, and what each dependency commits to, is in Stakeholder communication and lifecycle.

How the exams frame it

• CCAR-P asks you to "Evaluate accuracy-latency trade-offs and justify configuration decisions" and to align solutions to value pillars that include "performance SLAs" (CCAR-P exam guide). In our reading, a justified configuration names the platform, the binding limit and the lever, as in the worked example.
• CCDV-F lists "invoking Claude through third-party vendors" under Claude API Mechanics; in our reading that means knowing which platform lacks which feature and how the call changes (model in the URL on Google Cloud, anthropic. IDs on Bedrock, deployment names on Foundry).
• CCAR-F lists rate limiting, quotas, API pricing calculations and specific cloud provider configurations as out of scope.

Decide

• If a compliance requirement points to a platform (the Claude Platform on AWS docs send FedRAMP High, IL4, IL5 and HIPAA-ready requirements on AWS to Bedrock), settle the platform first; not the one with the most features.
• If the design depends on fast mode, Message Batches, server tools, Agent Skills or the MCP connector, choose the Claude API, Claude Platform on AWS for everything but fast mode after checking its not-supported list, or a Foundry deployment hosted on Anthropic for server tools other than the advisor, Agent Skills and the MCP connector; not Bedrock or Google Cloud, which list them as unsupported (web search aside on Google Cloud).
• If input tokens bind capacity, cache the static prefix; if output tokens bind, shorten real outputs or split traffic across models; not a lower max_tokens, which saves OTPM only by truncating answers (the cap itself is not counted toward OTPM).
• If non-urgent volume competes with interactive traffic, move it to Message Batches, which has its own limits; not a bigger synchronous fan-out.
• If one workload must not starve another, give each its own workspace with workspace rate limits (not available on Claude Platform on AWS or the Default Workspace); not one shared workspace.
• If stakeholders need guaranteed capacity on the newest models, go to sales; not Priority Tier, which is no longer sold and does not cover them.
• If you need resilience beyond one provider, run a second platform with its own capacity pool and a model-ID map; not server-side fallback, which returns rate limits and overloads as-is.

Traps

• Treating published rate limits as guaranteed capacity. They are maximums, not minimums, and a 529 overloaded_error (the API is temporarily overloaded) can occur when the API experiences high traffic across all users.
• Sizing on the minute average. Limits may be enforced per second, and sharp ramps can trip acceleration limits.
• Expecting inference_geo: "us" to work on Claude Haiku 4.5. On the Claude API and Claude Platform on AWS the parameter needs Claude 4.6 or later; US-only Haiku 4.5 needs another platform: a Bedrock regional endpoint or US inference profile, a Google Cloud us multi-region or US regional endpoint, or a Foundry US Data Zone Standard deployment.
• Assuming inference_geo gives a separate rate limit. Limits are shared across all inference_geo values.
• Planning a failover on the same model ID string. Claude Platform on AWS takes Claude API model IDs unchanged, but Bedrock (anthropic. prefix), Google Cloud's dated models (@) and custom-named Foundry deployments need a mapped ID, and Bedrock and Google Cloud set their own retirement dates.
• Forgetting the platform premiums. Regional endpoints on Bedrock and regional or multi-region endpoints on Google Cloud cost 10% more; US-only inference through inference_geo: "us", and Foundry's US Data Zone Standard, cost 1.1x.

Cost modeling

Tested in: CCAR-P 1.6, 2.5 (caching as a prompt reuse strategy), 3.3, 4.5, 6.2 and Sample 2 · CCDV-F 5.4 Cost and Token Management, 5.3 Model Selection and Tradeoffs · CCAO-F D3.3 and Sample 2 (cost, speed and quality when choosing a model) · CCAR-F 4.5-K1, 4.5-S1, 4.5-S4 and Question 11 (the 50% batch saving and where it does not apply); API pricing calculations are out of scope (APPX-OUTSCOPE-11)

A cost model is a design input, not a finance afterthought. The CCAR-P prep course ties the move to production to a budget for cost, latency and reliability (its wording is quoted at the top of Integration patterns), and its integration module starts a use case by estimating call volume, token consumption and cost. Per-token prices, the usage fields and billing reports are taught on the API page under Cost and usage tracking; this section is about the program: what goes into the model, how to price a workload you have not built yet, and how to defend the number.

What goes into the model

The Anthropic and Accenture pilot-to-production guide says to build "a lightweight total cost of ownership model before the pilot begins": API costs, integration overhead, maintenance burden, and the opportunity cost of not deploying. It then says to "revisit it quarterly as AI economics evolve", because an architecture sized on earlier pricing can end up over-engineered (Deploying AI from pilot to production).

Two framing rules decide where a program starts. Favor volume: "A process that runs hundreds of times daily is a much better candidate, as the economics scale differently" than one that runs quarterly (Deploying AI from pilot to production). And the price criterion in Anthropic's success-criteria guidance is not a single number: it covers "the cost for each API call, the size of the model, and the frequency of usage" (Define success criteria).

The unit is a completed task

Anthropic's cost guide is blunt: "You pay for completed tasks, though, so compare models on cost per completed task." Its second rule: "Price the tail of your workload, not the median: compare models on the hardest tenth of your tasks, not the typical one." The reason is that a failed task still bills its tokens, then the retry, then whatever the failure costs downstream; on one 20-problem WideSearch run, two problems carried 43% of the spend (Optimizing for cost and intelligence).

Anthropic's own customer-support benchmark shows why. Starting from Claude Opus 4.8 at its default (high) effort, Claude Code's /claude-api hillclimb search first moved to Claude Opus 5 at low effort with a prompt audit (98.9% train accuracy, 2.6 cents per ticket), then to Claude Sonnet 5 at low effort: "cheaper still at 1 cent per ticket, but accuracy fell to 88.9%". Adding routing rules and a refund-cap cross-reference to the prompt brought Sonnet 5 back to 98.9% at the same cost, and on 14 held-out tickets the final configuration scored 90.5% against the original 78.6% "at about one fifth the cost" (Reducing cost and improving performance). The cheap configuration only became the right answer once its failure rate was fixed.

Token counts are per model, too. Claude 4.7 and later models use a tokenizer that produces approximately 30% more tokens for the same text, while Claude Sonnet 4.6 and earlier models, Claude Haiku 4.5 among them, use the previous tokenizer. Recount a prompt on each candidate model before comparing prices.

Worked example: an internal policy assistant

The workload below is an assumption chosen to be easy to follow; the prices are the Claude API list prices as of September 2026. All arithmetic is ours.

• 100,000 requests a month.
• Every request sends the same 8,000-token system prompt and policy document, then 500 tokens of varying user input, and receives 500 output tokens.
• The static part is cached with the 5-minute TTL. Traffic is steady, so assume 95% of requests read the prefix from cache and 5% write it.
• Token counts are held equal across models to isolate price; in practice, recount per model (see above).

Per request:

Per month:

What the numbers teach:

• Caching beats downsizing. Caching Opus 5.5 ($1,552) costs less than running Sonnet 5 uncached ($2,200). A 5-minute write costs 1.25x input and, in the pricing page's words, caching "pays off after one cache read" (Pricing). The 8,000-token prefix is above the minimum cacheable length on all three models (512 tokens on Opus 5.5, 1,024 on Sonnet 5, 4,096 on Haiku 4.5); shorter prompts are processed without caching and no error is returned.
• Cache reads flatten the model gap. A cache read costs 5% of input on Opus 5.5, so Opus 5.5 and Sonnet 5 both pay $0.20 per million cached tokens. Once the prefix is cached, the difference between them comes from output and uncached input.
• Residency is a multiplier, and a constraint. US-only inference (inference_geo: "us") costs 1.1x on every token category on Claude 4.6 and later: the Sonnet 5 caching total becomes $937.20. On Claude Haiku 4.5 the parameter returns a 400 error, so a US-only requirement met through inference_geo rules Haiku 4.5 out before price is considered.
• Check the tier's spend cap. Monthly caps are $500 (Start), $1,000 (Build) and $200,000 (Scale); the Custom tier has none. Only Haiku 4.5 with caching fits under Start; Sonnet 5 with caching fits under Build; Opus 5.5 needs Scale (our arithmetic). At the cap, usage pauses until 00:00 UTC on the first day of the next month unless a higher limit is granted sooner, and requests return a 429 whose error.details.error_code is enforced_spend_limit_reached, with no retry-after header.
• Capacity improves with caching too. Cache reads do not count toward input tokens per minute on most models; the rate-limit arithmetic for this same request shape is in Worked sizing example.

If part of the traffic has no one waiting (a nightly re-check of every policy answer, say), send it through the Message Batches API: 50% off every token, cached ones included. Requests still unprocessed at 24 hours expire unbilled (more of them when demand is high) and need resubmitting, so budget for resubmissions. Caching and batch discounts stack, but batch cache hits are best effort, typically 30% to 98%. The realtime-versus-batch decision itself (the 24-hour window with no latency SLA, and the CCDV-F sample question on it) is in Invocation modes.

Levers, in the order to test them

Anthropic's cost guide splits levers into free wins that do not touch quality (caching, token hygiene, a prompt audit, batching, workspace spend limits) and trade-offs (model choice, effort, output caps and task budgets, multi-model architectures). Its figures are "Anthropic-internal" and "directional, not guarantees" (Optimizing for cost and intelligence), but the order is the useful part. The sequence below is ours, built from the guide's two groups and its advice to sweep effort before pricing a stronger model or combining models:

1. Cache the repeated context. In Anthropic's measurements caching cut agent-loop cost by a factor of 2.7 to 5.3. Over a full day of real traffic, agent loops read a median 84% of their input from the cache and the top 10% read 94% or more; below about 80%, look for something breaking the cache.
2. Batch everything nobody waits for. The cost guide's routing rule, and where batch does not fit, are in Invocation modes.
3. Sweep effort on the current model. Anthropic's cost guide calls it "the cheapest experiment" it describes and adds that "most workloads end there" (Optimizing for cost and intelligence). Returns diminish at the top: on Claude Fable 5.1, the last step up to max effort on Humanity's Last Exam added about half a point for 46% more cost (Reducing cost and improving performance).
4. Price a stronger model at low effort. "A stronger model at low effort can be cheaper than a weaker model working hard (high effort)." (Reducing cost and improving performance)
5. Only then combine models. An executor that escalates hard decisions to an advisor (the beta advisor tool, available on the Claude API and Claude Platform on AWS, runs the whole strategy "server-side in one /v1/messages request"), or an orchestrator that delegates bulk work to cheaper workers. The advisor's payoff depends on the consult rate, which is fragile; the orchestrator "saved money in only two measured situations": a long cost tail on routine work, and work larger than one context window (Optimizing for cost and intelligence).

Before cutover, run the winner in shadow on a traffic slice and keep the evaluation suite running; the method is in Evaluation strategy for a program.

Seats, subscriptions and chargeback

Apps and Claude Code rollouts are priced differently from API workloads:

• Claude Enterprise (usage-based plans). Seats cover access and usage is billed at API rates (quoted, with the seat-based alternative, in Spend in the rollout plan). The Academy course describes a typical agreement as a per-member platform fee plus pooled consumption measured in tokens.
• Claude Code. Across enterprise deployments, the Claude Code docs put the average at about $13 per developer per active day and $150 to $250 per developer per month, with costs below $30 per active day for 90% of users; budget and rollout are covered in Rolling out Claude Code to an engineering organization.
• Per-use value. Anthropic's consumption guide prices individual skills against the value they create: "a call-prep skill costing $0.90 per run against $20 of value returns 20x on every use." (Claude Enterprise consumption guide)
• Chargeback. The pilot-to-production guide cites Accenture research that organizations with formal chargeback accountability "link 32 cents of every dollar of AI token spend to a quantified business outcome, six times more than those with no allocation." (Deploying AI from pilot to production)

How the exams frame it

• CCAR-P Sample 2 is the model question: an 8,000-token system prompt and policy document repeat on every request, and both latency and cost matter. The keyed answer puts the static content first and enables prompt caching, because that "lets repeated prefixes be reused, reducing both time-to-first-token and per-request cost without discarding required context." The rationale rejects truncation (it "loses needed policy"), downsizing "blindly" (it "risks quality"), and moving the policy into few-shot examples, which "does not create a cacheable, reusable prefix" (CCAR-P exam guide).
• CCDV-F 5.4 covers "token usage tracking, cost modeling, and caching techniques (prompt caching, cache check-pointing)" (CCDV-F exam guide); 5.3 adds the quality, latency and cost trade-offs between Opus, Sonnet and Haiku. On "cache check-pointing", see the box below.
• CCAO-F D3.3 asks you to "Align model selection with task requirements (cost, speed, quality)". Its Sample 2 (a high volume of short customer-reply drafts) keys "Use a faster, lower-cost model suited to straightforward, high-volume tasks", and the rationale adds that "Always using the top model (A) wastes the cost and latency budget" (CCAO-F exam guide).
• CCAR-F lists the batch discount (4.5-K1) but excludes "Rate limiting, quotas, or API pricing calculations" (CCAR-F exam guide). Its Question 11 tests where the saving stops: a manager wants to move both a blocking pre-merge check and an overnight technical-debt report to the Message Batches API. The keyed answer batches the technical-debt reports only and keeps real-time calls for pre-merge checks, because the API "has processing times up to 24 hours with no guaranteed latency SLA", which "makes it unsuitable for blocking pre-merge checks where developers wait for results, but ideal for overnight batch jobs like technical debt reports." The rationale also rejects a timeout fallback to real-time as unnecessary complexity. Task statement 4.5 adds a cost habit: refine the prompt on a sample set before batch-processing large volumes, to maximize first-pass success and reduce resubmission costs.

Decide

• If a large prefix repeats on every request, put it first and cache it before considering a smaller model; not truncation, because the Sample 2 rationale says truncation loses needed policy.
• If nobody waits for a result, price it at batch rates, because batch halves every token; if someone is blocked waiting, price it at synchronous rates, not batch (the rule is in Invocation modes).
• If two models are compared, compare cost per completed task on the hardest tenth of your tasks, with each model's own token counts; not list price per token.
• If you are unsure which lever to pull, sweep effort on the current model first; if the sweep shows a gap, price the stronger model alone at low effort; only then consider a multi-model design; not a multi-model design first.
• If the monthly estimate is near the tier's spend cap, arrange the tier increase before launch (a spend limit you set yourself can only sit below the cap); not after the first 429.
• If a data-residency or compliance requirement applies, rule out the models and platforms it excludes before comparing prices.

Traps

• API cost as the whole TCO. Integration, maintenance and opportunity cost are lines in the model too.
• Pricing the median task. The tail is where failures and spend concentrate.
• Assuming cache reads cost 10% of input everywhere. On Opus 5.5 they cost 5%, and on Fable 5.1 and Mythos 5.1 they cost 2.5%.
• Forgetting the multipliers. US-only inference and regional cloud endpoints carry premiums; the rates by platform are in Data residency by platform.
• A cheap configuration that fails more often. A failed task still pays for its tokens and its retry.
• Lowering max_tokens to save money. The cap is invisible to the model, so it does not make the model economize; in Anthropic's measurements it cut cost per attempt without lowering cost per solved task, and the CCDV-F Sample 1 rationale lists it among the answers that miss the batch-versus-realtime trade-off.
• Counting on the typical batch turnaround. Most batches finish in under an hour, but the CCAR-F guide describes a processing window of up to 24 hours with no guaranteed latency SLA, and its Question 11 rationale rejects relying on "often faster" completion for blocking workflows.

Evaluation strategy for a program

Tested in: CCAR-P 4.1, 4.2, 4.3, 4.4, 4.6 and Sample 3 · CCDV-F 4.1 Debugging and Error Handling, 2.6 Configuration Management (model version pinning, prompt versioning), 5.3 Model Selection and Tradeoffs (breaking behavior changes across releases) · CCAR-F 5.5-K1, 5.5-S2 · CCAO-F D2.1, D7.2 (at the level of checking outputs and adjusting)

The CCAR-P prep course states the program-level rule: "Build evaluations as acceptance criteria and use them as the gate before any model or architecture change" (CCAR-P prep course). The mechanics of a single eval (criteria, test sets, graders, confidence intervals, pass^k) are on the evaluation page: Success criteria and test sets, Grading methods and Evaluating agents. The five metric families CCAR-P 4.1 names ("accuracy, latency, cost, safety, security") are turned into concrete measures on that page too. This section is about running evaluation across a program: agreeing what success means, deciding what the suite gates, moving changes into production safely, and feeding production back into the suite.

Agree the criteria before the pilot

Evaluation starts from the use case definition. The pilot-to-production guide asks that it include "a defined user, task, output, and a measurable quality threshold" (Deploying AI from pilot to production). The same guide shows why that is harder than it sounds: in its contract-review example, each function wants to track something different.

Criteria that do not converge before the pilot, the guide warns, "are likely to generate competing narratives about whether the program is working." (Deploying AI from pilot to production) Three more requirements from the same source belong in the plan: a human performance baseline (one of the outputs in What discovery must produce), leading and lagging indicators with the lag between them (the guide's example: shorter PR cycle time can be a leading indicator of Claude Code value, while revenue or churn is the lagging one), and the cost of each error type at full production volume.

Layers, cadence and owners

CCAR-P 4.2 asks for "mixed methodologies", and Anthropic's evals post lists them: automated evals are one method, and "A complete picture includes production monitoring, user feedback, A/B testing, manual transcript review, and systematic human evaluation." No single layer catches every failure; the post compares evaluation to the Swiss Cheese Model and recommends "automated evals for fast iteration, production monitoring for ground truth, and periodic human review for calibration" (Demystifying evals for AI agents). At program level, each layer needs a trigger and an owner. The table assembles them from the guidance cited on this page (the arrangement and the Decides column are ours):

Two consequences follow. First, the suite also gives you operating baselines "for free": "latency, token usage, cost per task, and error rates can be tracked on a static bank of tasks" (Demystifying evals for AI agents). Second, the loop closes in both directions: every production incident becomes a regression case, and offline evaluations are updated from production data rather than treated as static. The SDLC playbook calls it a live suite: as models improve, cases that once discriminated stop doing so, and new cases come from ongoing monitoring. It also notes that, depending on the use case, some teams may prefer to run the evals offline on a set cadence rather than on every change.

The gate: what forces a re-run

• Any change to the agent or its model. Model IDs are pinned: "Anthropic does not update the weights or configuration of an existing model ID. When an updated version is available, it ships under a new model ID." The guarantee covers model IDs, not the convenience aliases the Claude API accepts for models before the 4.6 generation (an alias such as claude-sonnet-4-5 resolves to the most recent dated snapshot for that minor version). Call a pinned ID and a model change becomes a deliberate configuration change that the suite can gate (Model IDs and versions).
• Prompt changes. The SDLC playbook names a rewritten prompt as a trigger: "When a new model is swapped in or a prompt is rewritten, the eval suite says whether the agent still does the work to the same standard." Anthropic's older enterprise guidance makes the same point about prompts as assets: "Like code, prompts need version control, testing, and proper documentation." (Building trusted AI in the enterprise)
• Configuration that steers the agent. Anthropic's AI-native SDLC playbook runs the suite on any change to CLAUDE.md, skills or hooks, "since that configuration steers the agent and deserves the regression testing that code gets." (AI-native SDLC playbook)
• New Skill versions. "Require the full evaluation suite to pass before promoting new versions", and pin production requests to a Skill version (Skills for enterprise).
• Deprecation notices. Anthropic advises testing newer models "well before the retirement date of your current model." (Model deprecations); notice periods and lifecycle states are in The model lifecycle inside the program lifecycle.

A migration in Claude Code can start from the bundled Claude API skill (/claude-api migrate), which applies the model ID swap and, as needed, breaking parameter changes, then "produces a checklist of items to verify manually" (Opus 5.5 migration guide). The migration guide's own checklist for moving from Claude Opus 5 ends with the item "Re-baseline cost and latency at your chosen effort level"; its recommended changes include testing "in a development environment before switching production traffic."

/claude-api migrate this project to claude-opus-5-5

Iterating against a held-out set

Anthropic's cost guide gives a four-step measurement method (Optimizing for cost and intelligence):

1. Pull a few tasks from production logs, weighted like real traffic, write outcome checks for each (tests pass, ticket closed, row count correct), and record cost per task beside the score.
2. Baseline the model tiers across effort levels, not only the default, and plot score against spend. A multi-model configuration must beat the single model's whole curve.
3. If the curve shows a gap effort cannot close, add the multi-model strategy that fits and re-run the suite.
4. "Run the winner in shadow on a traffic slice before cutover, then keep the suite running."

The Claude API skill in Claude Code automates parts of this loop (Reducing cost and improving performance):

The held-out split is the point. In the post's run, the final configuration was scored on "the 14 held-out tickets the search never saw"; a score on the train cases Claude read while tuning would flatter the result (our reading). The worked result is in Cost modeling. One reading rule from the same post, which applies on a non-saturated evaluation: "a flat performance-cost curve across effort levels suggests that the task is not bound by thinking compute; increasing effort is not beneficial."

A/B testing a live system

An A/B test compares variants on real user traffic. It measures actual user outcomes ("retention, task completion") and controls for confounds, and it is also slow: "days or weeks to reach significance", it needs enough traffic, it tests only changes you deploy, and it gives less signal on why a metric moved unless you also review transcripts (Demystifying evals for AI agents). Run it after offline evals pass, for significant changes. StubHub, in the pilot-to-production guide, tested several models against resolution-rate and satisfaction benchmarks before committing to production.

The prep course's integration module asks you to "Plan and interpret an A/B test or structured experiment on a live Claude system, setting the hypothesis, selecting metrics, estimating the required sample size, and reading a result without overclaiming" (Enterprise Integration & Production). A one-page plan built from those requirements (the layout is ours):

Hypothesis:  variant B changes <primary metric> by at least <effect> versus baseline A
Metrics:     primary outcome; guardrails (latency, cost per task, safety flags)
Sample size: from a power analysis for that effect
Exposure:    progressive ramp on a traffic slice; rehearsed rollback path
Read-out:    mean difference with its confidence interval; no claim beyond the tested traffic

• Baseline. Anthropic's success-criteria page defines A/B testing as a comparison "against a baseline model or earlier version." (Define success criteria and build evaluations)
• Statistics. A 95% confidence interval is the mean plus or minus 1.96 × SEM; paired comparisons and power analysis are covered in Success criteria and test sets on the evaluation page. On small evals, small real differences "will likely go undetected" (A statistical approach to model evaluations).
• Rollout mechanics. Anthropic's older enterprise guidance says to roll out progressively and "Set up infrastructure for A/B testing" (Building trusted AI in the enterprise); for stateful agents, Anthropic's research system uses rainbow deployments, "gradually shifting traffic from old to new versions while keeping both running simultaneously." (How we built our multi-agent research system)
• One run is not evidence. The same guidance lists "Make a decision based on a single evaluation test" among the things not to do (Building trusted AI in the enterprise).

What production monitoring watches

CCAR-P 4.6 asks you to "Monitor system performance using logging and observability tools". Anthropic's older enterprise guidance defines the scope: track "not just basic metrics like response times and error rates, but also LLM-specific concerns like token usage and output quality" (Building trusted AI in the enterprise). The signals and where each comes from, as of September 2026:

Telemetry setup for agents is in Reliability engineering for Claude applications; the organization-wide Claude Code configuration is in Rolling out Claude Code to an engineering organization.

When production disagrees with the suite

In that postmortem Anthropic said it had developed more sensitive evaluations, which it would keep improving, and that it would run quality evaluations continuously on true production systems. CCAR-P 4.4 names three causes to tell apart, "prompt failure, hallucinations, model mismatch"; how to separate them, and how to tell a model-output problem from an integration-layer one, is in Debugging: model or integration.

Decide

• If stakeholders define success differently, reconcile the criteria and their thresholds before the pilot; not after launch, when they become competing narratives.
• If any model, prompt, CLAUDE.md, skill or hook changes, run the suite before it ships; not a spot check.
• If the model must not change underneath you, call a pinned model ID and pin Skill versions (serving infrastructure can still shift behavior slightly); not a pre-4.6 alias or an unversioned Skill.
• If a variant wins offline and the change is significant, shadow it or A/B test it on a traffic slice before cutover; not a full switch.
• If an A/B result is small, check the confidence interval and sample size before claiming a win; not the raw difference from one run.
• If a production incident occurs, add it to the suite as a regression case; not only a hotfix.
• If quality drops after a document refresh with the model unchanged, inspect retrieval first (Keeping the index correct); not the model.

Traps

• Treating the suite as a one-off launch check. It is the gate for every later change and the source of cost and latency baselines.
• Optimizing on the cases you read. Score the final configuration on held-out cases.
• An A/B test as the first check. It is slow and reaches users; offline evals come first.
• Blaming the model when only the data changed. The CCAR-P Sample 3 distractors (silently changed weights, a temperature that is too low, a shrunken context window) are worked through in Keeping the index correct.
• Assuming a pinned model ID can never behave differently. The weights do not change, but serving infrastructure can.
• Monitoring with no owner. The pilot-to-production guide lists "Who owns continuous monitoring and degradation alerting?" among the ownership decisions to assign; alerts nobody is accountable for do not get acted on (our reading).

Governance and risk in delivery

Tested in: CCAR-P 5.1, 5.2, 5.3, 5.4, 5.5, 3.2, 6.4 and Sample 1 · CCAO-F D6.1, D6.2, D6.3, D6.4, D2.4 (the user-level view) and Sample 3 · CCDV-F 7.1 AI Application Security, 7.2 Guardrails and Safe Deployment and Sample 2 · CCAR-F 1.4-K1, 1.4-K2 and Question 1

Governance is cheapest before the pilot. The pilot-to-production guide says programs that treat compliance as a late-stage gate find, during the production build, that regulatory requirements reshape the architecture they designed during the pilot, while "The programs that treat compliance as a design constraint avoid this entirely because they surface those requirements pre-pilot, when changes are decisions rather than delays." It adds that testing alone does not get you there: "Organizations that try to satisfy compliance requirements through testing alone consistently discover the gap at the worst possible time" (Deploying AI from pilot to production). This section is the delivery view: what to decide first, how to prove each control exists, how much human oversight each output needs, and which failure modes to design against. The controls themselves are taught in Data retention, training and compliance, Admin and governance controls and Anthropic's Usage Policy.

Before the pilot: classify, then rule out

Classification happens in discovery: sort the data by sensitivity, map the access rules the system inherits from it, ask what Legal and Compliance will actually enforce, and bring those reviewers in before the pilot launches. Those steps, with the pilot-to-production guide's wording, are questions 1, 2 and 4 of The discovery questions, in order. One delivery detail to add: in Claude Enterprise, a connector passes through the member's own permissions in the source system.

Then rule out. The prep course's solution-design module puts governance and regulated-industry constraints before any other trade-off (quoted in the same discovery list). As of September 2026, these requirements narrow the choice of surface and platform:

FedRAMP is a property of the hosting service, not the model: "FedRAMP and DoD Impact Levels are certifications for cloud services (IaaS, PaaS, SaaS). AI models are software components, not cloud services." (Public sector FAQs). The same FAQ says Claude models deploy within authorized environments and customers maintain their compliance posture through the hosting platform.

On the exam, CCAR-P 5.4 is "Ensure compliance with regulations (e.g., GDPR, HIPAA, FedRAMP)". Apply the rule-out step above to it: find which options the regulation excludes, then compare what remains. The product specifics in the table are date-sensitive (as of September 2026), so check the current docs before a real engagement.

Map every obligation to a control, an owner and evidence

The prep course's responsible-AI module sets the standard: "Map each compliance obligation to a named control, an owner, and an evidence artifact, so the architecture can be accurately audited" (Responsible AI, Safety & Risk for Architects). A register built from controls and owners Anthropic's material names, with product details as of September 2026 (the layout is ours):

Two rules make the register real. An owner must exist: "A decision with no owner is one of the quickest ways a rollout stalls." And a record has to be read: the Academy course warns that a record nobody reviews is not a control, which is why the Compliance API belongs in the SIEM review you already run (Owners and intake; Visibility: what you can measure).

Match human oversight to consequence

The pilot-to-production guide: "Production governance requires a tiered approach: fast handling for routine, low-consequence outputs and more scrutiny for the ones that carry real weight." (Deploying AI from pilot to production)

• Anthropic's Usage Policy sets a floor for high-risk uses. Its High-Risk Use Case Requirements "apply to specific consumer-facing use cases that pose an elevated risk of harm", covering legal, healthcare, insurance, finance, employment and housing, academic testing, accreditation and admissions, and media or professional journalistic content. Where Claude provides advice, recommendations or subjective decisions directly affecting individuals or consumers, "a qualified professional in that field must review the content or decision prior to dissemination or finalization"; where outputs go directly to individuals or consumers, the use of AI must be disclosed: "This disclosure must be provided at a minimum at the beginning of each session." Separately, every consumer-facing chatbot or interactive AI agent must disclose that it is AI, and agentic use cases must still comply (Usage Policy). In the tier table, the review requirement maps to Reviewed or Advisory (our mapping).
• Checkpoints are audited too. "If the catch rate is low and the cost is high, the checkpoint can be automated, sampled, or removed." (Deploying AI from pilot to production). Name who has the authority to remove or automate review checkpoints as the system matures.
• Deterministic rules need code, not prompts. CCAR-F 1.4-K2: when deterministic compliance is required, "prompt instructions alone have a non-zero failure rate" (CCAR-F exam guide). Where a step must always happen, enforce it in code: a hook or a prerequisite gate (the tools 1.4-K1 names), or in Claude Code a permission rule, which Claude Code enforces rather than the model. The CCAR-F Question 1 rationale gives the reason: "programmatic enforcement provides deterministic guarantees that prompt-based approaches cannot."
• Routing by confidence (who reviews which item, and how thresholds are calibrated) is taught in Human review and confidence calibration.

Design the safety stack to fail closed

The prep course asks you to "Design the full safety stack for a Claude system, placing input screening, output screening, and tool-call authorization so the system fails closed rather than open" (CCAR-P prep course). The layers, roughly in the order a request meets them, with the Anthropic guidance behind each (the arrangement is ours):

Inference hooks are in beta and, as of September 2026, cover the prompt side only: "Today the only hook event is prompt", the verdict timeout defaults to 5 seconds, and response-side enforcement is planned. The organization's failure handling setting decides what happens when the AI security server is unreachable, returns an error or misses the timeout: block the request (fail closed) or let it proceed without inspection (fail open) (Inference hooks). The course's framing for the whole stack is to "Distinguish between what the model's training reduces and what your application layer must still enforce" (Responsible AI, Safety & Risk for Architects). Techniques are in Prompt injection, Jailbreaks and guardrail layering and Least privilege for tools and agents.

How CCAR-P Sample 1 frames it. A support agent can read tickets, draft replies, issue refunds and delete accounts, but staff only read and draft. The keyed answer removes the refund and delete tools: "Least privilege means removing capabilities the role does not require, eliminating the attack surface rather than monitoring or guarding it." The rationale rejects the other options: "Logging (A) and confirmations (C) are detective/compensating controls, not removal of unnecessary privilege; model size (D) is unrelated to authorization scope." (CCAR-P exam guide)

The same logic runs through the other exams' security and governance samples:

• CCDV-F Sample 2 (Domain 7). An agent summarizing user-submitted web pages meets hidden text telling it to reveal its system prompt. The keyed answer treats page content as untrusted input, keeps it separate from trusted instructions, and uses guardrails or hooks; the rationale rejects the alternatives because "Temperature (A) is irrelevant to injection; a polite request (C) is not an enforceable control; a more instruction-following model (D) can be more susceptible, not less." (CCDV-F exam guide)
• CCAO-F Sample 3 (Domain 6). A spreadsheet of customer names and account numbers meets a policy against sharing regulated personal data. The keyed answer removes or anonymizes the identifiers before upload; the rationale adds that "instructing the model not to retain data (C) does not satisfy the policy control" (CCAO-F exam guide).

Name the failure modes in the design

The prep course's production checklist includes "naming failure modes for the chosen architecture, and articulating the mitigation for each" (Enterprise Integration & Production). The pilot-to-production guide defines an error mode as "a specific, recurring category of failure" and asks what each one costs at full production volume (Deploying AI from pilot to production).

Incident response is part of the design, not the runbook written after the first incident. The guide's questions: who is notified, what the remediation path is, "Who has authority to pause the system?", and who tells affected parties; "Organizations that handle incidents well have documented answers to these questions before go-live." (Deploying AI from pilot to production)

Fairness and transparency

CCAR-P 5.5 asks for "bias, fairness, transparency" (CCAR-P exam guide). The prep course's version is to "Identify where unequal outcomes can arise within a system and define the explanations required for users, regulators, and your own debugging team" (Responsible AI, Safety & Risk for Architects).

• Make it measurable. Anthropic's older enterprise guidance turns ethics into a metric: "less than 0.1% of outputs flagged for bias across 10,000 interactions." (Building trusted AI in the enterprise)
• Test by perturbation. Anthropic's discrimination evaluation generates decision prompts across 70 scenarios and varies the demographic details in each; its released dataset varies age, gender and race for 135 examples per scenario (discrim-eval dataset). The paper found several prompt interventions "quite effective", especially "Illegal to discriminate", "Ignore demographics" and the two combined. The results are for Claude 2.0 (December 2023), and the authors caution that "we do not believe that performing well on our evaluations is sufficient grounds to warrant the use of models in the high-risk applications we describe here" (Evaluating and mitigating discrimination).
• Show the reasoning. Anthropic's agent principles include making the agent's planning steps visible (Building effective agents). For users, disclosure that they are dealing with AI is a Usage Policy requirement for consumer-facing agents.
• Govern the program. The same older guidance recommends an AI review board, ethical guidelines, and transparent processes for model evaluation and incident response (Building trusted AI in the enterprise). Anthropic itself holds ISO/IEC 42001:2023 certification for AI management systems (Anthropic certifications).

Decide

• If a role does not need a capability, remove it; not logging or a confirmation step, because the Sample 1 rationale calls those detective or compensating controls.
• If a regulation applies, rule out the surfaces and platforms it excludes first; not after comparing cost and latency.
• If an obligation lacks a named owner or an evidence artifact, it is not yet a control.
• If a consumer-facing use case in a Usage Policy high-risk domain gives advice or decisions directly affecting individuals, use the Reviewed or Advisory tier (our mapping); not Automated or Sampled.
• If a task does not need regulated identifiers, remove or anonymize them before they reach Claude; not an instruction telling the model not to retain them (CCAO-F Sample 3).
• If a review checkpoint catches little at high cost, automate, sample or remove it, with the authority to do so named in advance.
• If a rule must hold every time, enforce it in code (hook, permission rule, prerequisite gate); not a prompt instruction.
• If untrusted content reaches the agent, isolate it from trusted instructions and gate sensitive tools; not a system-prompt request asking users to behave.

Traps

• Treating FedRAMP or HIPAA as a property of the model. It comes from the hosting service and the arrangement you sign.
• Assuming ZDR covers every product. Managed Agents is not covered, and Covered Models require 30-day retention.
• Assuming the first-party API offers an EU inference geo. It offers "us" and "global".
• Compliance by testing alone. Constraints belong in the architecture.
• A bigger model as a security fix. CCAR-P Sample 1: model size "is unrelated to authorization scope". CCDV-F Sample 2: a more instruction-following model "can be more susceptible, not less."
• Asking for good behavior as a control. A system-prompt line asking users not to include malicious instructions "is not an enforceable control" (CCDV-F Sample 2), and telling the model not to retain data "does not satisfy the policy control" (CCAO-F Sample 3).

Stakeholder communication and lifecycle

Tested in: CCAR-P 6.2, 6.3, 6.4, 6.5 (6.1 is in Discovery and requirements), 1.6 (performance SLAs) · CCDV-F 2.2 Systems Life Cycle, 2.6 Configuration Management (model version pinning, prompt versioning) · CCAO-F D4.5 · CCAR-F: not listed

The CCAR-P prep course describes this work as the conversations "that decide whether a working system actually ships, adopts, and outlasts your involvement" (CCAR-P prep course). The technical design can be right and the program can still fail: the pilot-to-production guide cites Accenture data that "42% of organizations rely on shared IT and finance accountability with no single owner responsible for AI costs and outcomes." (Deploying AI from pilot to production). Discovery itself is covered in Discovery and requirements; this section takes the program from design to its long operating life.

The five phases the guide names

CCAR-P 6.5 lists "discovery, design, handoff, monitoring, iteration" (CCAR-P exam guide). What the architect produces in each comes from Anthropic's prep course and delivery guides; the "You are done when" column is our reading of those sources, not an official checklist:

The same idea appears in CCDV-F 2.2 as the systems life cycle, which the guide describes as "Systems life cycle management concepts and frameworks used to develop, implement, operate, and maintain IT systems." (CCDV-F exam guide). NIST's glossary defines the system development life cycle as the scope of activities from a system's initiation, through development and acquisition, implementation, and operation and maintenance, to its disposal (NIST glossary). Anthropic's AI-native SDLC playbook groups its plays into six non-linear stages (Plan, Design, Build, Test, Deploy, Maintain) and turns the traditional linear flow into a loop: continuous evals woven through implementation replace QA gates at stage boundaries, each stage ends by committing an artifact (intent.md, spec.md, plan.md, the diff and its tests, the PR with its review findings, the incident record), and "The chain of commits is also the audit trail: who asked for what, what the agent produced, and who approved it." (AI-native SDLC playbook). When agents speed up the build phase, the bottleneck moves to the stages on either side of it, mainly plan, review and test, and deploy, which still run at human speed.

From pilot to production

Pilots succeed partly because they skip production rigor, so the pilot-to-production guide's fix is to build "the governance, operational ownership, delivery stability, and economics as a part of the pilot design itself" (Deploying AI from pilot to production). Four instruments carry a pilot across:

• A documented go/no-go process, written before the pilot: who has decision rights, what triggers escalation, how wins and setbacks are communicated, and the rollout sequence.
• Graduation criteria. Anthropic's older enterprise guidance names three groups of potential graduation criteria: performance thresholds (accuracy, speed and latency, cost efficiency), operational readiness (system stability, support infrastructure, team capability) and risk management infrastructure (security compliance, data protection, operational controls).
• A parallel run. Anthropic's older enterprise guidance suggests running the AI-enhanced process alongside the existing workflow until performance and reliability are proven (Building trusted AI in the enterprise).
• An owner with real authority. The pilot-to-production guide treats decision rights, escalation authority and executive backing as three separate requirements; missing any one of them can stall the program (Deploying AI from pilot to production).

In the pilot-to-production guide's words, mature organizations "stopped treating AI deployment as a project with an end date and started treating it as an ongoing initiative with dedicated governance, metrics, and program management." (Deploying AI from pilot to production)

A handoff that survives your absence

The course's lifecycle outcome is to "design a handoff that survives your absence", because "a design that only the Architect understands falls apart the moment they leave the room." (CCAR-P prep course). Before you leave, every running responsibility needs a name. The pilot-to-production guide's "assign" questions make a usable checklist (Deploying AI from pilot to production):

• "Who owns continuous monitoring and degradation alerting?"
• "Who has authority to remove or automate review checkpoints as the system matures?"
• "Who is the human supervisor, exception handler, or system improver at scale?"
• "Who is accountable when model versioning or deprecation affects deployed systems?"
• "Who owns ongoing AI program management as a function?"

The receiving team also needs judgment: the ability to identify incorrect outputs, decide which cases require escalation, and detect system drift before it becomes a production issue, which the pilot-to-production guide says takes training and role design. For internal rollouts, Anthropic's champion kit warns that "Adoption that depends on a single person is fragile." (Champion kit); its observable signal that the handoff is working is in Enablement and review discipline (7.2).

The model lifecycle inside the program lifecycle

Model IDs have a lifecycle of their own, and the pilot-to-production guide asks who "is accountable when model versioning or deprecation affects deployed systems" (Deploying AI from pilot to production), so the program plan has to include model changes. The facts, as of September 2026 (Model deprecations, Model IDs and versions):

CCDV-F 2.6 names "model version pinning". In current docs, "Every Claude model ID is a pinned snapshot, including the dateless IDs used from the 4.6 generation on." (Models overview), so on the API, pinning means recording the exact model ID in configuration and changing it deliberately. Claude Code on a cloud provider pins through environment variables, shown in Choose the provider. Migration mechanics are in Model versions, deprecation and migration; the eval gate is in Evaluation strategy for a program.

Communicating decisions and trade-offs

The stakeholder module's rule: "Present an architectural trade-off in terms a business stakeholder can act on by pairing each choice with a cost, a risk, and what a reversal would take, so executive and procurement reviews reach a decision instead of stalling" (Stakeholder Engagement, Lifecycle & GTM). Different audiences need different things:

Give reversal cost its own line. Some choices are cheap to undo: a model ID is a configuration change behind an eval gate. Others are not. Anthropic's Claude Enterprise course names four settings that are hard to undo: domain claiming (once on, it can't be reversed), organization topology (merging or splitting organizations later means re-provisioning every affected member; the course's One organization or many lesson adds that adding a second organization later is cheaper than pulling apart one you consolidated too much), group structure mapped from your identity provider, and data retention (conversations already deleted under a shorter window are gone for good) (Deploying Claude Enterprise with confidence). Granting a surface is cheap, while "The expensive direction is taking one away" (Surfaces each group gets). On the API, "Workspace geo is set when you create a workspace and can't be changed afterward." (Data residency). More settings that are hard to undo (HIPAA readiness, CMEK, turning off memory for the organization) are listed in Admin and governance controls.

Using the policy-assistant example from Cost modeling, an option statement can look like this. It is illustrative: the layout and the risk and reversal wording are ours, and the figures are that section's arithmetic at list prices as of September 2026:

Option B: Claude Sonnet 5 with prompt caching
  Cost:     about $852 a month at 100,000 requests (Opus 5.5 with caching: about $1,552)
  Risk:     quality on the hardest tenth of requests not yet measured; eval before commit
  Reversal: change the model ID and re-run the eval suite; no data migration

State value and limits honestly. The CCAO-F guide asks Associates to "Communicate Claude's value and limitations to stakeholders" (CCAO-F exam guide), and Anthropic's own material models the tone: usage metrics "tell you Claude is being used, not what that use produced" (Adoption signals), and on hallucinations Anthropic says "this is an ongoing challenge for the entire AI field, not at all a solved problem." (Why do AI models hallucinate?). Adoption numbers are diagnostics: "The month you turn a diagnostic into a quota, members optimize for the number instead of the work." (Adoption signals)

Expectations and SLAs

CCAR-P 6.3 says "(including SLAs)" (CCAR-P exam guide). An SLA you give stakeholders is one you build, from what each dependency actually commits to (as of September 2026):

Close the gap with design and measurement: write the SLA as a percentile target (one of Anthropic's example success criteria puts 95% of responses under 200 ms, in Define success criteria), specify "reliability patterns (retries, fallbacks, circuit breakers)" as the prep course asks (Enterprise Integration & Production), note that the official SDKs retry transient failures twice by default with exponential backoff, honoring the retry-after header when present (Errors), and consider a second platform with its own capacity pool as a failover target (Choosing the platform). Point stakeholders to status.claude.com, which as of September 2026 tracks six components (claude.ai, Claude Console, Claude API, Claude Code, Claude Cowork and Claude for Government) and offers email, text message, Slack, Microsoft Teams, webhook, Atom and RSS subscriptions. Capacity mechanics are in Deployment platforms and capacity.

Then run the feedback loop on a cadence. Anthropic's evals guidance triages user feedback constantly and reads sampled transcripts weekly (Demystifying evals for AI agents); the Building AI Agents in the Enterprise guide measures adoption weekly in the pilot phase, with qualitative feedback collected alongside the numbers; and the Claude Enterprise Administrator Guide suggests a brief retrospective at each phase of rollout and a regular reporting cadence such as quarterly business reviews. The Administrator Guide's example targets include weekly active users at 70% of licensed seats, 3+ hours saved per user per week (user survey) and a satisfaction score of 4.0+ out of 5.0 (quarterly survey), and it says to shift from tracking activity metrics to demonstrating business value as the rollout scales.

The documentation set

CCAR-P 6.4 asks you to "Document architectures and provide implementation guidance" (CCAR-P exam guide). The artifact names and grouping below are ours; what each one records comes from Anthropic's material:

Decide

• If a decision will reach an executive or procurement review, present each option with its cost, its risk and what reversing it would take; not a capability comparison.
• If a choice is hard to reverse (domain claiming, organization topology, group structure, retention, workspace geo), make it deliberately and early, with the owner who will live with it.
• If a stakeholder wants an uptime guarantee, state what each dependency commits to and design the gap closed (retries, fallbacks, a second platform) or contract for capacity; not a promise the platform does not make.
• If a model you depend on is deprecated, treat the notice window as a scheduled migration with an eval gate; not an emergency.
• If you are about to hand over, name an owner for monitoring, checkpoints, supervision, deprecations and program management; not a document that only you can interpret.

Traps

• Treating the launch as the end. In the pilot-to-production guide, mature organizations run AI deployment as an ongoing initiative with dedicated governance, metrics and program management.
• Promising an SLA the platform does not offer. The standard tier is best-effort.
• Adoption quotas. Turn a diagnostic into a quota and members optimize for the number instead of the work.
• Assuming a dateless model ID updates itself. It is a pinned snapshot; you move when you change it.
• Owners without authority. Decision rights, escalation authority and executive backing are separate requirements.

Rolling out Claude Code to an engineering organization

Tested in: CCAR-P 7.1, 7.2, 7.3 · CCDV-F 3.1 Claude Code Operation (CLAUDE.md hierarchy, repository initialization, settings.json), 2.6 Configuration Management (CLAUDE.md files, settings.json, model version pinning) · CCAR-F 3.1-K1, 3.1-K2, 3.1-S1, 3.1-S4, 3.2-K1, 3.2-S1, 2.4-K1, 2.4-K2, 2.4-S1, 2.4-S2, 3.6-K4, Exercise 2 steps 1 and 4 (Configure Claude Code for a Team Development Workflow) and Question 4 (Scenario 2, Code Generation with Claude Code) · CCAO-F: not listed

This section follows a Claude Code rollout from the provider choice through what the repository carries and what policy enforces, spend, enablement and first-line support. CCAR-P Domain 7 (7% of the exam) is the smallest domain, and its first objective names the tool: "Configure Claude tools and environments for teams (e.g., Claude Code)" (CCAR-P exam guide). The matching prep module, Team Enablement & Operational Productivity (listed at 45 minutes), states its goal in one line: "Learn to enable a team to adopt a live Claude system and run it without depending on you." Its three learning objectives pair off with the three Domain 7 objectives (the pairing is ours; both texts are verbatim):

The configuration mechanics behind the rollout are taught in Managed settings for organizations, CLAUDE.md and the memory hierarchy, MCP servers in Claude Code, Monitoring, usage and cost and Claude Code security controls.

The decisions, in order

Anthropic's administrator page "walks through the deployment decisions in order" (Set up Claude Code for your organization). With the pilot and launch steps from Anthropic's cost and enablement material added (the merged sequence is ours):

1. Choose the API provider: billing, authentication, the compliance posture you inherit, and which features developers get.
2. Decide how settings reach devices: server-managed settings from the admin console, an MDM or OS-level policy, or a managed-settings.json file.
3. Decide what to enforce: permission rules, sandboxing, MCP and plugin allowlists, login enforcement, model and effort limits.
4. Set up usage visibility before anyone gets access: "That’s why you set visibility up before members get access, not after" (Visibility: what you can measure).
5. Review data handling: retention, ZDR, and whether a gateway is needed for request-level audit logging.
6. Pilot, then expand in waves: a small pilot group establishes a usage baseline before the wider rollout (Manage costs effectively).
7. Verify, launch and enable: /status on a developer machine, a launch message, a staffed channel, champions.

Choose the provider

What each choice brings with it:

• Some features need claude.ai accounts. Cloud sessions, Routines, Code Review, Remote Control and the Chrome extension "aren't available through Console API keys or cloud-provider credentials alone" (Set up Claude Code for your organization), so a cloud-provider rollout must decide whether developers also need Teams or Enterprise seats. Enterprise adds domain capture, role-based permissions and Compliance API access over Teams.
• The CLI works everywhere; organization controls do not. "The Claude Code CLI and everything that runs locally work on every provider." (Feature availability). Claude Enterprise's organization-level model and effort controls in admin settings do not reach sessions on Bedrock, Google Cloud's Agent Platform, Foundry or Claude Platform on AWS; use managed settings there (availableModels, model, maxEffortLevel). Anthropic's analytics do not see cloud usage either, so use OpenTelemetry or a gateway.
• A gateway centralizes, and you run it. Credentials, usage tracking, cost controls and audit logging move to one place, but "the gateway becomes infrastructure your organization operates." (LLM gateway). Give each developer their own gateway credential so usage is attributed and offboarding is one revocation. Anthropic's self-hosted Claude apps gateway signs developers in through browser SSO and has no service-token flow, so CI pipelines with no developer to approve the sign-in are configured against the provider directly (Gateways).

On Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry or Claude Platform on AWS, pin model versions before the rollout with ANTHROPIC_DEFAULT_FABLE_MODEL, ANTHROPIC_DEFAULT_OPUS_MODEL, ANTHROPIC_DEFAULT_SONNET_MODEL and ANTHROPIC_DEFAULT_HAIKU_MODEL. Without pinning, aliases resolve to Claude Code's built-in default for that provider, "which can lag the newest release and may not yet be enabled in your account"; "Pinning lets you control when your users move to a new model." (Enterprise deployment overview). On Bedrock as of September 2026, the unpinned opus alias resolves to Opus 5.5 from Claude Code v2.1.280 (older clients resolve it to Opus 5, Opus 4.8 or Opus 4.6, depending on version) and the unpinned sonnet alias to Sonnet 4.5. The docs' Bedrock example pins each alias (Amazon Bedrock):

export ANTHROPIC_DEFAULT_OPUS_MODEL='us.anthropic.claude-opus-4-8'
export ANTHROPIC_DEFAULT_SONNET_MODEL='us.anthropic.claude-sonnet-4-6'
export ANTHROPIC_DEFAULT_HAIKU_MODEL='us.anthropic.claude-haiku-4-5-20251001-v1:0'

What lives in the repository and what lives in policy

The repository carries team conventions that anyone can improve through review. Managed settings carry the organization's rules: "Claude Code enforces organization policy through managed settings that take precedence over local developer configuration." (Set up Claude Code for your organization)

When the same key is set in more than one settings file, the value from the highest level wins (array settings such as permission lists merge instead, as below): managed settings, then command-line arguments, then .claude/settings.local.json, then .claude/settings.json, then ~/.claude/settings.json (Settings). Details are in Settings files and precedence.

• Shared means committed. CCAR-F Question 4 puts a team /review command in .claude/commands/ in the repository because "These commands are version-controlled and automatically available to all developers when they clone or pull the repo." (CCAR-F exam guide). The mirror image is CCAR-F 3.1-S1: a new team member misses instructions that live in someone's ~/.claude/CLAUDE.md.
• Managed lists only grow. "Array settings such as permissions.allow and permissions.deny merge entries from all sources, so developers can extend managed lists but not remove from them." For fallbackModel, availableModels and modelPicker, the managed value replaces lower layers rather than merging. The Windows HKCU registry is writable without elevation, so "treat it as a convenience default rather than an enforcement channel." (Set up Claude Code for your organization)
• One team owns MCP. "We recommend that one central team configures MCP servers and checks a .mcp.json configuration into the codebase so that all users benefit." (Enterprise deployment overview). CCAR-F contrasts two MCP scopes: project-level .mcp.json for shared team tooling and user-level ~/.claude.json for personal or experimental servers (2.4-K1). The current docs add a third, local scope, which is the default, is also stored in ~/.claude.json, and is the scope they recommend for experimental configurations. On the exam, use the guide's two-scope model.

Put telemetry in the same policy so it is on from the first session. The docs' organization-wide example for managed settings (metrics and labels are covered in Monitoring, usage and cost):

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.example.com:4317",
    "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer example-token"
  }
}

A managed OTEL_EXPORTER_OTLP_* value removes conflicting developer-set variables at startup, which locks the destination.

Spend in the rollout plan

Say which billing model a statement applies to, because Anthropic's pages describe two. The Claude Enterprise Administrator Guide says "Claude Code access requires a Premium seat (legacy model), or a Chat + Code or Claude Enterprise seat (usage-based model)."

• Usage-based Enterprise: "the seat fee covers access only, and all usage is billed separately at API rates", and "There are no per-seat usage limits and no included token allowance." (What is the Enterprise plan?). Spend limits default to $0 when you assign seats, so set them as part of seat assignment (Claude Enterprise Administrator Guide).

• Seat allowance: Claude Code's cost page says that on Teams and Enterprise plans each member's Claude Code usage "draws from a per-seat allowance that resets on a rolling five-hour window and a weekly window", shared with Claude chat and Cowork and sized by seat tier (Standard or Premium); to let members continue past it, you turn on usage credits and set spend limits (Manage costs effectively). That description matches seat-based plans, not the usage-based Enterprise plan above.

• Waves, not day one. "Giving everyone Claude Code and Cowork access on day one is the fastest way to generate unexpected consumption." Claude Code and Cowork consume tokens much faster than chat. Start with "RBAC group-level limits and per-user limits"; the organization-level limit is a hard ceiling, and hitting it affects everyone simultaneously. A group that consistently approaches its limit should be investigated before the limit is raised (Claude Enterprise consumption guide).

• The default model is a spend lever. "Because most members run the model they see when they start a new task, the default steers most of your spend" (Surfaces each group gets). In the course's worked example, lowering the default model on the Engineering role fixed a spend spike and the cap stayed where it was (Managing spend).
• Know the usual causes. On an API or cloud-provider plan, unexpectedly high Claude Code spend "usually traces back to long sessions that were never cleared or to Opus left as the default model." Agent teams are disabled by default, and their token use scales with the number of active teammates (Manage costs effectively).
• Size the budget. Anthropic's averages across enterprise deployments (about $13 per developer per active day) and per-user rate-limit guidance are in Monitoring, usage and cost; the per-developer ranges sit with the other seat and subscription costs in Seats, subscriptions and chargeback.

Enablement and review discipline (7.2)

• Make installation trivial. The docs say that where the development environment is custom, a "one click" way to install Claude Code is key to growing adoption across an organization (Enterprise deployment overview).
• Start with guided usage. The same page suggests new users start with codebase Q&A or smaller bug fixes and feature requests, ask Claude Code to make a plan, and check its suggestions, letting it run more agentically as they learn. For repository initialization, /init generates a starting CLAUDE.md by analyzing the codebase, and if a CLAUDE.md already exists it suggests improvements rather than overwriting it (Memory).
• Launch properly. The communications kit's pre-launch checklist: a #claude-code channel linked in the message, the install command tested on at least one machine in your environment, a security and data-handling link, one concrete first task from your own codebase, a named owner for the channel for the first 48 hours ("Unanswered launch-day questions kill momentum"), and a C-suite sponsor to send or co-sign the announcement, because "Exec-sent launches consistently see higher first-week adoption than admin-sent ones" (Communications kit).
• Grow champions, then hand off. A champion shares what they discover, is the person people ask, and grows the circle. The 30-day playbook ends in week 4 by identifying a second champion, and it has worked when "questions in the channel are being answered by people other than you." Security and data-handling questions go to the administrator, and "champions should not improvise this answer." Running /team-onboarding in a well-used project produces a setup guide a new teammate can paste as their first message (Champion kit).

The review discipline in Anthropic's AI-native SDLC playbook (AI in the PR review loop): every PR gets the same review passes with findings ranked by severity; "Findings do not approve or block a PR on their own, and branch protection still requires approval from a code owner"; "Anything the agent writes arrives as a PR through branch protection, and the agent has no route to push to main" (CI/CD integration and deployment); and a mistake flagged twice becomes a CLAUDE.md correction. CCAR-F 3.6-K4 adds why the reviewer should be a separate instance: "the same Claude session that generated code is less effective at reviewing its own changes compared to an independent review instance" (CCAR-F exam guide). Review prompts are in Automated code review that engineers trust.

First-line support: symptom to cause (7.3)

The checks and fixes below come from Anthropic's docs; pairing them with symptoms in one table is ours.

The diagnostics a team should know are /memory, /skills, /hooks, /mcp, /permissions (resolved rules), /doctor (a setup checkup), /debug and /status (Debug your configuration); from the terminal, claude doctor prints read-only installation diagnostics without starting a session. For self-sufficiency, apply the champion kit to support: answer publicly once and link back to that answer when the question recurs, collect the most common questions and answers in a pinned FAQ message, and identify a second champion to divide the channel responsibilities with (Champion kit).

On data handling: Anthropic does not train on code or prompts on Team, Enterprise, API or cloud provider plans, and Claude Code ZDR "cannot be enabled from your admin settings" (Zero data retention); it comes through Anthropic for qualified Enterprise accounts, with forceLoginMethod and forceLoginOrgUUID keeping sessions in the ZDR organization. See Data retention, training and compliance.

Decide

• If developers need Claude Code and claude.ai with no infrastructure to run, choose Teams or Enterprise; if you must inherit AWS, GCP or Azure controls and billing, choose that provider and decide whether developers also need claude.ai seats.
• If every developer must get a piece of configuration on clone, commit it (project CLAUDE.md, .claude/commands/ or .claude/skills/, .mcp.json, .claude/settings.json); not ~/.claude/ or ~/.claude.json, which are personal.
• If a rule must hold whatever developers configure, put it in managed settings; not in a project file any developer can edit.
• If you deploy on a cloud provider, pin model versions and use managed settings instead: availableModels for restrictions, model for a default and maxEffortLevel for an effort cap; Claude Enterprise's organization model and effort controls do not reach those sessions.
• If a group keeps hitting its cap, check what the spend is producing and the default model first; not an automatic increase.
• If adoption is flat, invest in enablement (champions, guided first tasks); not a settings change, since "The fix is usually enablement, not a settings change" (Adoption signals).

Traps

• The HKCU registry as enforcement. It is writable without elevation.
• Expecting Anthropic's analytics to show Bedrock usage. Claude Code does not send metrics from your cloud back to Anthropic; use OpenTelemetry, a gateway, or your cloud provider's billing console.
• Letting AI review findings approve or block a PR. Branch protection and a code owner's approval still decide.
• Champions answering security questions. Refer them to the administrator.
• A team command in the wrong place. CCAR-F Question 4's rationale rules out ~/.claude/commands/ ("personal commands that aren't shared via version control") and CLAUDE.md ("for project instructions and context, not command definitions").

Exam map

Tested in: all four exams, section by section (CCAO-F, CCDV-F, CCAR-F, CCAR-P)

Which official objective each section of this page serves, taken from the four July 2026 exam guides. How to read the labels: the CCAO-F and CCAR-P guides list their objectives as unnumbered bullets and the CCDV-F guide lists its skills in order under each domain without numbers, so the numbers here are ours. CCAO-F objectives are numbered D1.1 to D7.3 in the order the guide lists them; CCDV-F numbers such as 2.3 are the skill's position within its domain; CCAR-P numbers such as 6.3 are the objective's position within its domain. CCAR-F numbers its own task statements (such as 3.1); the K (knowledge) and S (skill) suffixes are our numbering of the bullets under each task statement, in guide order, and EX, APPX and Q mark preparation exercise steps, appendix items and sample questions.

Where this page carries the most weight (CCDV-F skill weights are shares of the whole exam, as that guide states them):

• CCAR-P: every objective in Domain 6, Stakeholder Communication & Lifecycle Management (14%), and Domain 7, Developer Productivity & Operational Enablement (7%), has a section here, and the page also covers Domain 1 (17%: 1.1, 1.2, 1.3, 1.6), Domain 3 (19%: 3.2, 3.3, 3.5 to 3.8), every objective of Domain 4 (16%: 4.1 to 4.6) and every objective of Domain 5 (14%: 5.1 to 5.5). Objectives taught mainly elsewhere: 1.4 and 1.5 on Agents and the Claude Agent SDK, Domain 2 (13%) on Claude API Essentials, Prompt Engineering and Context Engineering (the caching side of 2.5 and Sample 2 are worked in Cost modeling), 3.1 in Designing a tool set, and 3.4 in Reliability engineering for Claude applications.
• CCDV-F: all of 2.1 Understanding Requirements (3.4%) and 2.2 Systems Life Cycle (2.8%), the vendor, data-access and realtime-versus-batch parts of 2.3 Claude API Mechanics (6.8%), the program side of 5.4 Cost and Token Management (2.8%), and the team-configuration side of 2.6 Configuration Management (4.1%) and 3.1 Claude Code Operation (3.1%).
• CCAR-F: little. The appendix puts embedding models or vector database implementation details, rate limiting, quotas or API pricing calculations, and specific cloud provider configurations out of scope. What remains here is team configuration of Claude Code (Domain 3, 20%: 3.1 and 3.2, plus 2.4 from Domain 2, and Exercise 2), Claude Code in CI/CD and independent review (3.6-K1, 3.6-K2, 3.6-K4), the batch trade-off in 4.5 and Question 11, deterministic enforcement in 1.4 and Question 1, and segment-level accuracy before reducing human review in 5.5.
• CCAO-F: the user's side only: D4.1, D4.4 and D4.5 from Domain 4 (16%), D3.1 and D3.3, D5.1, D2.1, D2.4 and D7.2, and Domain 6 (15%). The guide leaves enterprise-scale architecture and integration design to the Architect and Developer credentials (its wording is quoted at the top of this page).