I6 — A2A Delegation

Delegate a task from one agent to another across a system, vendor, or organisational boundary using a standardised wire protocol — task submission, streaming status, structured result, defined cancellation — so cross-system multi-agent collaboration does not require bespoke integration for every pairing.

Also Known As: Agent-to-Agent Protocol, Agent2Agent, A2A, Cross-Vendor Task Delegation, Inter-System Agent RPC. (The historical IBM/Red Hat ACP variant merged into A2A under the Linux Foundation in 2025; the unified protocol is now simply A2A.)

Classification: Category VI — Integration · the agent-level inter-system delegation pattern — the wire counterpart to O15 Agent Handoff (intra-system) and the agent-level counterpart to I3 MCP Server (tool-level).

Intent

Make a cross-boundary agent call interoperable by default — discover the executor via its Agent Card, submit a typed task, stream status, receive a structured result, and handle failure as a defined protocol event rather than a bespoke integration.

Motivation

Single-system multi-agent orchestration is a solved problem: an Orchestrator (O6 Orchestrator-Workers) calls a Worker via a function call or message queue, both run in the same process or codebase, and shared memory carries context. As agent ecosystems extend across vendors, platforms, and organisations, that in-process assumption breaks. An orchestrator built on one stack needs to delegate to a specialist agent built on another, hosted by another team, and authenticated through another identity system. Without a standard, every pairing demands custom code: a bespoke HTTP wrapper, a bespoke status format, a bespoke cancellation semantics, a bespoke error envelope. The combinatorial cost is what blocks the ecosystem.

I6 is the wire protocol that breaks that combinatorial cost. Google's Agent2Agent (A2A) protocol, announced in April 2025 and donated to the Linux Foundation in June 2025, became the focal point: a task-centric JSON-RPC-and-HTTP protocol with Server-Sent Events for streaming, defined task lifecycle states, structured results, and standardised cancellation. IBM/Red Hat's competing Agent Communication Protocol (ACP), launched March 2025 to power BeeAI, merged into A2A under the Linux Foundation in August/September 2025 — the protocol war ended in a single standard. ANP (Agent Network Protocol) remains as a decentralised, W3C DID-based alternative for open agent networks, but for enterprise cross-system delegation A2A is now the answer.

The pattern's defining contribution is to make delegation across a trust boundary a first-class protocol concern. It depends on I5 Agent Card for discovery — the orchestrator reads the executor's /.well-known/agent-card.json before it ever issues a task — and on V14 Trajectory Logging to keep the inter-system call auditable. It is distinct from O15 Agent Handoff (same-system, same-trust, shared memory, function call returning the next agent) and distinct from I3 MCP Server (tool-level discovery and invocation, not agent-level task delegation). The differences matter: tools answer questions; agents complete tasks. A2A treats the executor as an opaque agent with skills, not as a callable function with a schema.

The inter-agent boundary in A2A is not merely a system boundary — it is a context boundary. Each A2A executor runs in its own seq_len, paying its own O(n²) attention cost independently of the orchestrator (mechanism 6). Only the compact result crosses back. An orchestrator that delegates to five executors sequentially does not accumulate the cost of five tasks' worth of reasoning; it accumulates only five results. This is the same principle that makes subagent decomposition mechanically optimal in multi-agent architectures: bounded context per agent bounds inference cost per agent.

Variants

• A2A (Google $\to$ Linux Foundation). The unified standard as of late 2025. HTTP + JSON-RPC 2.0 transport; SSE for streaming; task-centric lifecycle (submitted $\to$ working $\to$ completed / failed / canceled); Agent Card at /.well-known/agent-card.json (older drafts used /.well-known/agent.json — treat that as legacy); broadest current adoption (150+ supporting organisations, 22,000+ GitHub stars on the core repo by mid-2026). The default choice.
• ACP (IBM/Red Hat $\to$ merged into A2A). Historical only. RESTful, message-based, both sync and async. Merged into A2A in Aug/Sep 2025; the BeeAI platform and its tooling now target A2A. Listed for completeness — new deployments should not adopt ACP as a separate protocol.
• ANP (Agent Network Protocol). Decentralised alternative. W3C DID-based identity, end-to-end encryption, no central registry, semantic-web-style (JSON-LD) capability descriptions. Targets open agent networks rather than enterprise cross-system pipelines; appropriate when no central authority should mediate discovery or trust.

A2A is the working assumption in the rest of this page. ANP is a structural alternative for the no-central-trust case; ACP is a historical footnote.

Applicability

Use when:

• The orchestrator and at least one delegated executor live in different systems, vendors, organisations, or trust domains.
• Multiple executors might be substitutable for the same skill — selection is by Agent Card capability, not by hardcoded URL.
• The task is long-running enough that streaming status updates are useful (cancellation, partial results, early decisions).
• The pipeline must scale beyond a single codebase or deployment.

Do not use when:

• The receiving agent lives in the same system / same trust boundary — use O15 Agent Handoff for an intra-system live-conversation transfer, or O6 Orchestrator-Workers for in-process worker delegation.
• The need is tool-level discovery and invocation, not agent-level task delegation — use I3 MCP Server.
• A single static URL and a bespoke contract are sufficient and the ecosystem will never grow — use a plain I1 Direct API call (and accept the lock-in).
• The trust model requires no central authority and cryptographic peer identity — use the ANP variant rather than A2A.
• Latency is the dominant constraint and the executor is in-process — A2A's network round-trip plus protocol overhead makes it the wrong tool.

Decision Criteria

I6 is right when delegation must cross a system, vendor, or trust boundary, and the orchestrator should be portable across executors rather than wired to a specific one.

1. Boundary test. Where does the executor live?

• Same process / codebase / trust domain $\to$ O15 Agent Handoff (intra-system).
• Different system, vendor, or organisation $\to$ I6.
• Same org but different deployment, with no auth boundary $\to$ either works; prefer O15 unless multi-vendor compatibility is on the roadmap.

2. Substitutability test. Can the orchestrator's choice of executor change at runtime (capability-based selection, marketplace fan-out, A/B between providers)?

• Yes $\to$ I6 mandatory; the Agent Card (I5) is what enables the choice.
• No, executor is fixed forever $\to$ I1 Direct API is simpler.

3. Task duration and observability. How long does the task run, and does the orchestrator need to see progress?

• < 1s, fire-and-forget $\to$ A2A still works but is overkill; consider I1.
• 1s–30min with progress updates $\to$ I6 with SSE streaming earns its keep.
• Multi-hour or human-in-the-loop $\to$ I6 with persistent task IDs and webhooks; pair with V1 Human-in-the-Loop for escalation.

4. Trust model. What is the executor allowed to see, and what is its output allowed to do?

• Trusted partner with a verified Agent Card $\to$ standard I6 with bearer auth.
• Adversarial or unknown $\to$ I6 must be wrapped by V6 Prompt Injection Shield (executor output is externally-sourced content) and V8 Tool Sandboxing if the result is used to take further action. Treat A2A responses with the same suspicion as web content.
• No central authority acceptable $\to$ use the ANP variant.

5. Operational discipline. Are the failure-mode controls in place?

• Mandatory: I5 Agent Card verification before first call (cache with TTL), timeout + cancellation (executor may never respond), V9 Bounded Execution (retry / reroute cap), V14 Trajectory Logging (every A2A call carries executor agent ID and version in the trace).
• If any of these is missing, I6 will silently degrade — orchestrator will hang on a frozen executor, retry into a black hole, or accept a result it cannot audit.

Quick test — I6 is the right pattern when:

• the executor is across a system, vendor, or org boundary, and
• the orchestrator wants the option to swap executors based on capability (Agent Card), and
• the task duration or progress visibility justifies a protocol over a plain HTTP call, and
• the operational controls (I5 verification, timeout, V14 logging, V6 on returned content) are in place.

If the executor is intra-system, use O15 Agent Handoff. If the need is tool-level not agent-level, use I3 MCP Server. If the executor is fixed and the contract is bespoke, I1 Direct API is simpler. If the trust model rejects central authorities, the ANP variant fits better than A2A.

Structure

  Orchestrator
       │
       │ 1. Read Agent Card (I5)
       ▼
  GET https://executor.example.com/.well-known/agent-card.json
       │  → skills, auth schemes, protocol version
       │
       │ 2. Verify skill compatibility (cache card with TTL)
       │
       │ 3. Submit task
       ▼
  POST /tasks  { id, skill, input, callback? }
       │
       │ 4. Stream status (SSE) or poll
       ▼
  GET /tasks/{id}/stream
       │   → working (progress 0.2)
       │   → working (progress 0.6, partial_result)
       │   → completed { result }     ─┐
       │   → failed    { error }       │
       │   → canceled                  │
       │                               ▼
       │                          Orchestrator
       │                          ├─ completed → use result (guard via V6)
       │                          ├─ failed    → retry / reroute / V1 escalate
       │                          └─ canceled  → log; reroute or abort
       │
       │ 5. Log every event in V14 trace
       ▼
  Trace store: { call_id, executor_id, executor_version, skill, status, latency }

Participants

Collaborations

The Orchestrator begins by reading the prospective executor's Agent Card (I5) — either from cache, with TTL, or freshly from /.well-known/agent-card.json. It verifies that the executor declares the required skill and that the protocol versions are compatible. It then submits a task to the executor's /tasks endpoint with a stable id, the skill name, and structured input. The Executor accepts the task and begins work, emitting status events over Server-Sent Events: working with optional progress and partial results, then a terminal completed, failed, or canceled. The Orchestrator's Result Handler consumes the terminal state, runs the returned content through V6 Prompt Injection Shield treatment, and decides the next action — use the result, retry with the same executor, reroute to an alternative executor discovered via another Agent Card, or escalate to V1 Human-in-the-Loop. V9 Bounded Execution caps the retry / reroute loop. V14 Trajectory Logging records every protocol event with the executor's agent id and version for full audit reconstruction.

Consequences

Benefits

• Cross-vendor and cross-organisation agent collaboration becomes a standard protocol concern rather than bespoke integration per pairing.
• Agent Card-based discovery enables runtime executor substitution — A/B between providers, capability-based routing, marketplace fan-out.
• Streaming status updates allow early decisions: cancel a too-slow executor, parallel-fallback before failure, surface progress to a user.
• Standardised cancellation semantics — orchestrators can recover from a hung executor without protocol-specific kludges.
• Bounded inference cost per agent (mechanism 6): the executor's reasoning stays in its own context; the orchestrator pays only for integrating the result.

Costs

• Network latency and protocol overhead vs. in-process delegation; not a fit for sub-100ms paths.
• Authentication complexity — bearer tokens, mTLS, OAuth schemes per executor.
• Schema and version compatibility maintenance: Agent Cards drift from reality unless generated live.
• Trust surface expands — every executor is a new external dependency with its own failure profile.

Risks and failure modes

• Unverified delegation. Orchestrator delegates to an agent whose Agent Card it never checked (or whose card it cached past TTL); skill mismatch or auth failure surfaces at task time.
• Hung executor. Executor accepts a task and never emits a terminal event; without orchestrator-side timeout the delegating session blocks forever.
• Cascading delegation. Executor itself delegates to another A2A agent that delegates to another — without trace-wide V9 Bounded Execution the call chain explodes.
• Returned-content injection. Result from the executor is treated as trusted; embedded prompt-injection content reaches the orchestrator's main loop. (Classic V3 Lethal Trifecta scenario.)
• Card spoofing. A malicious endpoint serves a plausible Agent Card claiming skills it does not have, or claims credentials it should not have; orchestrator must verify card authenticity (HTTPS cert, signed cards, or registry-of-trust).
• Silent capability drift. Executor's actual behaviour diverges from its declared card — orchestrator continues calling but quality degrades undetectably.

Implementation Notes

• Read the card every time, but cache it with a short TTL (minutes, not days). Cards are meant to be live; the cache is purely a latency optimisation, not a contract snapshot.
• Pin the protocol version. A2A is versioned (1.0 as of 2026, with 0.3 compatibility mode in the official SDKs). Mismatched versions silently misbehave; check the card's declared version before first call.
• Use the official SDKs over hand-rolled clients. a2a-python, @a2a-js/sdk, a2a-java, and the Go and .NET equivalents handle the lifecycle and streaming correctly; rolling your own JSON-RPC over SSE is a foot-gun.
• Timeout everything. Every task submission has a hard wall-clock budget; every status stream has an idle-timeout (no event for N seconds $\to$ cancel and reroute).
• Treat returned results as externally-sourced content. Pass them through V6 Prompt Injection Shield before they re-enter the orchestrator's reasoning. The executor is a remote system; its output has the same trust profile as web content.
• Log executor agent id, version, and Agent Card hash in V14 traces. Without these, "what did the third-party agent do on this date?" becomes unanswerable.
• Cap delegation depth. An A2A executor that itself uses A2A can produce unbounded chains. V9 Bounded Execution must apply globally, not per-hop.
• Compact the orchestrator's accumulated delegation results before each new reasoning step (mechanism 11). Verbose executor outputs, status events, and partial results that are no longer needed for the current decision should be compacted to a summary before being included in the next Orchestrator call. The orchestrator's seq_len grows with every round of delegation; without compaction, the O(n²) attention cost compounds across the pipeline.
• The executor's KV cache does not persist between task invocations (mechanisms 3 and 10): any context the executor needs from a prior task must be explicitly included in the new task input, not assumed to be "remembered" from the previous call.
• Use I5's authentication declaration to choose credentials. The card declares acceptable schemes — Bearer, OAuth, mTLS. Pick from those, do not assume.
• For executors you operate, generate the Agent Card from live config — never hand-write a static /.well-known/agent-card.json that will silently drift.

Implementation Sketch

LLM = configured session (model + setup + per-call prompt); code = wiring.

Composition: I6 chains an Orchestrator agent session with an external Executor agent (opaque, behind the protocol), mediated by deterministic protocol wiring. Composes with I5 Agent Card (mandatory prerequisite for discovery), V14 Trajectory Logging (audit), V9 Bounded Execution (retry / depth cap), V6 Prompt Injection Shield (returned-content guard), and V1 Human-in-the-Loop (failure escalation). Often invoked under O6 Orchestrator-Workers when the worker lives across a boundary, or wrapped by O15 Agent Handoff when a live conversation must cross systems.

The chain:

Skeleton:

delegate(task_spec):
    card = get_agent_card(task_spec.executor_url)        # code — I5, cached
    verify_skill_and_version(card, task_spec.skill)      # code — assert compatible
    task = build_task(task_spec)                         # code — typed object
    
    for round in range(max_rounds):                      # code — V9-bounded
        post(f"{card.url}/tasks", task)                  # code — A2A submission
        for event in stream_status(task.id):             # code — SSE consume
            log_v14(event, card.id, card.version)        # code — V14
            if event.terminal:
                if event.status == "completed":
                    result = v6_guard(event.result)      # code — V6 on returned content
                    return Orchestrator(result)          # LLM — integrate into reasoning
                if event.status == "failed":
                    if rerouteable(event.error):
                        card = find_alternative(task_spec.skill)  # code — Agent Card index
                        break                            # retry with new executor
                    if recoverable(event.error):
                        break                            # retry same executor
                    return human_review(event)           # code — V1 escalate
                if event.status == "canceled":
                    break
            elif idle_timeout(event):                    # code — no-event timeout
                cancel_task(task.id, card.url)
                break
    return human_review(task)                            # code — V1, V9 exhausted

The LLM sessions:

The Executor is intentionally opaque to the Orchestrator. That opacity is the pattern's point: the Orchestrator does not need to know the executor's model, framework, or implementation, only its declared skills and protocol contract. Two A2A executors are interchangeable from the Orchestrator's perspective if their Agent Cards declare compatible skills.

Specialist-model note. No specialist model is required for the I6 wiring itself — A2A is a protocol concern, not a model concern. Two structural dependencies do matter: the A2A SDK for the orchestrator's language (a build dependency, not a prompt) and the Agent Card endpoint on every executor (a deployment artifact). The Orchestrator's delegation decision can be a capable generalist; the rule "delegate when skill matches and boundary is cross-system" is a prompt rule, not a fine-tune. The Executor is opaque — its model choice is the executor's concern, declared abstractly in the Agent Card.

Open-Source Implementations

• A2A Protocol (core) — github.com/a2aproject/A2A — the official Agent2Agent protocol specification under the Linux Foundation; 22,000+ stars by mid-2026, 150+ supporting organisations.
• A2A Python SDK — github.com/a2aproject/a2a-python — official Python SDK; implements A2A spec 1.0 with 0.3 compatibility mode; async-first; pip install a2a-sdk.
• A2A JavaScript / TypeScript SDK — github.com/a2aproject/a2a-js — official JS SDK; JSON-RPC and REST transports; Express handlers for serving Agent Cards and task endpoints; npm install @a2a-js/sdk.
• A2A Java SDK — github.com/a2aproject/a2a-java — official Java SDK.
• A2A samples — github.com/a2aproject/a2a-samples — official multi-language samples and reference orchestrations; the closest match to the structure shown above.
• awesome-a2a — github.com/ai-boost/awesome-a2a — community-curated index of A2A agents, tools, servers, and clients.
• BeeAI Framework (ACP-merged-into-A2A) — github.com/i-am-bee/acp — historical home of IBM/Red Hat ACP, now operating under the unified A2A umbrella; useful as a worked example of the merger's reference implementations.
• Agent Network Protocol (ANP variant) — github.com/agent-network-protocol/AgentNetworkProtocol — decentralised W3C-DID-based alternative; appropriate for open agent networks where no central authority should mediate trust.

Known Uses

• Google Cloud and Vertex AI — production A2A deployments connecting Google-built agents with partner agents under the Linux Foundation's Agentic AI Foundation (AAIF) — the LF directed fund that also anchors MCP, AGENTS.md, and Goose; A2A is a sibling project under the same umbrella.
• AWS, Cisco, IBM, Microsoft, Salesforce, SAP, ServiceNow — all on the A2A Technical Steering Committee following the Linux Foundation transfer; multiple enterprise production deployments referenced in the Linux Foundation's 2026 first-anniversary report ("150+ organisations, enterprise production use in first year").
• BeeAI Platform (IBM) — the agent marketplace originally built on ACP, now operating against the unified A2A protocol post-merger.
• Agent marketplaces and registries — emerging pattern of capability-based agent selection mediated by I5 Agent Cards and I6 delegation, replacing hardcoded executor URLs.

Related Patterns

• Required by I5 Agent Card — I6 cannot operate without I5; the Agent Card is the discovery and verification mechanism for every delegated call.
• Distinct from O15 Agent Handoff — O15 is intra-system control transfer (function call returning an agent, shared memory, same trust boundary); I6 is the inter-system wire protocol. When a handoff crosses systems, O15 wraps I6 as transport.
• Distinct from I3 MCP Server — I3 is tool-level discovery and invocation (what operations can this server perform?); I6 is agent-level task delegation (what tasks can this agent complete?). A single deployment commonly serves both: an Agent Card describing high-level skills (I5/I6) and an MCP server describing low-level tools (I3).
• Pairs with O6 Orchestrator-Workers — when an Orchestrator-Workers deployment must reach workers across a system boundary, I6 is the transport; the O6 pattern remains unchanged.
• Pairs with V14 Trajectory Logging — every A2A call must appear in the orchestrator's trace, tagged with executor agent id and version, or cross-system incidents become unreconstructable.
• Pairs with V9 Bounded Execution — retry / reroute / delegation-depth caps; without them, a hung or recursive executor cascades the orchestrator into hang or token blowout.
• Pairs with V6 Prompt Injection Shield — returned executor content is externally-sourced; treat with the same suspicion as web content.
• Pairs with V1 Human-in-the-Loop — delegation failures (especially in marketplace or unknown-executor contexts) should escalate to human review, not silently retry.
• Required by V12 Stateless Reducer (for the orchestrator) — cross-system delegation means state must serialise across the boundary; without V12 the orchestrator cannot package what it knows for the executor.
• Note on fundamentality — I6 is the agent-level wire protocol; it stands as a pattern distinct from I3 (different granularity: agent vs tool), O15 (different scope: inter-system vs intra-system), and O6 (different layer: transport vs orchestration). The ACP and A2A merger collapsed two competing protocols into one variant; ANP remains a structural alternative for the decentralised-trust case.

Sources

• Google (April 2025) — "Announcing the Agent2Agent Protocol (A2A)", Google Developers Blog.
• Linux Foundation (June 2025) — "Linux Foundation Launches the Agent2Agent Protocol Project."
• Linux Foundation (2026) — "A2A Protocol Surpasses 150 Organizations, Lands in Major Cloud Platforms, and Sees Enterprise Production Use in First Year."
• IBM Research (March 2025) — "Agent Communication Protocol (ACP)" introduction; subsequent August 2025 announcement of the ACP-A2A merger under the Linux Foundation.
• LF AI & Data (August 2025) — "ACP Joins Forces with A2A Under the Linux Foundation's LF AI & Data."
• A2A Protocol Specification (a2aproject.github.io/A2A) — v0.3 and v1.0 specification documents.
• ANP — W3C-CG "AI Agent Protocol" draft, decentralised alternative whitepaper.
• IETF RFC 8615 — well-known URI standard (foundation for /.well-known/agent-card.json; older A2A drafts used /.well-known/agent.json).
• Composio AI Agent Report 2025 — adoption data for A2A, MCP, and ACP across the agent ecosystem.