A2A Multi-Agent Architecture: How Real Agent Handoffs Actually Work

Jatin Gupta
Jan 01, 1970
Agentic AI
8

Agentic AI A2A Protocol Multi-Agent

A2A Multi-Agent Architecture: How Real Agent Handoffs Actually Work

Building a multi-agent AI system is not simply deploying multiple agents. The real challenge is how agents discover each other, delegate work, hand off context, execute tasks, and return results through a clean delegation stack — this is the architecture that makes that possible.

August 2026

14 min read

Applied AI Engineering

Lifecycle steps — Orchestrate → Discover → Select → Delegate → Handoff → Execute → Return → Aggregate → Respond

Routing factors gate every delegation — capability, policy, trust, tenant, cost, latency, availability

Handoff context fields carry the full execution state between agents — no side channels

The A2A Pattern

Three Layers of the A2A Multi-Agent Architecture

The A2A (Agent-to-Agent) protocol is the emerging standard for how independently-deployed agents discover each other, delegate work, and return results. It replaces the brittle "hub calls every agent directly" model with a symmetric ecosystem in which any agent can be both a client (delegating to specialists) and a server (receiving delegations). This is what makes multi-agent systems actually scale beyond a single orchestrator.

Orchestration & Discovery

The orchestrator never hardcodes which agent handles what. It queries the Agent Registry, matches capabilities, and evaluates policy, trust, tenant, cost, latency, and availability before selecting the next agent.

Agent Registry Agent Cards Capability Match

A2A Protocol

Every agent runs as an independent A2A Agent Server with its own Agent Card and Agent Harness. When it determines a specialist is required, it initiates an A2A handoff — carrying full context, completed work, and artifacts forward.

Handoff Context Artifacts Delegation Chain

Result Propagation

Results do not jump directly back to the orchestrator. They propagate back through the delegation chain — Procurement → Finance → Security → Orchestrator — creating a clean delegation stack with full provenance at each hop.

Inverse Path Attestation Aggregation

Architecture Diagram

The Full A2A Flow at a Glance

The 9-step lifecycle, the delegation stack, the handoff context payload, result propagation, and the multi-factor discovery routing — all in one view.

Orchestration Flow

From User Request to Agent Selection

The orchestrator is not a hub that knows every agent. It is a router that discovers, evaluates, and selects — dynamically, at runtime, based on live capability and policy data.

The selection function evaluates: does this agent have the capability? Is it within policy and authorized for this tenant? Is it trusted by the requesting agent? Among the candidates that pass — what is the cost, latency, and current availability? Only the candidate that passes all gates gets delegated to.

✓ User Request → API Gateway: Auth, rate limiting, tenant resolution, request normalisation

✓ API Gateway → Orchestrator: Intent classification, task decomposition, plan formation

✓ Orchestrator → Agent Registry: Discovery query with task context and tenant scope

✓ Registry → Capability Matching: Agent Cards scored against task requirements

✓ Policy · Trust · Tenant · Cost · Latency: Multi-factor gate — candidate must pass all before selection

✓ A2A Task Delegation: Full handoff context attached — the agent gets everything it needs

✓ Result Propagates Back: Through the delegation chain; orchestrator aggregates and responds

Handoff Context

What an A2A Handoff Actually Carries

A handoff is not a task description. It is a complete execution context: what has been done, by whom, with what authorization, and exactly what is required next. The receiving agent needs no side channel.

// A2A handoff: Finance Agent → Procurement Agent { "contextId": "ctx_8f7a2b9e-3c12-4d90", "taskId": "task_3d1f8c4a", "originalGoal": "Process vendor invoice PO-2024-8847", "relevantContext": { vendor: "Acme Corp", amount: 47500, dept: "Eng" }, "completedWork": [ { agent: "SecurityAgent", action: "access_verified" }, { agent: "FinanceAgent", action: "budget_approved" } ], "artifacts": [ "vendor_validation.json", "budget_approval.json" ], "requiredNextAction": "issue_purchase_order", "userTenantContext": { userId: "u_4592", tenantId: "t_enterprise_emea" }, "authorizationContext": { delegationChain: [ "orchestrator", "security", "finance" ], maxScope: [ "procurement:write" ] } }

The authorization context is critical. It carries the delegation chain (orchestrator → security → finance) and the maximum scope the next agent is permitted (procurement:write). The receiving agent cannot escalate beyond what it was delegated — scope propagation is explicit, bounded, and auditable at every hop.

Discovery & Routing

The Nine Factors That Select the Next Agent

The Agent Registry and Agent Cards enable dynamic, multi-factor routing. The next agent is not hardcoded — the system determines which agent is capable, trusted, authorized, and available at the moment of delegation.

Routing Factor	Evaluated As	Purpose
Agent Registry	registry.query(task, tenant)	Central catalog of all registered A2A Agent Servers with live metadata and availability signals
Agent Cards	card.capabilities[]	Structured capability declarations — what tasks the agent can perform, what tools it exposes, what inputs it accepts
Capability Matching	card.supports(taskType)	The primary filter — does this agent actually have the skill to handle this next step?
Policy	policy.permits(agent, task, scope)	Is this delegation permitted? Does the task fall within the agent's allowed action envelope?
Trust	trust.score(caller, callee)	Is the requesting agent authorised to delegate to this agent? Prevents privilege escalation across trust domains
Tenant	agent.tenantScope.includes(tenantId)	Does this agent serve the current tenant? Prevents cross-tenant data and processing leakage
Cost	agent.costPerTask	Among candidates that pass all gates, rank by cost efficiency — enables least-cost routing for commodity tasks
Latency	agent.p95Latency	Does this agent meet the latency SLA for this workflow step? Avoids blocking the delegation chain
Availability	agent.status == "healthy"	Live health signal — only route to agents that are currently responsive and not at capacity

Result Propagation

Why Results Travel Back Through the Chain

The clean delegation stack model — where results propagate back through every hop — is not an implementation detail. It is the source of auditability, composability, and trust across the ecosystem.

✓ Each hop validates the result from below and adds its own attestation and artifact

✓ By the time the orchestrator receives it, the provenance is complete and signed — a chain of custody

✓ Exactly what enterprise audit and compliance workflows require

Security

Every hop authenticated

Every A2A delegation is an authenticated call between two independently identified agent servers. The authorizationContext carries the delegation chain explicitly, preventing privilege escalation structurally, not just by policy.

Observability

contextId threading

A single contextId threads the entire multi-hop workflow into one observable unit. Every agent logs its input, decision, tool calls, and output against it — full trace from user intent through every delegation.

Interoperability

Additive capability

Because every agent exposes a standard A2A interface and publishes an Agent Card, new specialists — from any team, vendor, or framework — join and are discoverable without changing existing agent code.

Takeaway

An Ecosystem, Not a Workflow

The A2A protocol is the emerging foundation for enterprise Agentic AI — the missing infrastructure that makes handoffs secure, observable, and interoperable. The shift is from a centralised multi-agent workflow to a true agent ecosystem, where the next agent is discovered, not hardcoded.

Blog