An agent can return fluent answers, classify cases, and suggest actions while remaining uncertain about important facts. That uncertainty becomes a practical risk when a system serves customers, changes data, or informs decisions with regulatory and financial consequences. Human review is valuable when it is placed at a specific decision boundary and given enough evidence to resolve a question. Asking someone to glance at a generic confidence score is not a meaningful control.
Escalation begins by separating a missing fact from a missing permission. A tool response without a citation calls for more evidence; a request to change a customer record without an approved grant calls for an authorization boundary, not a more confident model answer. Claude Agent SDK tool hooks and human approval can help enforce that boundary, but the surrounding application must still retain request identity, source versions and the outcome of each approval.
Separate epistemic uncertainty from operational permission
An agent may be uncertain whether a document is current. It may also be completely certain what a customer requested but lack permission to perform the operation. These are different problems. The first requires better evidence, authoritative sources or a qualified reviewer. The second requires an authorization process. A model’s statement of high confidence does not supply missing permission, and a human review of factual accuracy does not automatically authorize a financial side effect.
Define which decisions the system may make autonomously, which require deterministic validation, which require human judgment, and which are prohibited. A read-only summarizer can usually present an evidence-labeled draft without altering records. A system that modifies account access must check authenticated identity, scope and approval through trusted software regardless of how well the model explains its recommendation.
Give reviewers a verifiable claim ledger
A final answer should not be the only artifact of a consequential research process. Keep a claim ledger with claim_id, statement, supporting source IDs, source version, location, effective date, applicable scope and validation status. For a document-based conclusion, those references allow another person to inspect exactly what the agent relied on. A source title alone is often insufficient when the document contains several versions or contradictory sections.
Labels such as SUPPORTED, PARTIALLY_SUPPORTED, CONFLICTED and NOT_VERIFIED communicate specific evidence states. Avoid presenting a self-generated 94% confidence score unless it has actually been calibrated against an appropriate labeled dataset. Reviewers need traceable records and decision criteria rather than numbers that imply precision without evidence.
Keep provenance through delegation and summarization
A multi-agent workflow may have a scout retrieve sources, an analyst extract claims and a writer produce a readable report. At each handoff, preserve the mapping between each claim and its source. Summarization can remove repetitive context, but not the identifiers, dates and restrictions that make an assertion verifiable. If a new worker receives “the documents agree” without the actual references, it cannot distinguish genuine agreement from duplication or an erroneous summary.
Source registries should be maintained by trusted retrieval code or a verifiable repository. A model must not invent a plausible URI to support an unsourced claim. When a worker cites an unknown ID, reject the reference or reopen the original material. This is more reliable than asking another model to choose which invented citation sounds credible.
Recognize when sources actually conflict
Suppose a 2024 operating policy says only the platform team can approve a connector, while a 2026 amendment grants a narrow exception to application teams in one controlled environment. A careless summary may say the later rule replaces the earlier one everywhere. A responsible synthesis compares effective dates, issuing authority, applicable systems and scope, then explains the exception without erasing the general rule.
Not every conflict is resolved by the newest timestamp. A later informal comment may have less authority than an earlier approved policy. The system should record what can be established, which interpretation remains uncertain and who can settle it. If a decision depends on that unsettled point, escalation is required before claiming the outcome is final.
Escalate for meaningful reasons
Good escalation triggers are measurable: contradictory authoritative sources, missing identity verification, insufficient evidence for a required field, high-impact operations outside policy limits, disputed customer consent, or an externally unconfirmed state. A generic instruction to escalate whenever the agent is unsure will cause inconsistent reviewer loads. Define the exact condition and expected evidence for each type of handoff.
For a high-impact action, route the case to an accountable reviewer who can verify the specific record and decision. For a low-impact informational answer, it may be appropriate to state uncertainty and what source would resolve it. The severity of the possible error should shape the amount of review, not the emotional tone of the model’s wording.
Worked case: conflicting vendor onboarding policies
A support organization asks a Claude-based assistant whether a particular vendor can be granted access to an internal ticketing workspace. The agent retrieves an approved 2025 onboarding procedure, a 2026 security addendum and a message from a project manager. The procedure allows basic vendor access after a standard check. The addendum restricts access to sensitive customer tickets. The project manager’s message appears to request an exception but contains no formal approval.
A correct claim ledger separates the facts: the vendor may qualify for basic access under the procedure, the sensitive-ticket restriction still applies, and the message does not prove that an authorized exception was granted. The assistant can prepare a recommendation with citations and request that the designated security reviewer resolve the exception. It cannot treat a chat message as a substitute for the required approval or silently grant privileges.
The handoff includes the specific vendor record, requested scope, source IDs and versions, conflicting passages and the exact decision required. If the reviewer authorizes restricted access, the service still enforces identity, resource scope and expiry. A report that merely says “human approved” without a bound authorization reference is insufficient for future audit.
Human review should be bound to an action
An approval record should describe what is approved, by whom, for which resource, under what constraints and for how long. If the target changes after approval, require a new check. A reviewer agreeing with a summary does not necessarily approve the associated operation. Keep evaluation of the model’s reasoning separate from permission to execute an external write.
For systems with many cases, allocate reviewer attention to those most likely to cause harm or require judgment. A routine low-risk record with source-backed fields may be validated automatically. A request involving ambiguous identity, protected data or irreversible effects should wait. Good design limits both missed risks and unnecessary review of cases ordinary code can handle.
Confidence calibration is an engineering measurement
If the workflow uses confidence estimates, evaluate them on labeled examples. A system that assigns high confidence to 100 claims should be correct on an appropriate proportion of those claims if the score is genuinely calibrated. Measure by issue type, source quality, model version and operational consequence rather than reporting one unqualified average. A confidence score from one task should not automatically transfer to unrelated tasks.
Compare the assistant’s classifications with reviewer findings, track the error rate for automatically accepted items, and refine thresholds when evidence shows a problem. Separate false alarms from misses. The purpose is to allocate risk intelligently, not to create a decorative percentage that makes the system appear scientific.
Failures, retries and incomplete evidence
A tool timeout may leave a research task incomplete; a slow external write may already have executed. These require different recovery procedures. For incomplete research, retry only missing sources within a documented budget and preserve accepted evidence. For an ambiguous side effect, query the authoritative system before repeating the operation. If the state cannot be confirmed, preserve an unresolved record and human escalation rather than reporting completion.
Treat long-running context similarly. Store stable task IDs, source versions, accepted claims, pending reviewer actions and last verified external state outside the model conversation. When the assistant resumes, it should load those records rather than rely solely on a compact conversational summary. A concise narrative can explain what happened, but it does not replace an auditable ledger.
Independent review of a Claude agent requires more than its final answer. Preserve model and prompt versions, retrieval-source IDs, tool permissions and results, approval decisions, and timestamps so a reviewer can reconstruct why an operation proceeded. Those GenAI audit evidence practices are useful across vendor platforms, but an audit framework does not itself define Claude Agent SDK behavior or replace authorization enforced by the application.
Review the reviewer workflow itself
Test fabricated citations, sources with changed effective dates, conflicting instructions in retrieved documents, missing approval evidence and reviewer responses that arrive after an operation expires. Reject unknown source IDs and treat prompt injection in untrusted documents as data, not authority to broaden tool permissions. Reviewers must be able to decline or request more information without cycling indefinitely.
Measure not just the number of escalations but their value: harmful actions prevented, unsupported claims corrected, reviewer time, repeated cases, delay and unresolved outcomes. If human review creates a backlog without improving decisions, refine the trigger criteria and supporting evidence rather than removing the safety boundary outright.
Different escalation reasons require different reviewer powers. A missing citation calls for evidence retrieval; two policies with conflicting effective dates require a source-of-truth decision; an otherwise correct refund proposal may still need independent authorization. In a controlled drill, record the queue item, cited documents and versions, proposed action, approval scope and disposition. The workflow should stop when a reviewer asks for new evidence, not convert that request into implicit permission. In third-party CCA-F human-oversight scenarios, a reviewer shown only an agent’s summary cannot resolve a conflicting policy date without seeing the original versions. The correct response is to request those sources rather than perform a ceremonial approval.
Architect Foundations connection
A useful escalation exercise starts with two policy records that disagree about an effective date and a tool capable of acting on the result. The agent should identify the disputed claim, attach both source versions and stop before the consequential operation. The reviewer then needs an explicit set of permitted dispositions: approve one interpretation with evidence, request a newer source, narrow the request or reject it. Each disposition should leave a traceable record and a clear next state.
Use the Claude Agent SDK documentation to determine how tool requests, hooks and session state are surfaced by the particular implementation. Then design escalation fixtures for a changed permission policy, late human approval and unresolved source conflict. Without an actual SDK run these remain test specifications; evidence of a successful check would require a trusted action record showing what was—and was not—allowed to execute, not the model’s confidence score.