Handoffs are contracts

Part 2 decided where an agent system should split. Part 3 showed why a familiar domain with many workflows can still belong to one agent. This part begins only after a boundary has earned its place.

The next question is not which framework primitive to call. It is what the system must decide before work crosses that boundary. A model calling another model is an implementation event. A handoff is an execution boundary with an owner, a bounded task, an information policy, an authority policy, and a result contract.

Key takeaways

• A justified agent boundary is incomplete until each edge has an explicit contract.
• Topology and conversational ownership are separate choices: delegation and transfer can appear in several system shapes.
• A complete contract names ownership, task, context, authority, and outcome.
• Security authority must be supplied, validated, or enforced by trusted runtime code; model output cannot grant it.
• Lifecycle, completeness, failure reason, coordinator disposition, and external-operation evidence must remain separate.

A justified boundary still needs a contract

Decomposition tells you why two responsibilities should not share one reasoning surface. It does not tell you what the source may send, what the receiver may do, who keeps the user's agenda, or what counts as a usable result. Those are edge decisions, and they can be wrong even when the nodes are right.

Imagine a customer-care coordinator dispatching a home-internet diagnostic to Network Operations. The organization chart makes the destination look obvious. Yet the useful questions begin only after routing: Does Network Operations own the conversation or only the diagnostic? Does it see the entire support history or just the service reference and current telemetry? May it restart a session? Can it schedule a technician? How does it report a reset whose provider outcome is unknown?

If those questions are unanswered, the system still behaves somehow. Framework defaults forward or isolate history. Prompts imply authority. Free-form prose stands in for a result schema. The contract exists; it is merely accidental.

Framework behavior (OpenAI Agents SDK): its current multi-agent documentation distinguishes a manager calling specialists as tools from handoffs that transfer the active conversation to a specialist. The handoffs documentation also exposes input filtering and structured handoff inputs. These are useful primitives, not a complete application contract.

Framework behavior (Microsoft Agent Framework): its current handoff orchestration documentation describes agent-as-tools and handoff workflows with different ownership behavior. Again, an API can express the transition without deciding the application's confidentiality, authorization, or evidence rules.

Architecture recommendation: define a boundary contract for every cross-agent edge. It should be reviewable without reading prompts or assuming a particular SDK. That makes a bad boundary attributable: the wrong receiver was selected, a required input was omitted, excess data crossed, policy refused the action, or external state could not be confirmed.

The contract does not promise that handoffs cannot fail. Models can propose the wrong route. Context can be stale. A specialist can time out. The contract changes where failure lands: from an untyped surprise inside shared prose to a specific, testable mismatch at an interface.

That testability is operational, not just architectural. A contract lets a team build fixtures for a missing dependency, a forbidden account reference, an expired approval, a partial result, and an unknown provider outcome. It also lets reviewers ask whether a production trace followed the declared edge rather than grading the model's prose after the fact.

Without an edge contract, teams often compensate by making the coordinator prompt longer. The prompt accumulates routing instructions, data-handling rules, tool limits, response formats, and recovery hints. Some guidance belongs there, but the prompt cannot provide transaction isolation, credential scoping, or a provider receipt. Moving those decisions into explicit fields reveals which layer can actually enforce them.

A contract is also a versioned dependency between teams. Network Operations can change its internal tools without changing the coordinator if it continues to accept the same brief and return the same outcome schema. Conversely, changing the meaning of needs_input or widening forwarded context is an interface change worth review, even if no model or SDK changes.

The five dimensions of a boundary contract

Every dispatch should answer five questions:

1. Ownership: Who acts next? Who owns the next user-facing turn and the wider workflow?
2. Task: What bounded objective should the receiver complete, and what is explicitly outside scope?
3. Context: Which facts, source slices, and references may and must cross?
4. Authority: Which effects may the receiver cause, under what approval and runtime enforcement?
5. Outcome: Which lifecycle state, result extent, reason, artifacts, and operation evidence return?

These dimensions are intentionally independent. A specialist may receive rich context but read-only authority. A coordinator may retain workflow ownership while delegating a task. A result may be lifecycle-complete but only partially satisfy the requested work. Collapsing any two dimensions hides a decision.

Ownership prevents a successful subtask from silently becoming ownership of the whole customer problem. Task prevents the receiver from filling ambiguity with adjacent work. Context prevents “it was available” from becoming the disclosure policy. Authority prevents an instruction from masquerading as enforcement. Outcome prevents fluent prose from becoming the only record of progress.

The five dimensions also fail differently. An ownership defect produces dropped or duplicated conversation turns. A task defect produces scope creep or a result the caller cannot consume. A context defect creates missing dependencies, privacy leakage, or anchoring on irrelevant history. An authority defect causes unauthorized or unexpectedly blocked effects. An outcome defect makes recovery guesswork. Keeping them separate improves diagnosis because the remediation is different in each case.

The contract should identify both a logical field and its evidence source. For example, service_ref is a task input, while its value is resolved from an authenticated account binding. appointment_hold_ref is an outcome field, while its validity comes from the dispatch provider. Schema validity answers whether the field has the expected shape; provenance answers why the runtime should rely on it.

The telecom explorer below applies the same field names to three justified edges. Select an edge, then inspect each dimension. The values differ because the purposes, information needs, and permitted effects differ.

Three telecom boundary contracts

Coordinator → Network Operations · delegation

✓Coordinator → Network OperationsCoordinator → Field ServiceCoordinator → Billing

✓OwnershipTaskContextAuthorityOutcome

Ownership

Network Operations owns the diagnostic task; the coordinator retains the customer conversation and compound outage agenda.

mode

delegation

conversation_owner

customer_care_coordinator

workflow_owner

customer_care_coordinator

return_to

customer_care_coordinator

Reset

The explorer is a design record, not a runtime object you must copy literally. Small read-only edges can reference a reviewed default. Consequential, sensitive, write-capable, or cross-organization edges deserve the explicit fields because the cost of ambiguity rises sharply at those boundaries.

Delegation and transfer answer different questions

The first ownership decision is whether control returns. In delegation, the dispatcher retains the conversation and reconciles a bounded result. In transfer, the receiver becomes active and owns the conversational episode until another transfer or exit.

Topology and conversational ownership are related but separate. A coordinator often delegates because it must preserve one user-facing voice, reconcile parallel work, and maintain approvals spanning specialists. That is a strong default, not a law. It can transfer a self-contained episode while trusted runtime code still retains global workflow state and policy responsibility.

Likewise, a router can call a bounded specialist and format the result rather than transferring the user. The label on a diagram does not settle who owns the next turn. Record mode, conversation_owner, workflow_owner, and return_to per edge.

The narrower safety rule is useful: do not transfer an unresolved compound agenda, a cross-specialist approval, or global policy responsibility to a specialist that cannot see and enforce it. A clean transfer is possible when the episode is truly independent, its necessary state moves deliberately, and the exit path is defined.

The return path deserves the same precision as the dispatch. A delegated worker may return to the coordinator, publish to a durable workflow, or time out while a late result remains possible. The coordinator needs a disposition for each case. Otherwise a late but valid specialist result can overwrite a newer decision, or two actors can both answer the user.

Transfer needs an exit contract too. Define how the receiver gives control back, what happens when it cannot resolve the episode, and where the wider agenda lives during the transfer. “The active agent changed” describes framework state; it does not prove the application preserved paused work or shared approvals.

User experience does not settle the mode. A delegated specialist can produce a directly streamed answer while the coordinator retains responsibility. A transferred specialist can still speak in one shared brand voice. Conversational presentation, topology, and workflow ownership are three choices that should be recorded independently.

Task briefs, selected context, and provenance

“Handle the customer's problem” is not a task brief. It restates uncertainty. A receiver needs an executable specification: objective, exclusions, resolved references, expected result, dependencies, time and effort limits, and an authority reference.

The brief should expose data dependencies instead of smuggling them through conversation history. If lodging depends on an arrival window chosen by a flight specialist, the flight result produces arrival_window; the coordinator injects that named value into the hotel task. “It was mentioned earlier” is not an interface.

Provenance needs more than “model-generated” versus “not model-generated.” Use three classes:

• Runtime-authoritative facts: authenticated principal, tenant, granted scopes, policy versions, credential bindings, and committed approval state.
• Model proposals: a possible objective, route, entity match, priority, tool choice, or lower self-imposed budget.
• Validated and enforced values: runtime code resolves an entity inside the authenticated tenant, clips a requested budget to an enforced ceiling, validates arguments, and rejects work outside scope.

An entity reference is not authorization. A model may correctly identify account-1842 and still be forbidden to read it. A budget in a prompt is not a budget unless trusted code prevents an operation above the ceiling.

Task briefs should be immutable inputs to one attempt, or at least carry a version. If the customer's scheduling constraint changes while Field Service is searching, the old task does not silently acquire new meaning. The coordinator can cancel it, accept a read-only result as stale evidence, or dispatch a revised brief. Explicit task identity makes that choice possible.

Dependencies should be named at the granularity the downstream task consumes. Field Service needs requires_field_visit, equipment class, and the service address; it does not need the network specialist's reasoning. Billing needs the verified outage interval; it does not need the reset transcript. This produces a small typed projection from the coordinator's state rather than a second copy of the entire case.

The expected result closes the loop. If the coordinator needs a hold reference, expiry, and approval reason, asking for “the best appointment” is incomplete. The brief should name the result schema and require those fields when the receiver returns needs_input. A contract test can then reject a plausible but unresumable response before it becomes workflow state.

Context selection then asks three independent questions. Confidentiality: may this receiver see the information? Integrity: is it authoritative, user-claimed, untrusted, or derived? Purpose: does the receiver need it for this task?

Framework behavior (OpenAI Agents SDK): handoffs normally carry the conversation unless an input filter changes it, while local application context is not automatically sent to the model; the context guide separates those ideas. Framework behavior (Anthropic Agent SDK): subagents start with their own context and receive a scoped prompt. Neither default knows your data policy.

Choose the smallest sufficient context, not the smallest possible context. Enumerable facts often fit a structured brief plus declared source slices. Conversational nuance may require a relevant transcript segment. Independent review may benefit from a fresh context plus the artifact under review. Sensitive data unnecessary for the purpose should be excluded regardless of token cost.

Author inference: the distinction between enumerable dependencies and conversational nuance is a practical heuristic, not a universal empirical law. Recurring clarification, duplicate work, and missing dependencies suggest a policy is too narrow. Irrelevant sensitive data, high token cost, and anchoring on stale dialogue suggest it is too broad. Evaluate both failure modes against real traces.

Prefer stable references or raw source slices over generative summaries where exact wording matters. A summary is useful orientation but remains a lossy transformation. Reservation terms, provider policy, telemetry events, and tool receipts should remain reachable as evidence.

Context policy also applies on the way back. A specialist result can contain more than the coordinator or user should receive. Tool traces may include internal identifiers, sensitive diagnostics, or untrusted provider text. Define which result fields enter workflow state, which are retained as restricted evidence, and which may appear in the user-facing response. Filtering only the outbound brief solves half the data-flow problem.

Summaries need provenance of their own: source references, producing actor, creation time, and ideally a schema or purpose. A later receiver should know whether a line came from telemetry, the customer, a remote agent, or another model's compression. “Present in context” is not an integrity label.

Microsoft's FIDES security model is experimental. Its separate integrity and confidentiality labels are not a universal production standard, but they illustrate a durable point: tool permission and information permission are different controls.

Authority belongs at a deterministic boundary

Authority answers what the receiver may cause, not what it knows. Record allowed operations, credential and tenant scope, approval requirements, ceilings, policy version, enforcement location, and which effects require idempotency or later reconciliation.

The model can explain policy and propose an action. It must not grant itself authority by emitting a convincing field. Trusted application or runtime code must validate identity, scope, policy, and approval before the tool boundary executes or refuses the effect.

Framework behavior (OpenAI Agents SDK): the current human-in-the-loop documentation shows tool approvals interrupting execution, including tools reached through handoffs or agents used as tools. The SDK's handoff documentation also notes that input guardrails apply to the first agent and output guardrails to the final agent, while tool guardrails surround custom function calls. Therefore an application must name the enforcement layer instead of assuming every check follows every handoff.

For a consequential write, the shape is simple: the model proposes; runtime code resolves and validates; a policy-aware tool gateway executes or denies; the result carries an operation reference. Prompts can reduce bad proposals. They do not replace authorization.

Validation must happen close enough to execution that mutable facts cannot drift unnoticed. A customer can lose account access after the brief was built. A hold can expire between approval and confirmation. A policy ceiling can change. The gateway should recheck the facts that protect the effect, not trust that they were true when a model began reasoning.

Policy versions make decisions explainable. Recording credit-policy-v9 does not force the receiver to carry the whole policy document; it identifies which rule set the trusted gateway evaluated. If a newer version applies at execution, the continuation policy can require a fresh evaluation rather than silently using stale eligibility.

Least privilege applies to operations and resources. Giving Billing only an apply_service_credit tool is incomplete if the credential behind it can act on every tenant. The boundary should bind the credential scope to the authenticated account or require the gateway to derive that scope independently from the session. A model-supplied account ID can be an input to resolution, never the proof of access.

This separation also keeps architecture portable. Whether the receiver is a local subagent, a graph node, another service, or a remote A2A agent, the caller can enforce what it controls before sending work and can verify what it observes afterward.

Outcomes need a taxonomy and layered evidence

A single status field often mixes incompatible questions. completed, partial, provider_timeout, needs_input, and policy_denied are not peers. They combine lifecycle, completeness, failure cause, and control flow.

Keep at least five dimensions separate:

needs_input is an interruption, not necessarily a failure and not terminal success. The specialist can return useful partial work while waiting for one bounded user decision.

The A2A v1.0 specification similarly distinguishes terminal task states from input-required and auth-required interruptions. But an A2A task state or artifact is remote-reported evidence. It does not prove the remote agent's internal tool calls or the final state of every provider it contacted.

A local operation ledger has the same limit. It records what the local boundary observed, not external truth. An idempotency key helps only when the system that owns the effect enforces deduplication. Stripe's idempotent-request documentation is a concrete provider example. AWS transactional-outbox guidance also warns that duplicate delivery remains possible and consumers must be idempotent.

Layer operation evidence: local intent recorded; request attempted; provider acknowledgement received; external state confirmed or reconciled; or outcome unknown. Stable references let later retry, compensation, and reconciliation machinery investigate without pretending the envelope itself proves the effect.

Coordinator disposition belongs in this taxonomy because the caller and worker observe different lifecycles. A specialist may complete after the coordinator's deadline. The worker truth is completed; the coordinator truth may be timed_out with a late result quarantined for reconciliation. Neither value should overwrite the other.

Result extent is similarly orthogonal. A task can complete normally with a partial result because some requested items were unavailable. It can fail after producing useful evidence. It can pause for input after holding a resource. A coordinator that branches only on status cannot distinguish those cases without parsing prose.

Reason codes should remain bounded and machine-actionable while explanations can remain human-readable. appointment_requires_approval supports a known next step. The sentence explaining which slot triggered the rule belongs beside it. Do not grow lifecycle into hundreds of domain-specific values simply to avoid a separate reason field.

Telecom outage: three contracts, one agenda

A customer says: “My home internet has been down since last night. Try to restore it, book the earliest technician if it can't be fixed remotely, and apply any outage credit I qualify for. Ask me before accepting an appointment after 5 p.m.”

Assume this provider has genuinely separate operational surfaces. Network Operations can inspect line telemetry and perform approved recovery. Field Service owns appointment inventory and dispatch. Billing evaluates credits under a separate policy. That assumption matters: the word “telecom” does not prove that three agents are necessary. The boundaries were justified earlier by distinct authority, context, and lifecycle needs.

The coordinator first delegates the diagnostic. The user phrase “since last night” remains a claim. The runtime-resolved service reference and provider telemetry are authoritative inputs. The network gateway permits one reset for that service and refuses undocumented controls.

Trace

Home-internet outage: one compound agenda

1. Thought

   Coordinator decomposes restoration, technician fallback, and outage credit while retaining the customer conversation.

2. Tool callnetwork_operations.run_diagnostic820ms

   Delegate the bounded diagnostic contract.

   Input

   {
     "service_ref": "s-1842",
     "device_ref": "ont-93",
     "authority_ref": "network-policy-v7",
     "max_recovery_attempts": 1
   }

3. Observation

   Diagnostic completed; remote recovery failed and a field visit is required.

   Output

   {
     "state": "completed",
     "result_extent": "full",
     "reason_code": "remote_recovery_failed",
     "outage_ref": "out-7714",
     "reset_ref": "reset-551"
   }

4. Tool callcoordinator.dispatch_parallel1.04s

   Dispatch independent Field Service and Billing contracts with different context and authority.

   Input

   {
     "tasks": [
       "hold_earliest_visit",
       "evaluate_outage_credit"
     ],
     "dependency": "out-7714"
   }

5. Observation

   Field Service needs approval for a 6:30 p.m. hold; Billing reports a confirmed $18.40 credit.

   Output

   {
     "field": {
       "state": "needs_input",
       "result_extent": "partial",
       "hold_ref": "hold-208"
     },
     "billing": {
       "state": "completed",
       "result_extent": "full",
       "credit_ref": "credit-992",
       "amount": 18.4
     }
   }

6. Final310ms

   Remote recovery did not restore service. I found a 6:30 p.m. visit; would you like me to confirm it? An $18.40 outage credit was applied.

The verified diagnostic result opens two independent branches. Field Service receives the service address, outage reference, equipment class, and scheduling constraint. It does not receive payment history or raw line telemetry. Its gateway permits search and a temporary hold, but blocks confirmation of the evening slot without approval.

Billing receives the account reference, verified outage interval, service plan, and outage reference. It does not receive the street address, modem logs, or appointment discussion. The gateway computes the eligible credit and enforces the automatic maximum. The model does not choose its own spending authority.

The two results can return in either order. The coordinator does not flatten them into one status. Billing is complete and full. Field Service is interrupted with a partial result and a hold reference. The overall customer agenda remains open because one decision is pending.

This sequence exposes why the coordinator's state and each edge contract must agree. The diagnostic produces outage_ref and requires_field_visit; those named values make the two downstream tasks ready. Field Service produces a hold and expiry; those values create an approval gate. Billing produces a credit reference and receipt; those values close only the billing branch. No specialist needs to infer the whole dependency graph.

The example also yields concrete contract tests. Remove outage_ref and neither downstream dispatch should occur. Add payment history to the Field Service brief and the context-policy test should fail. Ask Field Service to confirm the evening slot without a committed approval and the gateway should deny it. Return completed without result extent or a hold expiry and the outcome validator should reject the envelope as incomplete.

Those tests remain valuable when prompts and models change. They do not prove that the specialist will reason well, but they fence the inputs and effects that matter most. Model evaluations can then focus on route quality, task completion, and explanation instead of carrying the entire burden of application safety.

If the customer approves, the continuation policy decides whether to resume the held task or dispatch a fresh confirmation using hold-208. Architecture recommendation: choose contextually. Resume may be appropriate when the checkpoint is durable, observable, and still policy-compatible. Redispatch may be safer when clean revalidation matters or retained context is stale. Neither is a universal default. In both cases, runtime code revalidates the hold, user, policy, and approval before confirmation.

Travel disruption across provider boundaries

A traveler says: “My flight to Chicago was canceled. Rebook me tonight with an aisle seat, and arrange a hotel if an overnight connection is unavoidable—but don't spend more than $250 without asking.”

This is a secondary example because the same five dimensions survive a change of domain and deployment distance. Rebooking and lodging may cross organization or provider boundaries. Availability changes during the run. The hotel task is not ready until a selected itinerary establishes arrival and connection facts.

The coordinator first delegates option discovery. The flight specialist receives a reservation reference, traveler identity binding, loyalty status, route, date, seat preference, and airline policy scope. It may search and perhaps hold an itinerary; whether it may confirm without approval is an explicit authority decision.

If the selected itinerary creates an overnight connection, its result produces named slots such as overnight_required, hotel_location, check_in_date, and check_out_date. Only then does the hotel task become ready. It receives those slots, required room preferences, a stable payment binding, and a runtime-enforced ceiling. It does not need the whole airline conversation or unrelated travel history.

Suppose the flight is held but the only suitable airport hotel costs $268. The hotel result can be needs_input with result_extent: partial, reason spending_approval_required, the flight and hotel option references, the $268 price, and the enforced $250 ceiling. The coordinator now asks a bounded question: approve the extra $18, search farther away, or keep only the flight.

The user's sentence is evidence of intent, not the enforcement mechanism. A trusted application records the ceiling, binds it to the authenticated traveler and payment scope, and prevents an over-limit booking without valid approval.

Across an A2A boundary, a remote task status and artifacts help the local coordinator reason. They remain provider reports, not proof of internal effects. The local contract should record protocol version, remote agent identity, task and artifact references, and any independent airline, hotel, or payment receipt available for reconciliation.

Cross-provider work adds failure modes that a local agent boundary can hide. The remote task may outlive the local request. A network timeout can leave the booking outcome unknown. Provider identity or capabilities can change between discovery and execution. The contract should distinguish a message-delivery failure from a task failure and an unknown external effect.

It should also bound what the remote party learns. A hotel provider needs dates, location, occupancy, and applicable preferences; it does not automatically need the canceled-flight transcript, loyalty history, or the reason for travel. A2A interoperability moves structured messages. It does not decide purpose limitation or authorize data disclosure for the application.

Keep a boundary-contract register

The durable output is a boundary-contract register. For each edge, record the named source and destination; ownership mode and owners; task schema; context policy; authority policy; outcome schema; continuation policy; and evidence references. The three telecom edges in the explorer form one register entry set. The flight and lodging edges form another, potentially across different trust domains.

Do not force equal ceremony onto every edge. A low-risk read-only lookup can reference a named reviewed default. A write-capable, sensitive, externally visible, or cross-organization edge should spell out its decisions. The point is not paperwork. It is making the edges with the greatest blast radius inspectable before they fail.

Review the register in both directions. From the caller's side, ask whether every dispatch has a bounded purpose, sufficient inputs, and a consumable result. From the receiver's side, ask whether it can reject missing dependencies, distinguish authority from data, and return an interruption without losing work. From the security side, ask where identity, policy, approval, and resource scope are actually enforced.

Version the contract when meanings change, not only when fields change. If completed once meant “provider acknowledged” and later means “external state confirmed,” that is a breaking change even if the JSON shape is identical. Keep old traces interpretable by recording the schema and policy versions used for a run.

Finally, connect the register to evidence. A diagram or ADR that never appears in tests and traces decays into documentation theater. Emit the contract identifier, task identity, policy version, context projection version, and result schema in the trace. Avoid logging sensitive values merely to prove the fields existed.

Common anti-patterns are recognizable:

• Framework-default context: nobody decided what information should cross.
• Prose-blob brief: objective, exclusions, dependencies, and expected result are ambiguous.
• Model-granted authority: a prompt or model field is treated as identity, authorization, approval, or policy enforcement.
• Permissions without data policy: tools are restricted while sensitive context is forwarded indiscriminately.
• One overloaded status: lifecycle, completeness, cause, coordinator observation, and external evidence are conflated.
• Envelope as proof: a worker report or local ledger is treated as external truth.
• History as dependency: a specialist must excavate an earlier result from transcript prose.
• Universal resume or redispatch: one continuation mechanism is applied without considering durability, staleness, and revalidation.
• Transfer of unresolved agenda: a specialist inherits responsibility it cannot see or enforce.
• Uniform ceremony: trivial reads receive the same process as consequential writes.

Check your understanding

A Field Service specialist returns a held 6:30 p.m. slot that needs customer approval. Which result is the soundest contract response?

A Field Service specialist returns a held 6:30 p.m. slot that needs customer approval. Which result is the soundest contract response?AMark the task failed because it did not confirm the appointment.BReturn needs_input, partial extent, an approval reason, hold reference, expiry, and coordinator disposition.CMark it completed because the model found a slot and let the transcript carry the approval detail.

The register extends the decomposition decision without replacing it. Decomposition says why a boundary exists; the contract says what may cross and what must return. The next problem is what the coordinator remembers while several such contracts are active.

Part 5 separates useful conversation history from explicit workflow state. That distinction is what allows the telecom coordinator to know which work completed, which hold is pending, which version a parallel result was based on, and what must be revalidated after an interruption.

Detailed approval mechanics, retry and recovery policy, compensation, observability, and cross-organization A2A trust are intentionally deferred to later parts. The contract gives those mechanisms named inputs and evidence to work with.

Primary sources

• OpenAI, Agents SDK — Agent orchestration — documentation accessed July 22, 2026
• OpenAI, Agents SDK — Handoffs — documentation accessed July 22, 2026
• OpenAI, Agents SDK — Context management — documentation accessed July 22, 2026
• OpenAI, Agents SDK — Human in the loop — documentation accessed July 22, 2026
• Microsoft, Agent Framework — Handoff orchestration — documentation accessed July 22, 2026
• Microsoft, Agent Security with FIDES — experimental, updated June 23, 2026
• Anthropic, Agent SDK — Subagents — documentation accessed July 22, 2026
• A2A Project, A2A Protocol v1.0 Specification — specification accessed July 22, 2026
• AWS, Transactional outbox pattern — documentation accessed July 22, 2026
• Stripe, Idempotent requests — documentation accessed July 22, 2026