Communication Protocols Between AI Agents

Key facts, with sources

• Anthropic reported that a multi-agent research system using an Opus lead agent with Sonnet subagents outperformed a single-agent Opus baseline by 90.2 percent on its internal research eval. (ByteByteGo)
• Anthropic's multi-agent research system used about 15x more tokens than a normal chat interaction, and token usage alone explained roughly 80 percent of performance variance. (The AI Engineer)
• The MAST research taxonomy identified 14 distinct failure modes across 7 popular multi-agent frameworks including AutoGen, ChatDev, and CrewAI, grouped into system design flaws, inter-agent misalignment, and task verification failures. (arXiv)
• Salesforce research found organizations run an average of 12 AI agents and projects multi-agent adoption to surge 67 percent within two years as enterprises move toward orchestration. (Salesforce)
• Multi-agent orchestration with three or more agents represents about 22 percent of enterprise agent deployments in 2026, projected to reach roughly 45 to 50 percent by 2027. (OnAbout AI)

Why prose handoffs rot

Prose between agents fails slowly, which is what makes it dangerous. An upstream agent rephrases its output slightly after a prompt tweak, a downstream agent interprets the new phrasing differently, and quality degrades with no error, no log line, no failing test. You cannot assert on prose, so you cannot write a regression test for the handoff. Context also snowballs: each agent appends its narration, transcripts balloon, and token costs climb while the signal-to-noise ratio falls.

The deeper issue is that prose hides the contract. When agent B consumes agent A's output, there is a real dependency — specific fields B needs, assumptions B makes. Prose keeps that contract implicit in two prompts that drift independently. Structured messages force the contract into the open where it can be validated, versioned, and tested.

Anatomy of a message envelope

I split every message into an envelope and a payload. The envelope is identical across the whole system: message ID, trace ID for stitching a run together, sender, recipient, intent, schema version, and a timestamp. The payload is typed per message kind and validated with its own model.

Two layers of validation happen on receipt: the envelope first, then the payload against the schema its sender and intent imply. Anything that fails either check is rejected at the boundary and logged — never passed along in the hope a downstream model will cope. That hope is how silent corruption spreads.

from datetime import datetime, timezone
from typing import Any, Literal
from uuid import uuid4

from pydantic import BaseModel, Field

class AgentMessage(BaseModel):
    message_id: str = Field(default_factory=lambda: uuid4().hex)
    trace_id: str
    sender: str
    recipient: str
    intent: Literal["request", "result", "error", "handoff"]
    schema_version: int = 1
    payload: dict[str, Any]
    created_at: datetime = Field(
        default_factory=lambda: datetime.now(timezone.utc)
    )

class ExtractionResult(BaseModel):
    document_id: str
    facts: list[str]
    confidence: float = Field(ge=0.0, le=1.0)

def handle(raw: dict) -> None:
    msg = AgentMessage.model_validate(raw)  # reject bad envelopes
    if msg.intent == "result" and msg.sender == "extractor":
        result = ExtractionResult.model_validate(msg.payload)
        process_facts(result)
    elif msg.intent == "error":
        route_to_retry_or_dead_letter(msg)

Intents: a small verb set keeps routing sane

Four intents cover nearly everything I build. A request asks an agent to do work and carries the task specification. A result returns completed work and must satisfy the payload schema for that task type. An error reports failure and carries a machine-readable reason plus a retryable flag, so the router can distinguish a rate limit from a permanently malformed task. A handoff transfers ownership of a task mid-flight — used sparingly, because it is the intent most likely to hide spaghetti routing.

The discipline is resisting new verbs. When someone proposes a 'clarification' or 'negotiation' intent, it usually means a task specification was too vague to execute — which is a schema problem to fix at the source, not a new conversation type to support forever.

Transport: function calls first, queues when forced

The envelope is independent of how messages move, and that separation is the point. Start with the simplest transport: in-process function calls, with the orchestrator passing validated message objects between agents in one Python process. This covers more production systems than people admit, and it keeps debugging local.

A queue earns its place when you need async execution, burst absorption, retries with backoff, or independent scaling of agent roles — real operational pressures, not architectural aspiration. HTTP between services makes sense when agents are owned by different teams or genuinely need separate deployment lifecycles. Because the envelope never changes shape across transports, migrating from function calls to a queue is plumbing work, not a redesign — which is exactly the option you want to keep open.

Versioning like a public API

The moment two agents are deployed or modified independently, their message contract is a public API between them, and it deserves the same discipline. Every payload schema carries a version. Changes are additive where possible — new optional fields, never repurposed ones. When a breaking change is unavoidable, the consumer accepts both versions during a migration window, and the version field tells it which parser to apply.

Messages that fail validation go to a dead-letter store with their full envelope, not into a retry loop — a schema mismatch will fail identically on every attempt, and retrying it just makes noise. A spike in dead-lettered messages after a deploy is the fastest signal you shipped a contract break, and I alert on it directly.

Where standards are heading

The standardization picture is settling unevenly. The model-to-tool connection has largely converged: the Model Context Protocol gives models a standard way to discover and call tools and data sources, and it is broadly supported. Agent-to-agent protocols — discovery, task delegation, and negotiation between agents built by different vendors — have published proposals but nothing I would call settled, and I do not bet client architectures on them yet.

My hedge is to keep the in-house protocol deliberately thin: a small envelope, typed payloads, four intents. If a cross-vendor standard wins, a thin protocol adapts with a translation layer at the boundary. The teams that will hurt are the ones with elaborate bespoke negotiation semantics baked into every agent — rich protocols are exactly the ones that resist migration.

When to hire senior help

Multi-agent orchestration is one of the least commoditized skills in AI engineering, and teams that succeed usually include someone who has debugged coordination failures in production. Get senior review before committing to an orchestrator-worker design, because architectural mistakes at this layer are expensive to unwind after launch. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships AI — Multi-Agent Architectures projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Defaulting to multi-agent when a single agent with good tools would do, since the roughly 15x token multiplier only pays off when subtasks are genuinely parallel and high value
• ✕Letting subagents share full conversation history instead of scoped task briefs, causing context bloat, contradictory actions, and coordination failures
• ✕Shipping without a verification layer, so errors propagate through agent chains unchecked; task verification failures are one of the three MAST failure categories
• ✕Skipping per-agent trace observability, which makes it impossible to identify which agent in the chain caused a bad final output

Frequently asked questions

Sources

• ByteByteGo
• The AI Engineer
• arXiv
• Salesforce
• OnAbout AI