A coordinator asks three Claude workers to investigate a supplier. Identity and contract checks return evidence, but the payment worker cannot access its ledger and emits an empty findings list. If the parent interprets that empty list as ‘no suspicious payments,’ its recommendation becomes more confident precisely because an important check failed. A multi-agent design for Anthropic CCA-F should encode the difference between “the search found no adverse payment” and “the payment search could not run”; a coordinator must never infer the first from the second. The parent can preserve partial findings, retry a safe read or escalate, but it cannot treat a broken dependency as a clean result.
An empty result is not a failed investigation
Imagine a worker asked to locate adverse-payment entries. It returns an empty list in two very different situations. In the first, it queried the correct authorized ledger for the agreed period and genuinely found no matches. In the second, the query failed because its credentials expired. The coordinator may receive identical-looking output if the worker contract includes only a list of findings. This is an information-loss defect. A useful result needs a separate execution status and an evidence-coverage statement, even when the finding list is empty.
A robust response distinguishes completed, incomplete, blocked, failed and canceled work. Completed means the named checks ran against the intended evidence; incomplete means some checks succeeded but required coverage remains; blocked identifies a missing permission or prerequisite; failed records an execution error; canceled indicates work stopped by policy or orchestration. These are application-level states to design and validate, not a claim that every Claude framework ships these exact enum values. What matters is that no downstream agent can quietly reinterpret “could not check” as “checked and found nothing.”
Specify the failure envelope before dispatch
Every delegated task should identify its question, permitted tools, source scope, deadline, output schema and owner of any consequential decision. Then define an error envelope that includes the task identifier, worker identity, status, error category, short sanitized reason, attempts made, source checks completed and unresolved requirements. The coordinator can compare that envelope with the task contract to decide whether the work is sufficient. A free-form apology such as “Sorry, I had trouble” cannot establish whether the worker saw confidential records, sent a transaction or never reached the data source.
Keep the record smaller than the entire worker transcript. A service outage may produce thousands of repeated stack-trace lines, but the coordinator needs the authoritative request ID, affected source, failure category and any ambiguous side effects. Detailed logs can remain available to authorized operators. Do not copy tokens, unrestricted customer data or secret configuration into an error summary. Good failure propagation carries exactly the information required to decide the next safe action, while preserving richer forensic evidence separately.
Separate protocol errors from task-level uncertainty
In Claude’s client-tool protocol, a tool failure can be returned as a tool_result with is_error: true, tied to the corresponding tool-use identifier. That is useful for telling the model the operation failed. But a parent-agent failure contract must go further: which part of the delegated investigation did the failed call affect, and was the overall task still partially successful? The coordinator should not infer comprehensive task status from a single error flag, especially if the worker also completed independent checks.
Conversely, a worker may execute every tool successfully and still be unable to answer its business question. A legal name may remain ambiguous because two records disagree. That is not a transport failure; it is a substantive evidence conflict requiring additional investigation or human review. Return both operational outcome and analytical coverage. When the coordinator receives a finished task, it should validate that required evidence is present and acceptable, not merely that the worker’s final message lacks an error.
Make dependencies and blocked conclusions explicit
A supplier’s payment analysis depends on the verified legal entity. If identity verification is blocked, a payment worker cannot safely compensate by searching accounts with similar names. Represent the dependency in the task graph: verified entity ID is required, and the downstream audit stays blocked until it exists. Other work, such as reading a public procurement policy, may continue independently. This limits the damage from one unavailable source without manufacturing a complete decision.
The coordinator should also know which final conclusions require all branches and which can tolerate missing optional evidence. A customer-support summary might state the facts already verified and flag missing account history. It must not assert that the account has never been charged twice when the payments ledger was unavailable. Treat the coverage requirement as part of the final-answer contract, ideally with a checklist or typed prerequisites evaluated by the application. A persuasive conclusion that omits one required branch is still incomplete.
Choose local recovery only when its outcome is safe
Local retry policy depends on the task dependency graph: an optional research branch may fail without blocking a final report, while an unverified identity prerequisite must stop dependent financial analysis. If the record still contains mutually inconsistent evidence, route it through explicit ambiguity escalation rather than making the coordinator average the incomplete answers. Worker error states should determine the safe next step, not just the tone of the final response.
A worker that receives a malformed input response may be able to fix one parameter and retry. A rate limit may justify bounded backoff. An authorization denial usually requires a legitimate permission workflow rather than endless retries. The coordinator should learn which category occurred and whether local recovery was attempted. If a worker exhausts its retry budget, return the unresolved state rather than suppressing the error. This prevents a slow, expensive loop from appearing productive simply because it keeps generating tool activity.
Actions with side effects demand stronger treatment. Suppose a delegated billing worker submitted a refund but lost the acknowledgment. The parent must not launch a replacement worker that repeats the refund just because the first one reported failure. Query an authoritative transaction status using the original operation identifier, or stop for manual reconciliation when that is unavailable. The tool-recovery boundary applies across subagents too: conversation failure does not erase a possibly committed external action.
Preserve partial success without laundering missing evidence
A research worker may review four of five authorized documents before one source becomes unavailable. Discarding every confirmed finding wastes work; describing all five as reviewed is worse. Return a completed-source list, the verified observations with references, and a precise coverage gap for the fifth. The coordinator can use the accepted observations for a qualified interim report while holding any conclusion that depends on the missing document. The line between partial research and accepted final judgment must remain visible.
Provenance matters when findings move between workers. A second specialist might be asked to reconcile one discrepancy, but it should receive the original source identifiers and an exact unresolved question, not a summary that turns the first worker’s guess into verified fact. This links failure handling to evidence provenance. The purpose of an error envelope is not merely better debugging; it protects the meaning of the available evidence as the workflow delegates, consolidates and restarts.
Budget and cancellation need their own semantics
Three specialists may have different deadlines. A fraud screening check could be mandatory before the decision, while a background search for general company news is useful but optional. If the optional worker exceeds its time budget, the coordinator can cancel it and continue with a documented limitation. If the mandatory identity check times out, the decision must stay on hold. A blanket rule to proceed when two of three workers finish would confuse quorum with coverage and reward the system for skipping the hardest check.
Late results create another hazard. A worker might finish after the coordinator has already issued a conditional report, or after a human reviewer has supplied a corrected document. Tag outputs with task and case revisions so outdated findings cannot silently overwrite current decisions. Cancellation means no further result is expected for that task version; it does not prove a remote action that was already submitted was canceled. Clear state transitions and idempotency controls protect the application from these races.
Test propagation under deliberate failures
A happy-path demonstration with three cooperating agents says little about reliability. In the test suite, deny one worker source access, introduce a malformed tool payload, delay an independent worker and force a timeout after a write has been submitted. Verify that the coordinator distinguishes the situations and chooses the policy-compliant response: retry an authorized read, retain partial coverage, hold a required decision or reconcile ambiguous side effects. Check the external systems to confirm prohibited repeat operations did not occur.
Quality metrics should include coverage correctness, hidden-failure rate, false clean results, safe retry behavior and the amount of additional human work created by the recovery path. Measuring only the fluency of the final report can miss the central defect: a summary may read beautifully while presenting missing evidence as reassuring silence. Preserve representative failure traces as regression cases when the agent framework or orchestration prompts change. The lessons from agent evaluation and guardrails apply to the complete workflow, not just each worker.
Finish the supplier investigation without guessing
Return to the three-worker supplier review. The identity worker confirms the registered entity and lists its authoritative sources. The contract worker identifies a termination clause and cites the signed agreement. The payment worker returns a blocked state: the ledger is inaccessible, no payment-period coverage has been established, and no payment-related finding can be accepted. The coordinator can report the verified legal and contract facts but cannot issue an unconditional low-risk supplier recommendation because a mandatory financial check remains open.
An authorized operator restores the ledger access, the payment branch resumes against the same verified supplier identifier and the new result is reconciled with the original case revision. Only after required evidence has been accepted does the coordinator produce the decision packet for the responsible reviewer. The architectural answer is not to multiply agents or make the prompt more insistent. It is to preserve execution status, coverage and source identity across every handoff, so a failed component cannot silently convert uncertainty into false reassurance.