Realizing: Agent-to-Agent Communication
How protocols, registries, and orchestration turn independent AI agents into one coordinated system.The last piece in this series laid out a six-layer stack for the Agentic Web: trust, identity, communication, delegation, orchestration, and memory. That stack answers what needs to exist. This piece…
How protocols, registries, and orchestration turn independent AI agents into one coordinated system.The last piece in this series laid out a six-layer stack for the Agentic Web: trust, identity, communication, delegation, orchestration, and memory. That stack answers what needs to exist. This piece answers a narrower question: once those layers are in place, what actually makes a pile of independent agents behave like one coordinated system?Three things, as it turns out. A shared protocol so agents can talk to each other without a translator. A registry so an orchestrator can find the right agent instead of hard-coding a list of endpoints. And a planning layer, the part I’ll call the Brain, that turns a human’s intent into a working plan and routes it across the mesh.Put those three things around a set of specialized agents, and you get what the earlier article called a quilt: dozens of narrow, purpose-built agents stitched together into something that can handle a real workflow. The quilt is the output. Protocol, registry, and Brain are what make the stitching possible.The Protocol Layer: Three Standards, Three Different JobsAsk five people what “agent-to-agent communication” means, and you’ll get five different answers because the industry hasn’t converged on a single protocol. Instead, it has converged on three: MCP, A2A, and ANP; each solving a different slice of the problem. Here’s how the three line up:+----------------+-----------------------+-----------------------+-----------------------+| DIMENSION | MCP | A2A | ANP |+----------------+-----------------------+-----------------------+-----------------------+| Purpose | Vertical connection: | Horizontal connection:| Peer-to-peer inter- || | Defines how one agent | Defines how two inde- | actions. Trustless, || | talks to its toolbox. | pendent agents find & | no central authority || | | exchange tasks. | or shared registry. |+----------------+-----------------------+-----------------------+-----------------------+| Governed by | Anthropic, open spec | Linux Foundation | Open source community || | | (orig. Google) | |+----------------+-----------------------+-----------------------+-----------------------+| Primary job | Agent to tool access | Cross vendor task | Decentralized peer to || | | delegation | peer discovery |+----------------+-----------------------+-----------------------+-----------------------+| Topology | Hub and spoke, | Client server, | Decentralized mesh || | host to server | task delegation | |+----------------+-----------------------+-----------------------+-----------------------+| Transport | stdio, | HTTPS, SSE, | HTTPS and decentral- || | Streamable HTTP | webhooks, gRPC | ized transports |+----------------+-----------------------+-----------------------+-----------------------+| Identity | Host managed OAuth | OAuth 2.0, mTLS, | Cryptographic || & Auth | or API keys | A2A extensions | W3C DIDs |+----------------+-----------------------+-----------------------+-----------------------+| Discovery | Manual or | /.well-known/ | DID resolution || | static config | agent-card.json | and .well-known |+----------------+-----------------------+-----------------------+-----------------------+The Model Context Protocol, or MCP, is the one most developers have already touched. It serves as a vertical tether connecting an agent directly to its tools. However, it is not built for agent-to-agent conversation, and it was never meant to be.The Agent-to-Agent protocol, A2A, fills that exact gap. Proposed by Google and now stewarded by the Linux Foundation, it handles the horizontal task exchange between agents. Yet, A2A leaves critical pieces undefined. It does not standardize a native publish-and-subscribe pattern for many agents listening to one event, nor does it provide a single signed envelope that carries proof of identity and authority with every message.Finally, the Agent Network Protocol, ANP, takes a different bet entirely. Though less mature and driven largely by open-source community efforts, ANP targets a scenario the others sidestep. It asks what happens when agents need to trust each other directly with no intermediary at all.Here is the overarching point I want to make. None of these three protocols is wrong, and none of them is the whole answer. MCP handles the vertical connection to tools. A2A handles horizontal task exchange between agents. ANP handles the trustless, no-registry case. What remains missing across all three is a shared envelope.We desperately need a unified layer that allows a message to carry the identity and authority of its sender in a form every recipient can verify, regardless of which protocol moved it. That missing link, a unifying communication layer carrying undeniable proof of provenance, is exactly what Layer 3 of the proposed stack was designed to solve.The Registry Layer: Finding the Right AgentA protocol only matters once you know who to send the message to. That’s the registry’s job, and it’s exactly the semantic DNS problem described in Layer 2 of the earlier article: not “where is agent X,” but “find me an agent that can do Y, certified for Z, under this latency budget.”A handful of real projects are already building toward that:+-----------------------+----------+-----------------------------------+-------------------------------------------------------------------+| REGISTRY / SOLUTION | ORG | PRIMARY FOCUS | KEY MECHANICS & FEATURES |+-----------------------+----------+-----------------------------------+-------------------------------------------------------------------+| NANDA Index | MIT | Global Agent Discovery | Maps decentralized identifiers to capability descriptions. || | | | Separates routing information from verifiable trust claims so || | | | lookups and trust checks are decoupled. |+-----------------------+----------+-----------------------------------+-------------------------------------------------------------------+| Google Agent Registry | Google | Enterprise Governance | Centralized catalog for MCP servers and A2A agents inside Google || | | | Cloud. Prevents redundant integrations and pairs with Agent || | | | Gateway to enforce permissions. |+-----------------------+----------+-----------------------------------+-------------------------------------------------------------------+| AWS Agent Registry | AWS | Enterprise Discovery & Federation | Provides a centralized, searchable catalog within AWS for agents, || | | | tools, and MCP servers with built-in approval workflows. Supports || | | | the open Agentic Resource Discovery (ARD) specification, enabling || | | | federation across different registries and multi-cloud || | | | environments like a DNS for agents. |+-----------------------+----------+-----------------------------------+-------------------------------------------------------------------+| fetch.ai | fetch.ai | Personal AI Agents with Discovery | Within the Fetch.ai ecosystem, Agentverse acts as the central || | | | discovery and growth engine. Rather than serving as a static || | | | directory, it functions as a live semantic registry where systems || | | | can find, evaluate, and deploy agents based strictly on their || | | | capabilities and operational constraints. |+-----------------------+----------+-----------------------------------+-------------------------------------------------------------------+NANDA Index, Google Agent Registry, AWS Agent Registry, and fetch.ai.Along with a registry, you need an agent’s resume for the registry to search against. That resume is Agent Facts. Picture a newly minted AI agent arriving at a massive digital switchboard like the AWS or Google Registry. Rather than waiting passively, it immediately presents a highly structured resume.This capability manifest holds the vital “Agent Facts” required for discovery: the agent’s exact identity, its authorized permissions, and its strict operational boundaries. By broadcasting these core attributes long before any work begins, the registry transforms from a blind directory into an intelligent matchmaker, instantly pairing complex jobs with the exact digital worker built to solve them.+-------------------------------------------------------------+| || AGENT FACTS || (Capability Manifest) || |+-------------------------------------------------------------+| || [1] IDENTITY & GOVERNANCE || * Decentralized ID (DID) || * Publisher / Owner Info || * Version Number || * Approval Status (Pending / Approved) || || [2] SEMANTIC CAPABILITIES || * Executable Task Descriptions || * Connected Tools & Endpoints || * Input/Output Data Formats (MIME types) || || [3] TRUST & COMPLIANCE || * Cryptographic Signatures || * Regulatory Certifications (e.g., SOC 2, HIPAA) || * Operational & Financial Constraints || |+-------------------------------------------------------------+Different projects, different motivations, but the same underlying need. Without a centralized registry and standardized Agent Facts feeding it, every multi-agent system has to be wired by hand, which is fine for a demo and unworkable at scale.The Brain: Turning Intent Into a PlanThis is the part that actually does the coordinating, what Layer 5 of the stack calls the Orchestration Mesh. Give it a complex goal, and it has to figure out which agents are needed, in what order, and how to route the work between them, all without a human standing in the loop for every step. It helps to break that into three stages:Planning: A supervisor agent takes the incoming goal and decomposes it into a directed acyclic graph, a map of tasks where each node knows what has to finish before it can start. Frameworks like LangGraph make this concrete. Once the plan exists as a graph rather than a script, a few things become possible almost for free: independent subtasks can fan out to multiple agents in parallel, dependent steps can wait behind a synchronization barrier until everything upstream is ready, and the plan can branch conditionally based on what earlier steps return.Resolution: Once the plan says “this node needs an agent that can do X,” something has to translate that requirement into an actual candidate. This stage takes the natural language description of what’s needed and turns it into a structured capability query against the registry, coming back with a ranked list of agents that fit the skill, price, and compliance requirements for that specific node. It’s worth naming this stage carefully. OWASP has its own proposal in this space called the Agent Name Service, and rather than reuse that name for a different design, it’s cleaner to call this stage what it does: capability resolution.Gateway: Once a specific agent has been chosen, something has to turn that logical identity into a live, secure network connection. The gateway handles the actual handoff, negotiates the protocol exchange (A2A, most commonly, for cross-vendor calls), and keeps the communication channel bound and authenticated for the life of the task.Planning decides what needs to happen. Resolution decides who does it. The gateway makes the connection real. Together, that’s what turns a set of independently capable agents into a single system that can execute a goal a human only had to state once.Where This Leaves UsGo back to the Cisco analogy from the first article in this series. Cisco didn’t win by building the smartest application. It won by owning the layer every application had to run through to talk to anything else. Protocol, registry, and orchestration are that layer for the Agentic Web: not the agents themselves, but the connective tissue that lets independently built agents behave like one coordinated system instead of five hundred employees with no shared language.The pieces exist today in early, uneven form. MCP and A2A are real and in production. Registries like NANDA and fetch.ai are running at a meaningful scale. Orchestration frameworks like LangGraph are already shipping the planning stage described above.What’s still missing is the unifying envelope from Layer 3 and a delegation model mature enough to make the payment layer trustworthy at scale, which is exactly where the next article in this series picks up.This story is published under the Generative AI publication. Connect with us on LinkedIn and follow Zeniteq to stay in the loop with the latest AI stories. Let’s shape the future of AI together!Realizing: Agent-to-Agent Communication was originally published in Generative AI on Medium, where people are continuing the conversation by highlighting and responding to this story.Source: Generative AI Pub — Published — Category: Image AI