Anthropic CCA-F Scenarios: Choosing Agents, MCP and Reliable Context

An architecture question can be difficult even when every term in it is familiar. A Claude agent can retrieve documents, a Model Context Protocol server can expose tools, and a structured-output schema can constrain JSON. Knowing those definitions is only the beginning. The hard part is recognizing what the system is authorized to do, what it actually knows, and which design offers the best trade-off under a particular constraint.

That is the useful way to prepare for Claude Certified Architect – Foundations. Anthropic’s published blueprint emphasizes agentic architecture, tool and MCP integration, Claude Code workflows, structured output, and context reliability. Rather than attempting to memorize a single preferred pattern for each topic, practice identifying the hidden decision in a realistic scenario. The same pattern that improves one workflow can make another needlessly complex or unsafe.

Start with the requested outcome, not the named technology

Suppose a business team asks for an assistant that reads new customer cases, checks an account history and prepares a recommended response. The description may immediately suggest an autonomous agent with multiple tools. Yet the decisive question comes first: is the assistant preparing a recommendation for a human, or is it authorized to change customer records and send a response? Those are different services with different failure consequences. A design that treats them as equivalent may be fast to implement but impossible to approve responsibly.

Write the outcome in a single testable sentence. “Produce a sourced draft that a caseworker can review” is not the same as “resolve the case autonomously.” The former can often be implemented with a bounded retrieval and drafting workflow. The latter requires stronger identity verification, evidence checks, side-effect controls, error recovery and monitoring. Until you distinguish them, debates about models or orchestration are premature.

A useful architect asks who receives the output and what action follows. A draft document may be wrong and still be caught in review. A tool call that transfers money, grants access or deletes data has already changed the world. Exam scenarios often become clearer when you identify this point where generating text crosses into operational authority.

Choose between a fixed workflow and an adaptive agent

Consider an onboarding application that always collects three verified fields, looks up an approved policy and generates a welcome message. If the task has a stable sequence, ordinary application code can orchestrate the steps and use Claude only where language understanding or drafting is genuinely useful. Giving an agent the freedom to decide the sequence may add unpredictable branches without improving the result.

Now consider a research request whose required sources depend on what earlier evidence reveals. The assistant may need to search several collections, compare contradictory documents and decide which follow-up queries are worth making. Bounded autonomy may be useful here, provided the system limits how long the process can run and what tools it may invoke. Even so, the agent should not be permitted to invent evidence or hide a failed retrieval just to produce a complete-looking report.

The right comparison is not “workflows are simple, agents are sophisticated.” It is whether adaptive planning improves task completion enough to justify extra cost, latency and risk. Design fixed steps for invariant business rules, grant the model flexibility where the decision genuinely requires it, and put explicit bounds around repetition and delegation. Agentic Architecture & Orchestration carries substantial weight in the official exam blueprint precisely because these are judgment calls rather than one-size-fits-all recipes.

At enterprise scale, tool permissions, retries, failure ownership and orchestration costs create additional design choices. Those concerns are central to Architect Professional agentic workflow design, but a Foundations candidate should first be able to defend why autonomy is necessary in the smaller system described by the question.

Trace state before you decide how to recover from a tool failure

Imagine an agent calls a customer-management tool to update a shipping address. The application times out before receiving a result. Should it retry immediately? That is not enough information to decide. The update may never have reached the service, may have succeeded before the response was lost, or may still be processing. Those possibilities require different recovery behavior if repeating the operation can create a second side effect.

Begin by separating four states: requested, accepted, completed and confirmed. A transport timeout tells you that confirmation is missing; it does not prove the operation failed. Where the external API supports idempotency keys, use them to make retries safer. Where it does not, reconcile the existing remote state before repeating a potentially consequential action. Maintain enough identifiers to connect the original request with any later result or compensating action.

A similar discipline applies inside an agent loop. The model’s tool-use request and the tool’s returned data must be connected to the correct call. A failure from one tool should not be presented as a successful result from another. For long-running work, the application needs a durable picture of completed steps, remaining steps and uncertain steps. Summarizing an interrupted conversation as “everything completed” is not recovery.

In scenario practice, highlight every verb that implies a side effect: create, update, transfer, approve, notify, deploy, revoke. Then ask how the system proves the action happened exactly once, or how it safely handles the impossibility of proving that immediately. Reliability emerges from those decisions more than from adding another retry loop.

Distinguish retrieved evidence from instructions and authorization

A support assistant may retrieve a policy document, a repository issue or a customer email. That material can be relevant evidence, but its text may also contain commands written by someone with no authority over the assistant. A malicious issue might say to ignore earlier safety requirements or upload a confidential file to a new address. Treating that instruction as a system-level request would allow untrusted content to cross the trust boundary simply because it arrived through a tool.

Keep the sources and purposes separate. An authenticated user request defines the task within the application’s policy. Retrieved documents provide facts to evaluate against that task. Tool outputs report observations or errors. The application decides which actions the current identity is permitted to take; a model-generated justification does not grant access by itself.

The same applies to MCP. A protocol gives a client a consistent way to discover and call integrations; it cannot guarantee the integration is trustworthy. Check the identity, scope and side effects of the actual server and tool. A document-search tool should not quietly acquire permission to modify account permissions just because both functions are exposed by the same connector. Where possible, give agents access only to the tools needed for the immediate task.

An effective architecture can still let the model summarize conflicting guidance or propose an action requiring approval. It simply prevents the proposal from becoming an executable side effect until the appropriate control permits it. The Developer Foundations analysis of tools and MCP explains the mechanics; an architecture question asks whether that integration is appropriately bounded.

Use structured output to constrain shape, not to certify truth

Suppose Claude must extract a case number, customer tier and recommended next action as JSON. A schema can make the response easier for software to parse, and required fields can prevent some omissions. But schema validity is not a guarantee that a case number was read correctly or that the recommended next action is allowed. An attacker-controlled document can produce a perfectly shaped answer containing the wrong account or an unsafe recommendation.

Define the contract for data shape separately from the contract for business truth. Validate identifiers against trusted systems, check permissions before acting, and send high-impact decisions through the appropriate review process. When an answer cites a policy, preserve the evidence needed to verify which version and passage was used. If evidence conflicts, the system should be able to report uncertainty rather than manufacture a confident value solely because a field is mandatory.

Few-shot examples can help communicate expected formatting, but examples should not quietly become the only source of truth. A model can overfit to the pattern and infer a value that was never present in the input. Good evaluations therefore include missing fields, conflicting records, ambiguous units, and clearly out-of-scope requests, not just clean examples that always contain the required answer.

Build a context strategy that preserves the decision trail

Long documents and multi-step conversations create a context-management problem. Copying every available page into the model may increase cost and confusion while obscuring the evidence that matters. Removing too much context can cause the model to forget a constraint that governed an earlier step. Neither maximal context nor minimal context is automatically best.

Decide which information must be stable and which can be retrieved again. System constraints, the user’s authorized goal and confirmed side effects belong in a more durable state than incidental search results. Retrieved passages should be scoped to the current question with provenance attached. When an assistant hands work to another agent, the summary should distinguish confirmed findings from hypotheses and record decisions that cannot safely be repeated.

Consider a four-step audit in which an agent validates a document set, asks a second agent to review exceptions, drafts a conclusion and sends it to a human. If the first agent’s summary omits unresolved exceptions, the second agent may receive a misleading picture. A handoff contract should include the original task, evidence references, constraints, unresolved questions, and the status of any attempted side effects. Without that structure, parallelism can amplify uncertainty rather than reduce latency.

When the scenario asks whether to use retrieval, summarization or a larger context window, answer based on the failure it is trying to avoid. Retrieval helps when information is too large or changeable to include consistently. Summarization helps when a durable thread must stay manageable, but it can omit details. A larger context window may help with direct comparison yet still requires careful ordering and provenance. The architect’s job is to choose and verify the right combination.

Compare candidates against the consequence of being wrong

Many plausible answer choices describe technically possible designs. To distinguish them, compare the evidence each design preserves, the permissions it grants and the failure it makes likely. A question about a read-only research assistant will reward a different balance than a question about an agent that updates customer data. A design optimized purely for fast responses might be reasonable for a low-risk summary and unacceptable for a security-sensitive workflow.

For each practice scenario, write down two alternatives and the specific condition under which you would choose each. For example, if an operation cannot safely be repeated, state what would establish its actual completion before retrying. If the question mentions sensitive data, identify who authorizes access rather than assuming a helpful assistant can decide. This habit produces defensible decisions and exposes gaps in understanding before test day.

Finally, distinguish preparation from claims about the assessment itself. Anthropic publishes the blueprint and sample formats, but editorial scenarios like those above are teaching tools, not recalled live exam questions. The most durable preparation is hands-on design practice: make the boundary explicit, test a failure, inspect the result and explain why the chosen architecture behaves better than the alternatives.