Protocols in Agentic Systems

A developer explains that protocols are the critical but overlooked plumbing in multi-agent AI systems, defining shared contracts for communication that prevent failures when agents interact. The post highlights tool-calling schemas and Google's Agent2Agent (A2A) protocol as examples of standardizing agent-to-agent communication.

Picture an office where every employee speaks a different language, uses a different filing system, and refuses to fill out the same form twice. That's most multi-agent AI systems before someone introduces a protocol. Agents are brilliant in isolation and chaotic in groups, and the only thing standing between "chaotic" and "coordinated" is a shared set of rules about who says what, when, and in what format. This is the unglamorous half of agentic AI. Nobody writes a viral demo about a well-designed message schema. But spend a week debugging an agent swarm that silently corrupts its own state, and you'll start treating protocols with the reverence usually reserved for database transactions. A protocol, in the agentic context, is an agreed-upon contract for communication. It answers four questions: That's it. It's not a model architecture, not a prompting trick, not a clever chain-of-thought technique. It's plumbing. And like plumbing, you only think about it when it leaks. A useful mental model: if a single LLM call is a sentence and a ReAct loop is a conversation with yourself, a protocol is etiquette for a conversation with strangers. The moment more than one autonomous component is involved - another agent, a tool, a human, or a database - etiquette stops being optional. Humans get away with sloppy communication because we're extraordinary at inferring intent. Say "Can you grab that?" while pointing vaguely at a table, and another person fills in the gaps using context, tone, and shared history. Agents don't do this gracefully. An LLM agent calling a tool with a malformed argument doesn't pause and think, "They probably meant the CSV, not the JSON." It either fails loudly, fails silently, or - worse - succeeds in a way nobody intended. Without a protocol, here's a fairly typical failure mode in a two-agent setup: Agent A:"Here's the summary you asked for: wall of unstructured text ." Agent B: expecting a JSON object with a summary key, gets a string instead, crashes trying to parse it Nobody did anything "wrong" exactly. Agent A produced a perfectly reasonable summary. Agent B had a perfectly reasonable expectation. The system failed because nobody agreed in advance on the shape of the handoff. This is the agentic equivalent of two people agreeing to meet "later" without specifying a time — technically an agreement but practically useless. The most common protocol any agent encounters: a structured schema usually JSON describing what a tool accepts and returns. This is the seatbelt of agentic systems - unglamorous, occasionally annoying, and the reason you don't go through the windshield when a model decides to get creative with its output format. Example: OpenAI's function calling, Anthropic's tool-use API, and Google's function declarations all do the same fundamental thing - they force the model to emit a structured payload {"name": "get weather", "arguments": {"city": "Pune"}} instead of a free-text guess at what a tool call should look like. The protocol isn't the tool. It's the agreed format for requesting the tool. This is the layer that gets the least attention and causes the most pain. Tool-calling protocols govern how an agent talks to a function . A2A protocols govern how an agent talks to another agent - a fundamentally messier problem, because the other party isn't a deterministic API. It's another model with its own context, its own interpretation of the task, and its own way of going off-script. A workable A2A protocol typically needs to define: {"from": "researcher", "to": "writer", "type": "handoff", "payload": {...}} . Industry example: Google's Agent2Agent A2A protocol is a direct attempt to standardise exactly this - giving agents built on different frameworks say, one built with LangGraph and another with CrewAI a common envelope for discovering each other's capabilities and exchanging tasks, regardless of which vendor or framework built them. Without something like this, every pair of agent frameworks needs a custom translator, which scales about as well as you'd expect - that is, badly. Frameworks like AutoGen and CrewAI bake a version of A2A messaging into their internals already - when a "manager" agent delegates to a "worker" agent, there's a defined message format underneath, even if it's framework-specific rather than a true open standard. The trend industry-wide is towards pulling that logic out of individual frameworks and into shared, framework-agnostic protocols. How does an agent know what tools and data exist without every integration being hand-wired? This is where the Model Context Protocol MCP comes in - an open standard for connecting AI applications to external tools, data sources, and systems through a single, consistent interface. Think of it as the difference between every appliance in your house needing its own proprietary charger versus everything just using USB-C. Mildly annoying to standardise, wildly convenient once it's done. Concrete example: Without MCP, an agent that needs to read files from Google Drive, query a Postgres database, and check GitHub issues needs three separate, custom-built integrations - each with its own auth handling, its own response format, and its own edge cases to maintain. With MCP, each of those becomes an MCP server that exposes its capabilities e.g., list files , run query , get issue in a standard format. Any MCP-compatible agent can then talk to any of them the same way, without bespoke glue code per integration. Anthropic's Claude Desktop, for instance, can connect to a local filesystem MCP server or a Slack MCP server using the same underlying protocol - the agent doesn't need a different communication style for each one. This is also why MCP gets compared to the Language Server Protocol LSP in developer tooling. Before LSP, every code editor needed a custom integration for every programming language's autocomplete and linting. LSP lets editors and language tooling agree on one interface, so any editor could support any language without N×M custom integrations. MCP is making the same bet for agents and tools. In a multi-agent workflow, somebody has to decide whose turn it is to act, or you get the digital equivalent of a conference call where four people start talking at once and two never get a word in. This is a real protocol layer, not just a scheduling detail, because it defines a contract: only one agent or a defined subset may act at a time, and there's an explicit rule for handing control back. A few concrete patterns in current use: GroupChat manager cycles through agents in turn or selects the next speaker based on the conversation so far, with an explicit manager component responsible for the decision, rather than leaving it to the agents to sort out among themselves.In each case, the underlying agreement is the same: turn-taking can't be implicit. Someone - a manager process, a graph,or a queue - has to own the decision of who acts next, or the system devolves into agents talking over each other or, just as commonly, everyone waiting for someone else to go first. What happens when a tool call fails, a response times out, or an agent returns something nonsensical? This counts as a protocol because it's a contract too - just one for the unhappy path instead of the happy one. A system without this contract doesn't fail gracefully; it fails wherever it happens to fail , which in production is usually somewhere inconvenient. Concrete patterns worth knowing: {"status": "error", "reason": "rate limited"} that the calling agent can actually reason about and act on.Consider a simple two-agent system: a Researcher agent that searches the web and a Writer agent that drafts a summary from the research. Without a protocol , the Researcher might return: Found some interesting stuff about quantum computing, here's what I think... The Writer agent, expecting structured findings, has to guess what's a fact, what's the Researcher's opinion, and what's even usable. It's working from vibes. With a protocol , the contract might look like this: { "from": "researcher", "to": "writer", "type": "handoff", "status": "complete", "findings": {"claim": "...", "source": "...", "confidence": "high"} } Now the Writer knows exactly what it's receiving, can validate it before using it, and - crucially - can fail predictably if the Researcher sends something malformed, rather than failing mysteriously. The difference between these two systems isn't model quality. It's whether anyone bothered to define the interface. If you're building a multi-agent system and rolling your own protocol — which, early on, you often will - a few things tend to matter more than they first appear: "version": "1.2" field.Protocols don't make agentic systems smarter. They make them legible to each other and to the humans trying to debug them at midnight. The flashy parts of agentic AI reasoning loops, tool use, autonomous planning get the conference talks. Protocols get the postmortems. But every durable multi-agent system, from A2A and orchestrator frameworks to standards like MCP, is ultimately betting on the same unsexy truth: agents that agree on how to talk to each other will always outlast agents that are merely good at talking.