An AI agent is not simply a prompt that happens to be long. An agent makes a sequence of decisions, can call software tools, sees the results, and decides whether more work is needed. Designing that sequence is an engineering problem: each step needs a reason to exist, a defensible boundary of authority, and a way to tell whether the system is improving the user’s outcome. Claude’s agentic capabilities make the problem approachable, but they do not remove the need to design those boundaries.
For candidates preparing for Anthropic CCAR-F, these choices are particularly relevant. Anthropic’s blueprint weights agentic architecture and orchestration at 27%, tool design and Model Context Protocol integration at 18%, and context management and reliability at 15%. Those areas overlap in a production system: a tool can be perfectly implemented and still be unsafe if the agent invokes it at the wrong point, without enough context or without a human review gate.
The most useful starting point is to forget the number of prompts, agents or tools and focus on the actual task. Consider an organization that receives a customer request to change a subscription, issue a refund or update an account profile. The request must be classified, checked against policy, grounded in the right account data and carried out only when the proper authority exists. This article follows that kind of workflow through the architectural decisions that matter.
Decide whether the task needs an agent
A fixed workflow should remain fixed when the input, steps and permitted outcomes are predictable. For example, validating that a request contains a customer identifier, checking whether the identifier exists and rejecting a transaction above a numerical approval limit can all be handled deterministically. Inserting an agent between those steps may increase latency and introduce avoidable uncertainty without making the workflow more useful.
An agent becomes valuable when the system must interpret ambiguous language, choose among several legitimate investigative steps, adapt to incomplete information or decide which tool could provide the missing evidence. Suppose a customer writes that their subscription was cancelled but a charge still appeared. The system may need to distinguish the invoice date from the cancellation date, retrieve payment history, check eligibility rules and ask a clarifying question when records conflict. Hard-coded branching is possible, but the variety of cases may make an agentic decision loop a more practical interface.
The design should still minimize discretionary decisions. A sensible hybrid system lets deterministic services authenticate the user, enforce monetary limits, apply business rules and execute final changes. Claude can help interpret the request, select the next read-only investigation and prepare a reasoned recommendation. The final mutation remains behind an explicit application gate. This separation is also a strong way to improve testing: an eligibility rule should not change because a model paraphrased the customer’s message differently.
Before building the agent, write down the smallest outcome that counts as success. Is it a correct answer with cited policy, a recommended action waiting for approval, or an authorized change recorded in the account system? These are different products. A prototype that answers well is not automatically ready to take irreversible actions.
Give the model judgment, not unrestricted authority
Claude’s tool-use interface is a structured agreement between a model and the application. The application advertises available tools and their input schemas. The model can request a call, but execution happens through the surrounding software or a configured server-side capability. The result then returns to the model as context. The important consequence is that a model’s request is not equivalent to permission to execute.
For an account-support agent, a get_invoice tool could accept an invoice identifier and return a limited set of fields. A propose_refund tool could calculate a suggested amount without moving money. A separate execute_refund operation should require authenticated customer identity, policy eligibility and an approval token issued by deterministic application logic. Merely asking the model to be careful is not a substitute for enforcing those preconditions in code.
Tool descriptions should state when the operation is appropriate, not only the data it returns. Two functions named search_customer and find_customer are ambiguous unless their scopes differ clearly. One might search public documentation while the other queries a private account database; those distinctions affect both privacy and the probability of the model selecting the right tool. Inputs should be narrowly typed. A model should not need to invent an account identifier or assume a default currency because the schema omitted required fields.
A tool result also has to be treated as data rather than a new instruction. Customer notes, retrieved documents and web pages may contain adversarial text or outdated recommendations. A reliable design clearly separates trusted application policy from retrieved content, validates tool responses, and prevents a customer’s free-form message from escalating the agent’s privileges.
Choose the simplest effective orchestration
A single agent with a small, well-defined set of tools can accomplish surprisingly complex work. It can investigate a case, gather evidence, explain uncertainty and draft a recommendation while retaining one coherent view of the interaction. This is usually the architecture to test first, because it is easier to trace, evaluate and operate than a system in which many autonomous components hand tasks to one another.
Specialist agents become worthwhile when the task contains genuinely different skills or permission boundaries. A document-analysis specialist might extract relevant clauses from a contract, while a policy specialist evaluates eligibility and an account specialist checks the current customer record. Separating their tools can reduce the risk that the document agent has unnecessary access to billing operations. But adding roles creates communication costs: each agent needs a clear input contract, its own success criteria and a predictable way to return evidence to the coordinator.
A coordinator should not merge confident summaries without reconciling the underlying facts. If two specialists disagree about the cancellation date, the orchestrator must identify the discrepancy and request verification rather than averaging the answers. Handoffs should preserve the source of each claim, whether it is a customer statement, a signed policy document or a timestamp from the billing system. The design should also define a maximum number of investigation steps so one unresolved case cannot trigger endless tool calls.
Careful task decomposition allows independent checks to run concurrently, such as retrieving a payment record and reading a subscription’s termination history. It is counterproductive when one operation depends on another or when multiple agents might mutate the same state. An approval step cannot safely run before the amount and customer identity are established. The faster system is not the one with the most agents; it is the one that makes the minimum necessary decisions in the right order.
Use MCP to standardize integrations without blurring trust
The Model Context Protocol (MCP) offers a standardized way for an application to connect to external tools and information sources. Its host, client and server responsibilities matter to the architecture. A host application manages the user-facing AI experience and connections; an MCP client communicates with an MCP server; the server exposes capabilities such as tools or resources. Standardizing the interface reduces the amount of custom integration plumbing required, but it does not certify the safety or accuracy of any server.
Suppose a support agent can connect to a billing system and a policy repository through separate MCP servers. The billing integration should expose only the fields and actions the workflow needs. Read access to a historical invoice does not imply write access to a payment method. The policy integration should return document identity and version metadata so the agent can distinguish current rules from an old cached policy. Tool names, parameter descriptions and outputs should be clear enough that a reader can reconstruct why a particular piece of evidence was used.
Good MCP tool design is mostly disciplined API design. Prefer a small number of well-scoped operations to one generic command that accepts free-form instructions. Return structured outcomes for expected conditions: found, not found, access denied, stale data or temporary failure. An authorization failure must not look like an empty successful search result, because the model could misinterpret missing data as proof that no customer record exists.
Credentials and access policies belong in the application and integration layers. Secrets should never be inserted into a model prompt to make an integration convenient. Log tool identity, the requesting workflow, decision timestamps and sanitized outcomes, without storing unnecessary sensitive content. The result is traceability: a reviewer can distinguish an agent making a poor decision from a tool returning incorrect information or an integration failing at the network boundary.
Treat context as a finite, curated resource
In a multi-step interaction, an agent needs relevant history without being overwhelmed by everything that has ever happened. A conversation transcript is not a reliable substitute for durable state. For the customer-support scenario, the system should maintain explicit identifiers, a current case status, evidence references, outstanding questions, approvals and the version of the policy used. That structured record survives summarization and makes it possible to resume after a process restart.
Context selection can be task-specific. When checking refund eligibility, include the approved refund policy, transaction date, amount and subscription status. Do not inject years of unrelated customer conversations. When drafting a customer-facing explanation, include the decision and the supporting evidence, not access tokens or raw database dumps. Retrieval should answer a specific information need, and each retrieved item should carry enough source information to test whether it remains current.
Long-running workflows need rules for compaction. A summary that says “customer qualifies” loses too much information unless it preserves the rule used, the evidence and whether approval is pending. Retain a durable decision record with links or IDs that allow the underlying source to be fetched again. If the agent’s context becomes inconsistent with the system of record, prefer a fresh tool query to a plausible guess based on conversational memory.
Claude Code configuration and project instructions introduce a related but distinct problem: developers need consistent repository context, permitted workflows and team conventions. The Developer – Foundations track goes deeper into developer implementation, while Architect – Foundations expects design judgment about how tools, context and orchestration fit together. Documentation files and configuration conventions can improve consistency, but enforcement still belongs in tests, permissions and application logic.
Design failure handling before the first successful demo
Real workflows fail in ordinary ways: a record is missing, the policy has two versions, a tool times out, an external service returns an unexpected schema or a user changes their mind midway through a request. The agent needs explicit responses to each class of failure. A retry can be reasonable for a transient read error; blindly repeating a financial mutation can be costly. Operations that change external state should be idempotent where possible, and the application should record whether an earlier attempt committed before resubmitting it.
A well-defined handoff to a human is not a weakness in the architecture. It is the right outcome when evidence conflicts, policy exceptions require discretion or the proposed action crosses a risk threshold. The handoff should include a concise summary of what the agent knows, links to the underlying records, exactly what it could not verify and the specific decision a person needs to make. “Human intervention required” without evidence merely moves the investigation burden to somebody else.
Evaluation should test the complete workflow, not just whether the final answer sounds convincing. Build a scenario set with normal cases, ambiguous requests, outdated policy documents, prompt-injection attempts, missing IDs, permission denials and interrupted operations. Record whether the agent selected the appropriate read-only tool, stopped when approval was missing, rejected unsupported claims and avoided duplicate actions. The metric that matters is reliable completion under realistic constraints, not the average number of tokens emitted.
Operational monitoring should connect model behavior to service outcomes. Useful signals include repeated tool failures, human handoff rates, rejected writes, time per case, excessive retries and disagreement between agent recommendations and final policy decisions. Review these together: a lower cost per request is not an improvement if it causes a sharp increase in mistaken account changes or support escalations.
Walk through a defensible end-to-end design
Consider the earlier request: “I cancelled last week, but I have been charged again.” The user-facing system first authenticates the account and attaches an internal case identifier. Claude interprets the request as a possible billing dispute; it does not decide immediately that a refund is owed. A deterministic eligibility service records the account’s authorization context and the customer-facing policy version.
The agent retrieves the subscription cancellation timestamp and recent invoice history through read-only tools. If the invoice was issued before the effective cancellation date, the correct next action may be to explain the billing timeline. If it was issued afterward, the agent retrieves the current policy and checks whether an exception or prorated adjustment applies. If the cancellation record is missing, the agent asks for clarification or escalates with the conflicting evidence. It does not substitute a confident narrative for a missing database record.
Next, an application service calculates an allowed adjustment from verified inputs. Claude can explain the proposal, including what happened and why the policy allows or disallows a refund. When the proposal exceeds the permitted threshold, a reviewer must approve it. Only a separate controlled operation can post the refund, and it checks a unique request key to avoid processing the same action twice after a timeout.
The case record retains the supporting invoice IDs, cancellation date, policy version, requested and approved amounts, approval identity and final transaction status. A follow-up message is generated from that record. If the agent summary omits a material detail, the record still supports review and correction. This is what makes an agent trustworthy: it can be investigated after success or failure, and the organization can explain why the system acted.
The architecture also illustrates why “more autonomous” is not synonymous with “better.” The model handles ambiguity and synthesis while deterministic controls own authentication, money movement and record integrity. Tool schemas keep operations intelligible, MCP integrations separate systems, structured context prevents memory drift, and review gates handle unresolved risk. Each component has a specific reason to exist.
Connect the design to Claude certification decisions
Anthropic’s exam blueprint expects practitioners to recognize trade-offs among agentic architecture, tool integration, Claude Code workflows, structured output and context reliability. The details of a given task change, but the architectural questions remain consistent: Which steps are deterministic? What information can the model request? Which actions need separate authorization? When are specialist agents useful? How is state preserved? What evidence demonstrates that the system worked?
The distinction matters across certification levels. Architect – Professional is a separate credential focused more heavily on enterprise-wide design and governance, rather than an automatic upgrade from Foundations. An effective Foundations-level study approach is therefore to analyze concrete workflows, identify the unsafe decision boundaries and explain why one design is more reliable than another. Memorizing product labels alone cannot substitute for that reasoning.
A mature agent architecture makes room for model judgment without asking the model to become the security boundary, the source of record or the final authority over irreversible changes. That principle applies whether the system supports a single customer-service workflow or coordinates several specialists across a larger application. Design clarity is the most useful foundation for both practical deployment and serious technical assessment.