Pattern 15: Inter-Agent Communication (A2A) — Getting Strangers’ Agents to Work Together

The interview scenario

This pattern shows up when the problem crosses a team or company boundary:

• “Our procurement agent needs to negotiate with our suppliers’ agents — different companies, different tech stacks. How do they talk?”
• “Five teams here each built their own agent — one in LangGraph, one in CrewAI, one on a homegrown stack. Design how they collaborate on a single workflow without rewriting them.”
• “Design an ecosystem where third-party developers can publish agents that our orchestrator can discover and delegate work to.”

The tell is heterogeneity: multiple agents, built by different people on different frameworks, that must coordinate. If everything lived in one codebase under one team, you’d use in-process orchestration and skip this pattern entirely — and saying that out loud earns points.

What this pattern is, in plain words

One agent, however capable, hits a ceiling on multi-faceted problems. The natural fix is specialists: a research agent, an analysis agent, a report-writing agent, each owned by whoever knows that domain best. But the moment those specialists are built by different teams — or different companies — on different frameworks, you hit the babel problem: LangGraph agents, CrewAI agents, and Google ADK agents have no native way to talk to each other. Every pairing needs a custom, brittle integration, and the integration count grows with every new agent.

Inter-agent communication protocols solve this the way the web solved it for documents: with a shared, open standard. The concrete one to name is A2A — Agent2Agent — an open protocol originated by Google and backed by a broad industry group (Microsoft, Salesforce, SAP, ServiceNow, LangChain, and others), which matters because a communication standard is only as valuable as the crowd that speaks it. A2A runs over plain HTTP with JSON payloads — deliberately boring transport, because boring transport is what lets everyone join.

The analogy I’d lead with: A2A does for agents what standardized business communication does for companies. When you hire a contractor, you don’t need to know what software runs their back office. You find their public listing, read what services they offer, send a work order, and get status updates and deliverables back. A2A formalizes exactly that loop for software agents — discover, delegate, track, receive — while each agent’s internals stay a black box. The protocol’s word for this is opaque: the client agent sees the remote agent’s advertised capabilities and its results, never its implementation, its prompts, or its proprietary logic. Opacity is a feature — it’s what makes cross-company collaboration palatable, because nobody has to expose their secret sauce to cooperate.

Three roles to keep straight: the user who wants something done; the client agent acting on the user’s behalf, which discovers and delegates; and the remote agent (the A2A server), which exposes an HTTP endpoint, accepts tasks, and does the work.

And here’s the sentence you must be able to say cleanly, because it’s asked in nearly every interview that touches this space: MCP connects an agent to its tools and data, while A2A connects an agent to other agents — MCP is how an agent uses a hammer; A2A is how it hires another carpenter. The deeper distinction: a tool is called and mechanically returns; an agent is delegated to — it reasons, may work for hours, may come back with clarifying questions. The two protocols are complements, not rivals, and a real system uses both: each agent reaches its own tools via MCP and its peers via A2A.

How the design actually works

Four building blocks, in the order a real interaction uses them.

The agent card — a business card describing what an agent can do. Every A2A agent publishes a small JSON file listing its name, description, endpoint URL, version, its skills — named capabilities like “check_availability,” each with a description and example prompts, so a caller (human or LLM) can figure out which agent fits a job — plus the interaction modes it supports (streaming? push notifications?), what input and output formats it accepts, and how you must authenticate. It’s simultaneously a business card, a menu, and the fine print on the door.

Discovery — how you find the card. Three strategies, matched to context. Well-known URI: the card lives at a standard path on the agent’s domain (/.well- known/agent.json), like a shop hanging its sign where everyone knows to look — good for public agents. Curated registry: a searchable internal catalog where approved agents are published — the right answer for enterprises, because it doubles as a governance chokepoint (only vetted agents get listed). Direct configuration: you just hardcode the card for partners you already know. In an enterprise design, say “registry” and mention that the card endpoint itself should be access-controlled, since even non-secret capability metadata is reconnaissance material for an attacker.

Tasks — delegation with a paper trail. The unit of work is the task: the client sends a message (which can carry text, files, or structured data in typed parts), the server assigns the task an ID and moves it through an explicit lifecycle — submitted, working, completed, or failed, plus a state worth calling out: input-required, meaning the remote agent is pausing to ask the client a clarifying question mid-task, which turns delegation into a genuine conversation rather than fire-and-forget. Outputs come back as artifacts — the deliverables — and a context ID threads related tasks together so multi-step collaborations keep shared state. Notice the asynchrony is structural: agent work can take seconds or days, so the protocol is built around long-running jobs, not instant function calls.

Interaction styles — four ways to wait. Synchronous request/response for quick lookups: send, block, get the answer. Polling for longer jobs: the server immediately returns “working” plus a task ID; the client checks back periodically — like a package- tracking number. Streaming via server-sent events, a persistent one-way HTTP channel the server pushes incremental updates down — right for progress bars and partial results. And webhooks — push notifications — for very long jobs: the client registers a callback URL and the server calls it when the task finishes, so nobody holds a connection or polls for hours. Which of these an agent supports is declared on its card, and the protocol handles multimodal payloads — text, files, structured JSON, even audio and video.

Trust and security — the part that separates senior answers. The moment agents from different organizations delegate work, you’re doing cross-company API security with an agentic twist. The baseline: encrypted channels via TLS, or mutual TLS where both sides present certificates — both parties show ID, not just the server. Authentication requirements are declared on the agent card and use standard credentials — OAuth tokens or API keys in HTTP headers, never embedded in URLs or message bodies where they leak into logs. Authorization should be scoped: a client authorized for the “get_forecast” skill isn’t thereby authorized for everything else the agent can do. And comprehensive audit logs record who delegated what to whom, when, with what outcome — essential when a workflow spanning three companies goes wrong at 2am and everyone’s lawyers want the timeline. The agentic twist worth naming: the remote agent is a black box that reasons, so you should validate its outputs before acting on them — treat a peer agent with the same “trust but verify” posture as any external service, plus a bit more skepticism because its behavior is non-deterministic.

The complete interview answer, spoken

Spoken end-to-end for: “Five teams each have their own agent on different frameworks — design how they collaborate on one workflow.”

“Clarifying questions first. What’s the workflow — a fixed pipeline where agent A always feeds agent B, or dynamic, where an orchestrator decides at runtime who does what? Are all five agents inside our network, or are any external — vendors, partners? And what are the latency expectations — interactive, or batch jobs that can take hours?”

(Interviewer: dynamic workflows, all internal today but a vendor agent is joining next quarter, and tasks range from seconds to about an hour.)

“That shapes everything. Dynamic delegation means agents must be discoverable with machine-readable capability descriptions, not hardwired to each other. A vendor joining rules out any single-framework answer — we can’t ask a vendor to rewrite their CrewAI agent in our stack, and honestly we can’t even ask our own five teams to converge; that’s a year of rewrites for zero new capability. And hour-long tasks mean the communication has to be asynchronous at its core. All three constraints point the same direction: don’t unify the agents, unify the conversation. I’d adopt an open agent-to- agent protocol — A2A — as the lingua franca, so each team keeps its framework and just adds a standard HTTP front door. Whiteboard:

                     +--------------------+
                     |   Agent Registry    |  (curated catalog of
                     |  [card] [card] ...  |   agent cards; vetting
                     +--------------------+   gate for new agents)
                        ^ publish    | discover/query
                        |            v
  User ---> +---------------------+
            |  Orchestrator agent |  (A2A client)
            +---------------------+
              |            |             |
        A2A/HTTPS     A2A/HTTPS     A2A/HTTPS + OAuth + mTLS
              v            v             v
        +---------+  +---------+   +----------------+
        | Research|  | Data    |   | Vendor pricing |
        | agent   |  | analysis|   | agent (external|
        |(LangGr.)|  | (CrewAI)|   |  next quarter) |
        +---------+  +---------+   +----------------+
             |            |
           MCP -> tools  MCP -> internal DBs
        (tools via MCP; peers via A2A)

  Task flow: submit -> working -> [input-required?] -> completed
             short task: sync/stream    long task: webhook callback

The pieces. Every agent, whatever its insides, exposes an A2A server endpoint and publishes an agent card — think of it as the agent’s business card: a JSON file with its name, endpoint, version, authentication requirements, and a list of skills with descriptions and example prompts. The card is the contract; the framework behind it becomes irrelevant, which is the entire trick.

Cards get published to a central registry — a curated internal catalog. I’m choosing a registry over the fully-decentralized option, where each agent just hosts its card at a well-known URL on its own domain, because a registry gives the enterprise a governance gate: when the vendor’s agent wants in next quarter, someone reviews its card, its auth setup, and its data-handling posture before it’s listed and discoverable. The registry is where ‘can this agent participate?’ gets decided once, instead of five times by five teams.

Runtime flow: a user asks the orchestrator for, say, a competitive pricing report. The orchestrator — the A2A client here — queries the registry, reads skill descriptions off the cards, and picks its subcontractors; because the cards carry natural-language descriptions and examples, the orchestrator’s own LLM can do this matching dynamically, which is exactly the dynamic-workflow requirement. It then creates tasks: structured delegations, each with a unique ID and an explicit lifecycle — submitted, working, completed, failed. For a thirty-second lookup it might use a synchronous call or stream results back over server-sent events, which is a persistent one-way channel for incremental updates. For the hour-long analysis job, holding a connection or hammering the status endpoint is silly, so the orchestrator registers a webhook — a callback URL the analysis agent pings when it finishes. The card tells you which modes each agent supports, so the orchestrator adapts per subcontractor.

Two protocol features I’d call out because they do real work. First, the input- required state: halfway through, the analysis agent can pause its task and ask the orchestrator ‘which fiscal year?’ — delegation becomes a conversation, and without that state you get failed tasks or silently wrong assumptions on every ambiguous request. Second, opacity: the orchestrator never sees inside its subcontractors — not their prompts, not their chain of reasoning, just card, task states, and output artifacts. Teams keep autonomy over their internals; the vendor keeps their proprietary logic private; the only coupling is the contract. That’s what makes both the five-internal- teams story and the external-vendor story the same story.

One distinction I want on the record, since these protocols get conflated: MCP and A2A solve different layers. MCP standardizes how an agent connects to its tools and data — databases, APIs, file systems. A2A standardizes how an agent talks to other agents. In this design each agent uses MCP internally to reach its own tools, and A2A externally to collaborate — tools versus colleagues, both protocols, different layers.

Security, especially with the vendor coming. Everything over TLS; for the cross-company link, mutual TLS, where both sides present certificates. Auth requirements live on each agent card — internal agents can use service credentials; the vendor gets OAuth tokens scoped to exactly the skills they’re allowed to invoke, passed in headers where they don’t leak into URL logs. Authorization is per-skill, not per-agent — being allowed to ask the pricing agent for quotes doesn’t grant its admin skills. And every task — who delegated, to whom, when, what came back — lands in an audit log, because when a three- agent workflow produces a wrong number in an executive report, I need to reconstruct the chain in minutes, not days. I’d also treat remote agents’ outputs as untrusted input: schema-validate artifacts before acting on them, because a subcontractor agent can be wrong, compromised, or just weird — it’s a reasoning black box, not a deterministic function.

Failure handling. Every failure mode of distributed systems applies, plus agent flavor. Timeouts per task with sensible defaults per skill; retries with idempotency keys so a retried ‘generate report’ doesn’t produce two reports; a fallback list per capability — if the primary research agent is down, the registry can offer an alternative that advertises the same skill, which is a resilience benefit you only get once capabilities are standardized and discoverable. If a task fails permanently, the orchestrator degrades gracefully: partial report with an explicit gap, rather than silent omission. For the agent-specific failures — a subcontractor returns confident nonsense — the orchestrator applies output validation and, for high-stakes artifacts, a critique pass before incorporating them.

Monitoring and evaluation: distributed tracing with the task ID as the correlation key, so one user request can be followed across five agents — without it, debugging a multi- agent workflow is archaeology. Dashboards per agent: task success rate, time-in-state (a task stuck in ‘working’ for three hours is an alert), input-required frequency (a spike means some agent’s requests are chronically ambiguous — a prompt bug upstream). End-to- end, I’d keep a suite of golden workflows replayed nightly against the live mesh, because five independently-deploying teams means the system integration is changing daily even when the protocol isn’t.

Cost is mostly organizational and architectural rather than per-token: each team implements one A2A adapter once — versus n-squared custom integrations that grow with every new agent — and the marginal cost of adding agent number six, including the vendor, is ‘publish a card, pass the registry review.’ There’s some latency overhead per hop from HTTP and task bookkeeping, which is why I’d keep genuinely chatty, tightly- coupled agent pairs inside one process behind a single A2A front door, and use the protocol at true team and company boundaries — standardize where the boundaries are real, not everywhere.

Summary: keep every team’s framework, add a standard front door per agent; agent cards plus a curated registry make capabilities discoverable and governed; async task lifecycles with streaming and webhooks handle seconds-to-hours work; scoped OAuth, mTLS, and audit logs make it safe to extend to a vendor; and MCP handles each agent’s tools while A2A handles the conversation between them.“

Follow-ups they will ask

“A2A versus MCP — when do you use which?” The one-liner: MCP standardizes an agent’s connection to tools and data; A2A standardizes agent-to-agent collaboration. Deeper cut: a tool is invoked and mechanically returns; an agent is delegated to and reasons — long-running, stateful, capable of asking clarifying questions (input-required). Use both in one system: MCP inside each agent, A2A between agents. Grey zone worth acknowledging: you can wrap a simple agent as an MCP tool; prefer A2A when you need task lifecycles, streaming, negotiation, or cross-org boundaries.

“Why a protocol instead of a message queue like Kafka, or plain REST APIs?” A queue gives transport but no shared semantics — every pair of teams still invents its own message formats, task states, and discovery story, which is the babel problem relocated. Bespoke REST works for two agents and decays into n-squared custom integrations as agents multiply. The protocol’s value is the standardized layer on top: cards, discovery, task lifecycle, interaction modes — agreed once, spoken by everyone, including agents you don’t control.

“How does the orchestrator pick which agent to delegate to?” Discovery via the registry, then matching: skill descriptions and example prompts on the cards are written for LLM consumption, so the orchestrator can reason over them like a hiring manager reading résumés. Harden it with structured tags for filtering, a preference/fallback ranking per capability, and observed reliability stats feeding selection — route around agents whose task-failure rate is climbing.

“What stops a malicious or compromised agent from joining and wreaking havoc?” Layers: the registry as a vetting gate (no listing, no discovery), per-skill scoped authorization so a compromised credential has a small blast radius, mTLS so you know who’s on the wire, schema validation and sanitization of all inbound artifacts — a remote agent’s output is untrusted input, and could even carry prompt-injection text aimed at your orchestrator’s LLM — plus audit logs and anomaly detection on traffic patterns. Never extend blind trust to opaque reasoning systems.

“How do you debug a workflow spanning agents owned by three different teams?” Distributed tracing keyed on task and context IDs across every hop; each agent logs task-state transitions with timestamps; the audit trail gives the cross-team timeline nobody can dispute. Add replayable golden workflows to catch integration breakage before users do, and per-agent SLAs so accountability has edges. The honest admission: opacity is great for autonomy and terrible for debugging — the trace boundary is the team boundary, and that’s a deliberate trade.

“What if two agents’ schemas or interpretations subtly disagree — one’s ‘net price’ is another’s ‘gross price’?” Protocols standardize the envelope, not the meaning. Mitigations: typed structured parts rather than free text at critical interfaces, explicit schemas versioned in the cards, contract tests between agent pairs, and semantic checks in the orchestrator (units, ranges, cross-field sanity). Semantic drift is the multi-agent version of the classic microservices integration bug — same disease, agentic accent.

Say it in one breath

“When agents built by different teams or vendors must collaborate, don’t unify their frameworks — unify their conversation: an open protocol like A2A gives every agent an HTTP front door and an agent card, a business card describing what it can do; clients discover cards via a registry, delegate work as tracked tasks that stream updates or call back via webhooks and can pause to ask clarifying questions, all under TLS, scoped OAuth, and audit logs — and in one sentence, MCP connects an agent to its tools while A2A connects it to other agents.”