Skip to lesson

AnthropicClaude Certified Architect – Professional2026-101.4 Design multi-agent systems and orchestration strategies

Make delegation contracts preserve decision evidence

Completed by the knowledge check

Learning objective

Define agent roles, delegation contracts, scoped tool sets, and structured handoffs that preserve evidence, provenance, and uncertainty.

Core idea

For an architect integrating specialists across runtimes, the contract must outlive the framework that dispatches them. Assume role definitions and attributed evidence records. The professional addition is an explicit agreement about authority, acceptable evidence, unresolved uncertainty, and who can accept a handoff as sufficient for the next decision.

Anthropic’s research account requires clear objectives, output formats, tool and source guidance, and task boundaries. Turn those into a portable contract with runtime-specific enforcement. A structured report is an inspectable deliverable, not automatic permission to act on its conclusions.

How it works

Assign decision authority with the role

Define what a role establishes and what remains another owner’s decision. An evidence reviewer can identify a requirement and its qualifications. It does not thereby authorize a business exception. A synthesis role can compare accepted records, but it cannot silently grant itself permission to fill a missing clause from memory.

Write the reusable contract around the evidence standard, permitted actions, and acceptance conditions. Supply the particular task’s question, source set, time period, and required coverage in its assignment. In the Agent SDK, these map to AgentDefinition.prompt and the Agent invocation’s prompt. Use the same conceptual split when your application supplies a Messages API tool definition and dispatches work itself.

The portable contract names an accountable recipient. For a hierarchy, the branch lead accepts leaf reports and the root accepts branch coverage; see 1.4.2. Preserve the boundary between a worker’s claimed completion and a recipient’s acceptance. A worker can finish its assigned investigation with unresolved evidence while the downstream business decision remains blocked.

Map scope into capabilities

Recall that the SDK specialist’s tools list restricts its tool inventory, while top-level allowedTools pre-approves calls. For each portable role, record how its capability label maps to the chosen runtime’s actual tool inventory and backing-service permissions. A “read only” label must name which adapters can retrieve documents, which source locations they can access, and which actions they cannot perform.

Review indirect capabilities during that mapping. Removing a dedicated publication tool while leaving unrestricted command execution can preserve another path to publication. In an SDK adapter, remove Bash as well when the role needs no commands; in an application-owned dispatcher, expose only the required retrieval operations and use a service identity without publication permission. These are adapter choices for the role’s contract, not a universal tool list.

When an adapter changes, review each allowed operation against the same role authority before accepting its outputs. Confirm that the replacement can retrieve required evidence without gaining edit or publication access. Record any capability mismatch as a contract failure rather than silently broadening the role or narrowing its evidence obligations. The role prompt states the rule; the tool inventory and service permissions enforce the available paths.

Carry uncertainty as an evidence obligation

Use uncertainty fields that tell the next owner what remains unresolved. Anthropic’s hallucination guidance explicitly permits admitting insufficient information, grounding claims in quotations, and checking claims against supporting passages. Apply that guidance to the contract: an unknown is a valid reportable outcome with a reason, an affected claim, and a proposed way to resolve it.

Distinguish missing source access, insufficient coverage, interpretive ambiguity, and credible conflict. Missing access means an operation did not establish evidence. Insufficient coverage means the available source set does not settle the requested question. Ambiguity means a passage admits materially different readings. Conflict means credible records support incompatible assertions after their scope is considered.

These are application classifications, not Anthropic enum values. Define them precisely enough that downstream stages cannot convert “not assessed” into “no requirement.” An uncertainty record should identify which conclusion it blocks. A general low-confidence label gives no such dependency information.

Keep competing evidence until the authorized recipient resolves it. A reconciliation record states the chosen treatment and its reason, while retaining the original claims. Do not let the summarizing agent erase a discrepancy merely because the contract asks for a concise conclusion. Specialist uncertainty and coordinator acceptance are separate records.

Design a handoff the recipient can validate

The following example is an application-defined handoff for hypothetical internal documents. Its fields are not SDK response fields:

{
  "task_id": "RETENTION-REVIEW-7",
  "contract_version": "1",
  "producer_role": "policy-reviewer",
  "coverage": "partial",
  "evidence": [
    {
      "id": "E1",
      "content": "Delete the export after the approved review ends.",
      "source": {
        "document_id": "POLICY-42",
        "revision": "3",
        "location": "Exports, paragraph 2"
      }
    }
  ],
  "findings": [
    {
      "id": "F1",
      "claim": "The clause covers review exports.",
      "evidence_ids": ["E1"]
    }
  ],
  "uncertainties": [
    {
      "kind": "insufficient_coverage",
      "affects": "backup-retention-decision",
      "reason": "No supplied clause addresses backup copies.",
      "next_action": "Request the backup policy from its owner."
    }
  ]
}

The added contract version and task identity let the recipient validate the expected shape and assignment. Source revision makes the finding’s provenance more specific than a mutable document title. The uncertainty names the affected decision and recovery owner instead of asking the next agent to infer the gap.

Validate structural completeness, then check that the evidence belongs to the named source and supports the claim at the assigned scope. Record acceptance or rejection separately.

For large handoffs, use the artifact-reference pattern Anthropic describes. The artifact retains full evidence, provenance, and unresolved obligations; the message carries its reference and a concise account. Confirm the recipient can retrieve it with its scoped tools. A compact reference that the next role cannot open transfers no usable evidence.

Key distinctions and trade-offs

Portable contract versus runtime adapter: The contract describes role authority, evidence obligations, and acceptance. The adapter supplies prompts, actual tool restrictions, and result extraction for the chosen runtime. Changing frameworks should not silently change decision authority.

Provenance versus uncertainty: Provenance identifies where a finding came from. Uncertainty identifies what that evidence leaves unsettled. A fully attributed claim can still be insufficient for the requested decision.

Concise handoff versus lossy handoff: Reduce irrelevant intermediate material while retaining evidence, qualifiers, and affected decisions. Compactness is useful when it preserves those relationships; otherwise it moves the investigation cost into the next stage.

Architecture / decision scenario

A healthcare organization has three engineers building an assistant that compares internal data-handling policies. Its contractual requirement is that every recommendation identifies supporting policy revisions and routes undocumented treatment to the policy owner before release. The scenario assesses internal documents, not a vendor’s regulatory eligibility.

You separate evidence reviewers from synthesis and release acceptance. Each reviewer gets only the supplied-document tools, a versioned output contract, and the exact policy scope. Two reviewers return different retention clauses, while one reports that backup coverage is insufficient. Synthesis receives both clauses and the uncertainty record; it cannot invent a backup rule to finish its comparison.

The acceptance owner checks the source revisions and claim support, records the conflict treatment, and requests the backup policy from its responsible owner. Supported portions can proceed as a limited comparison, but the backup recommendation stays unresolved. When a different runtime replaces the SDK implementation, its adapter must preserve these same capabilities, records, and acceptance rules.

Common exam traps

  • Treating a role name or prompt prohibition as an enforced capability boundary.
  • Assuming a role’s “read only” label preserves its authority when the runtime adapter changes.
  • Transferring a source reference that the recipient cannot retrieve.
  • Keeping provenance while dropping which decision an uncertainty blocks.
  • Treating a worker’s coverage: "partial" report as accepted without a recipient decision.
  • Allowing synthesis to resolve credible conflicts without an accountable decision.

What to remember

Define a role’s authority, achievable tool scope, evidence standard, and acceptance owner together. Preserve uncertainty as a specific unresolved obligation attached to a decision. Runtime adapters may differ, but the contract must keep evidence and authority intact across every handoff.

Knowledge check

References