AnthropicClaude Certified Architect – Professional2026-101.2 Design end-to-end architectures (input → processing → output → feedback loops)

Keep business writes behind deterministic owners

Completed by the knowledge check

Learning objective

Separate orchestration, model inference, tool execution, and system-of-record writes, with validation, authorization, business rules, idempotent side effects, retries, and timeouts outside the model.

Core idea

For an architect operating a Claude workflow, loop ownership and prerequisite gates are the starting point. The Professional decision is how those controls extend across a business transaction, especially when a tool returns late, a worker restarts, or an external service commits a write before its response is lost.

Separate four responsibilities: orchestration decides which stage runs; inference proposes content or operations; the tool executor checks and invokes capabilities; the system-of-record service commits the business effect. Anthropic’s client-tool protocol explicitly puts actual execution in your codebase. Use that seam to make the permitted effect depend on trusted state rather than model phrasing.

See 1.2.1 for the stage map and 1.2.3 for validating the proposed payload. Here the concern is who can commit it and how the application recovers without multiplying effects.

How it works

Assign authority separately from proposal generation

The orchestrator owns the application’s transaction record: the business request, accepted intermediate results, permitted next stage, and terminal outcome. Its state determines whether execution can continue. A model-generated plan can suggest a stage, but it cannot set its own authorization status.

Inference receives evidence and returns a candidate. A client tool_use.input is part of that candidate, including any account identifier, amount, or claimed approval. The executor resolves those values against authenticated identity, trusted prerequisite state, and business rules before dispatching the operation. The system-of-record service remains responsible for enforcing its own write contract.

For example, an illustrative submit_adjustment tool can propose a ledger adjustment. Its handler verifies the caller’s account scope, the approved case, and the amount calculated by the business service. The tool’s schema determines the input shape; these checks determine whether that specific adjustment is permitted. None of the illustrative tool names or transaction fields here is an Anthropic built-in.

With an application-owned Messages loop, put these checks before the handler invokes the write service. With the Agent SDK, a blocking PreToolUse hook can deny a matching call through hookSpecificOutput, hookEventName: "PreToolUse", and permissionDecision: "deny". Keep the write service’s checks too: the hook covers the harness path, while the service protects the actual commit interface.

Preserve an accepted transaction across restarts

Define a durable application record for the accepted operation, separate from the inference transcript. It contains the intended business effect, policy decision, approval evidence, and external outcome. A process restart reloads that record instead of asking Claude to rediscover whether payment was approved.

Treat stage checkpoints and duplicate-effect prevention as different controls. A saved extraction result avoids repeating a model stage. It does not prevent a second ledger write if the worker crashed after the ledger committed but before the local checkpoint was saved.

In this example design, the write service accepts an application operation_key derived from the approved business operation. It stores that key with the effect and returns the recorded outcome when the same operation is requested again. The key and storage behavior are requirements of the example write service, not an Anthropic API idempotency guarantee.

For Agent SDK custom tools, annotations can declare idempotentHint: true to describe a handler whose repeated calls with the same arguments have no additional effect; the default is false. This hint is informational metadata, not enforcement: the write service’s operation_key behavior makes the effect duplicate-safe.

Bind the key to the accepted payload. Reusing one key for a changed amount must produce a conflict rather than silently reuse or overwrite the earlier result. Generate the key from application-owned transaction identity, not the model’s choice of a random identifier. A tool_use.id correlates a conversational call; it is not the durable identity of the business operation across later inference attempts.

Make uncertain writes a distinct recovery path

Consider a write that reaches the ledger, commits, and then loses its response. The executor times out, but its observation does not establish whether the ledger committed. Store an illustrative outcome_unknown state and reconcile through the write service’s lookup by operation_key. If it returns the recorded effect, persist that result and continue without another business effect.

If the service supports safe repetition with the same key, repeat only the accepted operation under that contract. If it offers neither duplicate prevention nor outcome lookup, defer the unresolved write for investigation rather than claiming a safe retry. This is a capability requirement you must establish for the downstream service.

After a timed-out write, the write service’s capabilities decide the recovery path.

Return uncertainty in the correlated client tool_result with is_error: true, and keep reconciliation bound to the persisted operation_key; an unknown result must not create a fresh operation identity.

Bound inference and dependency recovery separately

Anthropic’s Python client retries connection errors, HTTP 408, 409, 429, and errors at or above 500 twice by default, with exponential backoff. Set max_retries deliberately, with max_retries=0 when the orchestrator owns retries.

Configure the Python client’s timeout in seconds for inference. Its documented default is ten minutes, and timed-out requests are retried twice by default. An attempt count alone therefore does not establish the workflow’s elapsed-time bound. A client timeout produces APITimeoutError; the orchestrator determines whether another attempt fits the remaining business deadline.

These client settings govern calls to Claude, not your ledger or other tool dependencies. Give each executor its own dependency timeout and make its recovery consume the transaction’s remaining deadline. A model instruction to stop after ten seconds does not replace a timeout on the dependency call.

A repeat inference can produce a different proposal. It must return through validation and authorization, and it must not create a second operation identity for an already accepted write. Anthropic’s programmatic gates belong on this boundary as well as between model stages.

Key distinctions and trade-offs

The ownership split provides separate evidence for separate decisions:

Owner	Decision	Evidence it records
Orchestrator	Which accepted stage may run?	Case state and remaining deadline
Inference	What content or operation is proposed?	Model response and requested arguments
Executor	Is this invocation permitted and executable?	Validation, authorization, and dependency result
System of record	Has the business effect committed?	Durable operation identity and external receipt

Persisting accepted stages reduces repeated inference and improves recovery. A duplicate-safe write contract requires downstream engineering and retained operation identities. Those costs matter most where an uncertain repeat could move money or change a legally significant record. Adding more prompt checks is cheaper, but does not create that transaction contract.

Architecture / decision scenario

A financial-services team automates approved fee adjustments. Its application deadline is thirty seconds, and the ledger supports an operation-key lookup and duplicate-safe submission. Those are scenario constraints, not Claude defaults.

Claude proposes submit_adjustment. The executor validates the inputs against the approved case, verifies account authorization, and checks the business-calculated amount. The orchestrator persists the accepted operation and key before invoking the ledger. Inference has explicit Python max_retries and timeout settings that fit the remaining deadline; ledger calls have separate executor timeouts.

The ledger commits, but the response is lost. The executor records outcome_unknown and returns an error result describing the uncertainty. Recovery looks up the persisted key and obtains the committed receipt. It updates the transaction record without rerunning inference or submitting a different adjustment. If lookup remains unavailable at the deadline, the case goes to reconciliation with the accepted operation intact. The timeout changes who must investigate; it does not authorize a second debit or credit.

Common exam traps

Letting model arguments supply their own approval evidence.
Treating a saved model output as duplicate-safe external execution.
Using tool_use.id as the identity of a business operation across retries.
Interpreting a timed-out write as proof that nothing committed.
Applying Claude client retry settings to unrelated tool dependencies.
Restarting each layer’s retry or deadline budget independently.

What to remember

The model proposes, the executor checks, and the system of record commits. Preserve accepted transaction identity across restarts. Bound inference and dependency calls outside the model, and reconcile uncertain effects through the downstream service’s actual duplicate-prevention and lookup contract.