AnthropicClaude Certified Architect – Professional2026-101.2 Design end-to-end architectures (input → processing → output → feedback loops)
Trace each request through accepted action
Completed by the knowledge check
Learning objective
Map the end-to-end flow from input capture and validation through context assembly, model processing, output handling, and downstream actions.
Core idea
For an architect delivering a Claude service, the unit of design is the business request from arrival to an accepted outcome. An API response covers model processing. It does not establish that the right input arrived, the right evidence reached the model, or the downstream action completed.
Map the path as contracts between stages. Each contract names the input, the output, the checks that permit advancement, and the destination for unresolved work. Anthropic’s prompt-chaining pattern provides a useful mechanism: divide a task into calls and place programmatic gates between them. The trade-off is additional latency for easier, more accurate individual tasks. Choose stage boundaries where you can check a meaningful intermediate result, rather than splitting prose arbitrarily.
This Bite owns the lifecycle map. See 1.2.2 for execution and transaction ownership, 1.2.3 for structured interfaces and acceptance routing, and 1.2.4 for the feedback path that improves subsequent versions.
How it works
Capture a business request before assembling a prompt
Define an application intake record that survives independently of any model response. In a customer-service workflow, it might contain a case identifier, authenticated requester, channel, source attachments, and requested outcome. These are application fields, not Messages API properties. Intake decides whether the record is eligible for processing: readable material, a recognized request type, and a requester permitted to submit that case.
Distinguish accepting a case from accepting its contents as facts. A customer can submit a valid complaint containing an incorrect account reference. Preserve that claim as source material and obtain the account facts through the authorized business service. A missing identity prerequisite belongs to intake or an execution gate; asking Claude to infer the identity does not supply the evidence.
Make an unreadable attachment visible in the intake record. If later stages receive an empty string that looks like a successfully parsed document, even a good model response cannot restore the missing evidence. Use an explicit application outcome such as needs_manual_input, with the original source available to the assigned handler.
Assemble context from accepted inputs
Context assembly combines the request, relevant source material, and task instructions. For the Messages API, instructions belong in system, while conversation content belongs in messages. The API is stateless: you send the conversational history needed for each request. Conversation history is therefore a supplied model input, not the durable business case record.
For retrieval-augmented generation, identify the query, retrieved source identifiers, and the passages actually added to the prompt. Anthropic’s Contextual Retrieval article describes combining lexical BM25 and semantic embedding retrieval, deduplicating the results, and adding selected chunks to the prompt. The lifecycle contract is the selected evidence set, regardless of which retrieval algorithm produced it.
Keep the business record and retrieved policy distinguishable from a customer’s assertions. Deliver untrusted third-party text inside tool_result blocks, with its nature and source identified, rather than in system or plain user text blocks. State the untrusted-content policy in system and JSON-encode third-party strings where possible so their delimiters remain explicit; see 5.1.4 for prompt-injection mitigation and 2.2.2 for delimited templates. Preserve the selected policy passage for review: ten plausible chunks do not establish that retrieval found the applicable clause.
Give model processing a stage-specific deliverable
A call that extracts a request category and a call that drafts a customer response serve different consumers. Extraction supplies a record for application code; drafting supplies language for a reader. Define the acceptance contract for each before selecting the output mechanism. See 1.2.3 for the interface choice.
With client tools, a tool_use block is a proposal that your application executes. Its name, id, and input describe the requested operation. The corresponding tool_result reports what execution produced. A tool request therefore adds another checked exchange within processing; it is not proof that the dependency succeeded.
A fixed sequence can use application-owned prompt chaining: extract, check, retrieve, draft, check. An agentic stage can choose its next operation dynamically, but the same architecture still needs accepted inputs and an explicit completion outcome. More autonomy changes control flow; it does not remove the stage contract.
Handle the response before delivering an action
Define output handling as a separate consumer of the model result. Its responsibilities include recognizing incomplete or refused responses, checking the expected payload, comparing material claims with evidence, and applying the business review rule. Structured outputs can enforce a supported schema, but refusal and token exhaustion require explicit handling; 1.2.3 owns those paths.
A draft accepted for review is different from a draft approved for sending. Represent that difference in the application’s case state. For example, draft_ready, approved, and delivered are illustrative application statuses. They should correspond to different evidence: a checked draft, an authorized approval, and the downstream service’s delivery result.
Downstream actions include sending correspondence, updating a record, or creating a fulfillment request. Model text saying “sent” is not a delivery receipt. Read the actual client-tool or service result and expose unresolved delivery separately from generation failure. See 1.2.2 for preventing duplicate effects during recovery.
Record the stage that blocks completion
A useful map states what happens on each unsuccessful arrow. Intake can require manual input; retrieval can leave the evidence incomplete; inference can fail; acceptance can require review; delivery can remain uncertain. Do not collapse all five into “Claude failed.”
Attach the relevant stage output and reason to the case. Anthropic recommends task-specific, measurable success criteria, including latency and price alongside task fidelity. Apply those criteria to the entire request: a rapid generation that waits indefinitely for approval has not met an end-to-end completion target.
Key distinctions and trade-offs
The architecture should preserve these contracts:
| Stage | Accepted output | What the next stage cannot assume |
|---|---|---|
| Intake | Eligible case and usable source material | Every customer claim is verified |
| Context assembly | Selected evidence and instructions | Retrieval found every required fact |
| Model processing | Candidate record, draft, or tool proposal | The business decision is authorized |
| Output handling | Validated result and required approval | A downstream action has completed |
| Delivery | Recorded external outcome | Future quality improves without feedback |
Additional gates add execution and operational work. They earn that cost when an intermediate defect could otherwise reach an expensive action. A single call can remain appropriate when its evidence is already assembled and its result is easy to validate; Anthropic recommends the simplest solution that works.
Architecture / decision scenario
A retail contact center promises acknowledgement within five minutes and a reviewed answer within one business day. A single classify-and-draft call would minimize model round trips, but must draft before category-specific retrieval has supplied the applicable returns policy. The architect chooses classify → check → retrieve → draft because the reviewed-answer target allows that extra latency and the category check rejects unsupported categories before policy selection.
The following budgets and owners are application requirements, not Claude defaults:
| Stage | Budget and waiting party | Owner of an unsuccessful arrow |
|---|---|---|
| Capture and acknowledgement | Five minutes; customer waits for receipt | Intake team preserves the case and routes unreadable scans to manual input |
| Classification and check | Thirty seconds; background worker waits | Workflow owner rejects unsupported categories or sends the case to a handler |
| Record and policy retrieval | Ten seconds; background worker waits | Retrieval owner resolves missing authorized evidence |
| Draft and evidence check | Two minutes; background worker waits | AI service owner supplies a checked draft or an explicit incomplete result |
| Review and delivery | Remaining business day; customer waits for the answer | Contact-center lead owns approval; correspondence service owns confirmed delivery |
Intake acknowledges the case independently of AI processing. Classification must pass its check before retrieval selects policy passages, and the draft must pass evidence checks before approval permits sending. Retrieval failure leaves the handler a case without an AI draft; uncertain sending remains the correspondence service’s problem rather than restarting classification. The staged choice costs extra calls, but gives each failed arrow a responsible owner and keeps the acknowledgement target independent of model availability.
Common exam traps
- Drawing only the model call and calling it an end-to-end architecture.
- Equating captured customer claims with verified business facts.
- Treating conversational history as the durable case record.
- Accepting a tool proposal as evidence of successful execution.
- Treating draft approval and downstream delivery as one state.
- Measuring generation latency while ignoring the rest of the request.
What to remember
Trace one request across input, context, inference, acceptance, and action. Each arrow needs a contract and a failure destination. Record the business outcome from the component that actually owns it, then carry its evidence into the feedback loop.
Knowledge check
In a claims-intake pipeline, a scanned police report fails text extraction. The parser passes an empty string to context assembly, and Claude produces a fluent summary that omits the report’s findings. Which design change addresses the defect where it starts?
A collections workflow gives Claude a client tool, send_letter. After the application executes the tool, the correspondence service times out, and Claude’s next message says “The letter has been sent.” Which evidence should move the case to delivered?
tool_use block requesting send_letter with valid inputtool_use block is a proposal, approval is a different case state, and model text saying “sent” is not a receipt. Delivered requires the downstream service’s confirmed successful result; after a timeout that result is unknown, so the case stays unresolved at delivery instead of being marked delivered.A support assistant built on the Messages API keeps the running messages array as the only record of each case, including the customer’s identity, attachments and requested outcome. A worker restart loses several arrays mid-case. What should the architecture change?
system prompt of every requestA retail contact center must acknowledge each email within five minutes and send a reviewed answer within one business day. Each answer depends on a category-specific returns policy; the policy library is too large to include in full, so retrieval can select the policy only once the category is known. Intake acknowledges emails independently of model processing, and timing tests show that a staged workflow fits the one-day target. A single classify-and-draft call would be fastest. Which flow should you choose?
References
- Anthropic, Building effective agents
- Anthropic, Working with Messages
- Anthropic, Handle tool calls
- Anthropic, Introducing Contextual Retrieval
- Anthropic, Define success criteria and build evaluations
- Anthropic, Create a Message
- Anthropic, Mitigate jailbreaks