Build an A2A Agent Federation Workflow for Cross-Org Task Delegation in 2026

By Deepak Bagada, CEO at SaaSNext & Principal AI Architect.

Introduction

By mid-2026, the Agent2Agent (A2A) protocol moved from Google announcement to open infrastructure. After Google donated A2A to the Linux Foundation in June 2025 with more than 50 launch partners, the project crossed 150 supporting organizations and reached production deployments across industries, including ServiceNow's Now Assist (Zurich Patch 4), Salesforce Agentforce, Box agents, and SAP Joule. Docker alone shipped native A2A support for docker-agent so that any containerized agent can be exposed to the wider agent ecosystem.

The mental model that made this stick is simple: MCP below, A2A above. MCP is how a single agent talks to tools and data. A2A is how agents talk to each other across teams, vendors, and legal boundaries. If MCP is the USB-C of AI tooling, A2A is the SMTP of agent email — it lets one org's researcher agent hand a task to another org's booking agent and get the result back in a structured envelope.

This workflow builds a production A2A federation for a realistic cross-org scenario — a procurement team who needs to qualify suppliers who each expose their own agents. You will wire agent discovery, task delegation, streaming, artifact sharing, and a tamper-evident audit trail that keeps security teams comfortable with letting agents act outside the trust boundary.

For the single-agent tool layer under this system, our AI workflows library covers the MCP-backed pipelines; the MCP directory catalogs the servers you can expose through the federation.

Architecture Overview

graph TD
  subgraph OrgA[Organization A - Buyer]
    A[Orchestrator Agent] --> B[A2A Client Hub]
    B -- WebSocket --- D[Agent Discovery Registry]
  end
  subgraph OrgB[Supplier 1]
    D2[A2A Server] --> E[Catalog Agent]
    E --> F[Inventory Database via MCP]
  end
  subgraph OrgC[Supplier 2]
    D3[A2A Server] --> G[Lead Agent]
    G --> H[CRM via MCP]
  end
  B -- agent.json / task delegation --> D2
  B -- agent.json / task delegation --> D3
  A --> I[Audit / SIEM Sink]
  I --> J[Compliance Ledger]

The design principle from A2A's specification: every agent advertises an Agent Card (agent.json) describing its name, skills, endpoint, and security policies. The buyer's hub reads those cards, then delegates tasks that return structured Task objects with status and artifact URLs. Because transport is WebSocket with an HTTP fallback for firewalled networks, federation works across NATs and DMZs without opening inbound ports.

Part 1 — The A2A Server (Supplier Side)

We expose one agent per A2A standard as a FastAPI service. It advertises an Agent Card, accepts task POSTs, and streams updates.

.env

A2A_PORT=8347
A2A_AGENT_URL=https://agents.supplier1.example.com/a2a
AGENT_CARD_PATH=./agent.json
REDIS_URL=redis://localhost:6379
LLM_API_KEY=sk-supplier-xxxx
AUTH_TOKEN=mtls-scoped-token

agent.json

{
  "name": "CatalogAgent",
  "description": "Queries catalog pricing and stock across regions.",
  "url": "https://agents.supplier1.example.com/a2a",
  "skills": ["catalog.query", "catalog.pricing.get"],
  "security": {
    "auth": "mTLS + OAuth2 client-credentials",
    "data_residency": "eu-central-1",
    "retention_days": 90
  },
  "version": "1.0.0"
}

server.py

from fastapi import FastAPI, Header, HTTPException
from a2a import A2AMessage, Task, TaskState
from pydantic import BaseModel

app = FastAPI(title="Supplier A2A Server")

class TaskRequest(BaseModel):
    messageId: str
    task: Task

@app.post("/a2a/tasks")
async def start_task(req: TaskRequest, authorization: str = Header(None)):
    if authorization != f"Bearer {AUTH_TOKEN}":
        raise HTTPException(401, "invalid federation token")
    # A A2A task is an object with id + input; never raw prompt text only.
    task = req.task
    return await dispatch_to_catalog_agent(task)

@app.get("/a2a/agent")
async def agent_card():
    return json.load(open("agent.json"))

Part 2 — The A2A Client Hub (Buyer Side)

The hub is where federation gets real. It maintains a registry of known agent cards, validates them, delegates tasks, and streams results back to the orchestrator.

client.py

import httpx, json
from urllib.parse import urljoin

REGISTRY = {
    "supplier-1": "https://agents.supplier1.example.com/a2a",
    "supplier-2": "https://agents.supplier2.example.com/a2a",
}

async def discover_and_validate(url: str):
    async with httpx.AsyncClient() as c:
        card = (await c.get(urljoin(url, "agent"))).json()
    required = {"name", "skills", "url", "security"}
    missing = required - card.keys()
    if missing:
        raise ValueError(f"invalid agent card, missing {missing}")
    return card

async def delegate(card: dict, task_spec: dict) -> dict:
    payload = {
        "messageId": new_uuid(),
        "task": {"id": new_uuid(), "input": task_spec},
    }
    async with httpx.AsyncClient() as c:
        resp = await c.post(card["url"] + "/tasks", json=payload)
        resp.raise_for_status()
        return resp.json()

Retry rules: retry a delegated task with exponential backoff on 5xx (base 1s, factor 2, max 5 attempts) and only accept 503 + Retry-After as a scheduler hint. Never retry a 400 — the task payload is invalid and retrying burns remote capacity.

Part 3 — Orchestrator Integration

The orchestrator (LangGraph) treats each remote agent as a tool node that returns an A2A Task envelope rather than free text. Streaming updates arrive on the WebSocket subscription channel and are written to shared state.

graph.py

from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated, List
import operator

class FederationState(TypedDict):
    rfp: str
    candidates: list
    quotes: Annotated[List[dict], operator.add]
    audit_log: list

def build_graph(client, registry_names):
    g = StateGraph(FederationState)

    g.add_node("discovery", lambda s: discover_all(client, registry_names))
    g.add_node("delegate", lambda s: delegate_all(client, s["candidates"]))
    g.add_node("score", lambda s: score_quotes(s))

    g.set_entry_point("discovery")
    g.add_edge("discovery", "delegate")
    g.add_edge("delegate", "score")
    g.add_edge("score", END)

    return g.compile(interrupt_before=["delegate"])

Use interrupt_before=["delegate"] to add a human approval gate before any cross-org task is dispatched. That one line is the difference between a demo and a compliance-approved deployment, because a human can review the exact task envelope and destination before money or data moves.

Security & Audit

Federation's biggest unresolved question is security, so we treat every cross-org message as instrumented traffic:

1. Verified agent cards — re-pull and re-validate agent.json on a 24h TTL; reject cards missing a security.auth stanza.
2. mTLS + scoped OAuth — never rely on bare bearer tokens across org boundaries.
3. Envelope PII checks — reject delegation payloads containing card numbers or health data unless the remote card declares DP-compliant residency.
4. Tamper-evident ledger — every messageId, task state transition, and artifact hash is appended to a WORM audit log shipped to the SIEM.

Production Checklist

1. Publish one Agent Card per agent, and keep skills narrow — marketing is a smell, not a skill.
2. Put the A2A hub behind the same identity fabric as your internal agents.
3. Add budget caps per remote agent (max N tasks/hour, max cost/day).
4. Log A2A messageId ↔ internal trace_id mapping for replay debugging.
5. Watch the 90-day production-retention signal: teams keep A2A in production after one real incident, not after the demo week.

Delegation policy: who may call whom, and how much

A federation without policy is a botnet of convenience. Add three rules before any production traffic: capability match (only delegate tasks that fall inside a remote card's advertised skills), budget caps per remote (a hard limit on tasks/hour and cost/day per remote agent, so a runaway loop burns neither your quota nor your vendor bill), and jurisdiction routing (payloads containing regulated data only go to remotes that declare compatible residency in their card). These belong in the hub as policy objects, versioned alongside the agent cards, not in prompts. That is the same policy-as-code discipline we apply to every production gateway in our AI workflows library.

A worked walkthrough: the RFP response federation

Concretely, the buyer's orchestrator qualifies three suppliers for an RFP response. Discovery resolves three cards. The orchestrator builds three task envelopes — supplier billing policy, capacity, compliance posture — and interrupts for the human to approve the batch. Delegated tasks stream status updates over the WebSocket channel (working, input-required, completed). The input-required state matters: a supplier agent that needs a missing field triggers a callback back to the buyer hub, which routes the question to the correct human, rather than burning retries. On completion, artifacts (structured answers) are fetched from each remote's artifact URLs and scored. The whole exchange lands in the WORM ledger: message ids, task transitions, artifact hashes, and the human approvals. That walkthrough is the reference implementation for every cross-org agent deployment we catalog — you can watch it operate live in the examples within our latest AI news coverage of the ServiceNow and Salesforce A2A integrations.

Starting narrow in production

Adopting A2A does not require your whole estate. A defensible first deployment is a single federation pair with one remote partner: two agent cards, one task type, no autonomy on admin actions. Run that pair for a month, measure delegation success rate, average task latency, and audit drift — then widen to the three-supplier RFP pattern this guide walks through. The protocol earns its keep at real boundaries, and real boundaries need hardening one relationship at a time. That staged expansion is the same controlled path we prescribe across our AI workflows library, and it keeps the 150-organization ecosystem behind A2A honest: adoption is measured in production retention, not logo counts.

Frequently Asked Questions

Q: Is A2A a replacement for MCP in 2026?

A: No — they are complementary layers. MCP connects an agent to tools and data sources; A2A connects agents to each other. The convention adopted by the ecosystem is MCP below for tool access and A2A above for agent-to-agent delegation, and mature stacks like AgentMaster integrate both protocols.

Q: What are the minimum A2A primitives to implement?

A: An Agent Card (agent.json) for discovery and advertising, and a Task object for delegation. Tasks carry an id, name, input, state (submitted, working, input-required, completed, failed), and artifacts with URLs that the client pulls.

Q: How does streaming work over A2A?

A: The server opens a WebSocket subscription channel per message; state changes are pushed as TaskStatusUpdate events. For NAT-restricted partners the protocol falls back to polling GET /tasks/{id}.

Q: Why did 2026 adoption skepticism fade?

A: Linux Foundation governance, 150+ supporting organizations, production deployments at ServiceNow, Salesforce, SAP, and Box, and a formal spec made A2A a multi-vendor standard rather than a Google strategy bet. The honest caveat: production retention, not logo support, is the real adoption signal.