An agent produces a polished report saying that a new supplier meets every security requirement. The report contains citations, tables and confident conclusions. During review, a human discovers that one of the source systems was unavailable and another source described an outdated policy. The writing was coherent; the evidence was incomplete. A good architecture should make that situation visible before the report is treated as a decision-ready result.
The Context Management & Reliability domain of Claude Certified Architect – Foundations includes escalation, error propagation, human review and provenance. Anthropic’s published examination uses CCAR-F as the formal code, while CCA-F is the site label for the same exam. These topics are particularly important for multi-agent research and customer-support systems, because an agent’s job is often to explain what is known, what remains unresolved and who has authority to decide.
Escalate because the decision requires it, not because Claude is uncertain
There is a difference between normal uncertainty and a decision that should leave the automated workflow. A knowledge assistant can continue searching when an initially relevant document is incomplete. A customer-service agent can ask a clarifying question when a user has supplied an ambiguous order number. A refund request with a policy exception and potential financial impact may require an authorized human decision even when the user’s identity is clear.
The escalation rule should identify the actual trigger. Examples include multiple equally plausible records where choosing incorrectly would harm a customer; an action whose consequence exceeds delegated authority; and a business situation for which the existing policy supplies no decision rule. The surrounding service should encode those limits so that the model cannot talk itself into an exception by presenting a persuasive explanation.
Escalation is not automatically justified because a request is long, unfamiliar or difficult. The system may have a legitimate procedure for further retrieval, a bounded follow-up question or a safe partial response. Excessive escalation burdens staff and frustrates users. Under-escalation hides consequential risks. The architect’s task is to decide where automated interpretation ends and authorization must begin.
A practical support workflow might resolve ordinary billing questions, ask for a missing receipt when the rule requires one, and hand off cases involving a contested identity or discretionary compensation. It should record which branch was selected and why. That is more testable than instructing Claude to “ask a human whenever you do not feel confident.”
A human handoff needs enough context to act
A weak handoff forwards the last fifty conversational turns and asks a support specialist to work out what happened. A useful handoff is a compact decision record: the customer’s verified identity, requested outcome, relevant policy, evidence already checked, action attempted, reason for escalation and unresolved choices.
For a disputed refund, the agent can provide the order ID, verified purchase date, applicable policy section, current account status and the exact exception requested. The specialist should not have to reread unrelated small talk, and the handoff should not include hidden credentials or data from other customers. Evidence can be cited by safe record reference rather than duplicated in every message.
The handoff must also distinguish proposed actions from committed ones. “Refund recommended” and “refund issued” are different states. If a payment tool timed out, the agent should mark the operation as unknown and request a transaction lookup instead of telling the human that the refund failed. A timeline of actual tool receipts lets the reviewer avoid repeating a charge or refund while investigating.
If the human rejects a proposal, the workflow needs a way to represent that rejection. Resuming an agent after a denied approval should not cause it to try a differently named tool for the same disallowed action. The denial is a controlling fact until a legitimate new authorization or materially different request changes the decision.
Preserve source provenance through multi-agent synthesis
A research coordinator often receives evidence from separate agents: one reads policy documents, another searches technical references, a third examines a contract and another drafts the report. Each subagent can provide a useful summary, but summaries can discard the source details needed to substantiate the final claim.
A provenance-aware return preserves the document’s stable identifier, title, version, publication date, relevant passage location and the finding that depends on it. When two sources disagree, the coordinator should not remove one simply because the other is newer or more confidently worded. It should examine scope and authority: a current vendor announcement may describe a recent change, while an older contractual agreement may still govern a particular customer.
Suppose one research agent reports that an integration supports regional processing, while another finds documentation stating that only global endpoints are supported. The two claims could refer to different model generations or deployment products. The report should preserve their precise contexts instead of flattening them into “regional support: yes.” If the contradiction cannot be resolved, it becomes an explicit unresolved item with a targeted verification step.
This process is not just about adding citation links. A citation that points to a large page without connecting the page to the specific claim is weak evidence. A complete provenance chain lets the reviewer trace the final statement back through the subagent output to the appropriate source section and revision.
The context and recovery design is essential here because long-lived research jobs cannot rely on an unlimited model context to preserve this chain automatically. Durable source references and concise case-fact records are more dependable than an expanding transcript.
Make partial failure a valid, explicit result
An unavailable source should not turn into an empty finding. A policy search that returns no matching policy and a policy server that never responded have different meanings, even if both leave the agent without a text snippet. Their outputs should be distinguishable so that a coordinator can choose an appropriate next step.
Multi-agent systems need structured status reporting. A research subagent might return complete with cited findings, partial with a coverage explanation, or blocked with a specific access failure. A tool-level error should include the affected source, whether the operation can be retried and what evidence remains valid. That prevents a coordinator from assuming that silence means absence.
Local recovery should usually precede unnecessary human escalation. If a single source is temporarily unavailable, the subagent may retry within a bounded policy, use a permitted alternative source or mark that section incomplete. If the task requires that exact source for a consequential decision, the coordinator must not claim success based on loosely related material. It can publish a clearly limited preliminary result or stop the workflow pending access.
The same is true after a state-changing tool call. A timeout is not conclusive proof of failure. The system must reconcile the destination state before repeating the write. The agent-loop and tool boundary makes this a core architectural responsibility, not an optional note at the bottom of a response.
Confidence must be calibrated to evidence and consequences
A numeric confidence score can give an illusion of scientific precision when it is only the model’s impression of its own answer. An architect should ask how that score was calibrated: against which verified examples, for which kinds of task, and with what observed error rate? A score that predicts success on simple documents may be misleading for cases with conflicting evidence or incomplete records.
Human-review thresholds should reflect consequence as well as uncertainty. An ambiguous product recommendation may be acceptable with a disclosure. An ambiguous identity match before a sensitive account change is not. High-impact decisions may demand review even when a model believes the answer is straightforward. Policy ownership and tested authorization are stronger gates than a self-reported percentage.
Reviewers also need usable explanations, not just scores. A finding that cites two contradictory statements, labels one as older and identifies the missing issuer confirmation supports a real decision. A finding that says “93% confidence” without source details does not. For triage, calibrated risk categories and evidence descriptors can be more helpful than unsupported fine-grained numbers.
Sampling human reviews should account for rare but important cases. If most customer requests are routine, a random sample may miss the policy exceptions that matter most. Review sets can oversample ambiguous identities, unusual languages, failed tools, complicated contracts and other high-risk conditions. The purpose is to understand where the system fails, not merely to publish a favorable average.
Build a report that distinguishes facts, inferences and gaps
A reliable research report makes its evidence boundaries visible in the writing. Verified facts can be stated directly with sources. Interpretations should be identified as interpretations, particularly when comparing architecture alternatives. Missing issuer confirmation, unavailable documents or unresolved contradictions should not be hidden by a conclusive headline.
Consider a procurement assessment. The report can state that an integration supports a documented API feature, that a contract imposes a particular obligation, and that a regional deployment choice appears suitable if certain data-residency requirements hold. These are different claims. The first two may be sourced facts; the third is a design judgment dependent on explicit assumptions.
A coherent report can still be concise. It does not need to reproduce every tool log. It should carry a coverage summary, direct citations, significant contradictions, material assumptions and recommended verification work. This helps the reader decide what to trust and what to investigate further without confusing brevity with certainty.
For public educational content, this same discipline prevents stale or incorrect certification claims. An exam code, blueprint weight or eligibility rule should be attributed to the issuer where possible, while an instructional design example is clearly framed as an example. An old blog URL is not proof that a retired exam remains current.
Test escalation through consequential scenarios
Create a test suite with cases where escalation is required, optional or inappropriate. Include two accounts with matching names, a refund that exceeds a policy threshold, a service outage during a harmless information lookup, a missing document required for a regulatory statement and two conflicting sources with different revision dates.
For each case, specify the expected route: request clarification, retry safely, produce a limited answer, seek authorized human judgment or block a forbidden action. Evaluate whether the agent preserved actual tool receipts, passed correct source references, and avoided disclosing unrelated private data. A test that merely checks whether the final answer contains the word “escalate” is too shallow.
Also interrupt the workflow between research and synthesis. On resumption, verify that the coordinator knows which sources were checked and which were not, that it does not mistake a partial status for completion, and that prior human decisions remain binding. Include a deliberately misleading retrieved instruction and confirm that it cannot override the application policy or disclose unrelated records.
The CCA-F architectural lesson is practical: a responsible agent is not one that always answers and not one that always asks for help. It is one whose evidence, authority and failure state can be inspected independently. Good escalation protects consequential decisions, while provenance allows humans and software to understand the exact basis of the result. Together they turn fluent automation into a workflow that can be trusted without pretending the model is infallible.