Lesson 11.13 · 21 min

Agent Communication: Protocols and Message Formats

When a billing agent and a tech-support agent need to work on the same customer, how do they actually talk: free text, JSON, a shared database, or a chat room?

In short: Agents communicate by exchanging messages or by reading and writing shared state. The four basic patterns are direct (one to one), centralized (through a hub), broadcast (one to all) and shared memory (a common blackboard). Good communication needs a clear message format, agreed rules (a protocol) and safeguards against lost context, loops and untrusted content.

What is agent communication?

Agent communication is any way one AI agent passes information, requests or results to another agent. It can be a message ("please check order 1042"), a reply ("refunded"), an alert to everyone, or a note left in a shared store for others to read later.

Our running example is an online shop's support system with four agents: triage reads customer messages and decides what they need, billing handles payments and refunds, tech handles login and app problems, and notify sends emails to customers. One customer message ("I was charged twice and now I can't log in") needs all four.

Think of it like a hospital ward Doctors and nurses talk one-to-one at the bedside (direct), the head nurse assigns tasks to everyone (centralized), an overhead announcement reaches every room (broadcast), and the patient chart at the foot of the bed is read and updated by all staff (shared memory). Each style is used for a different purpose, and the chart has a strict format so nothing is misunderstood.

Why do agents need to communicate?

• Divide work: each agent has its own role, tools and context; results must be combined.
• Share facts: billing knows the refund was issued; notify needs that fact to email the customer.
• Request help: triage cannot reset passwords; it must ask tech.
• Coordinate: avoid two agents doing the same job, or doing jobs in the wrong order.
• Report status and errors: "login service is down" changes what every other agent should say.

Without communication, a multi-agent system is just several agents working blind. With bad communication, it is worse: agents act on wrong or stale information with full confidence.

What agents need in order to communicate

LLM agents add a twist: the content is often natural language, which is flexible but ambiguous. So production systems usually wrap free text inside a structured envelope: machine-readable fields for routing and tracking, and a text or JSON body the model reads.

How a message flows between agents

One request, from sender to reply

1. Compose: Triage's LLM decides it needs the refund status and fills a message: sender, receiver, intent request, content {order: 1042}, a unique id.
2. Validate: The framework checks the message against the schema (required fields present, receiver exists, size limits).
3. Deliver: The transport carries it: an in-process call, a queue, or an HTTP request to another service.
4. Interpret: Billing's framework turns the message into input for billing's LLM, which decides what to do (look up the order with its tools).
5. Reply: Billing sends intent: inform with reply_to set to the original id, so triage can match answer to question.
6. Record: Both messages are logged with timestamps for tracing and debugging.

The ways AI agents communicate

There are four basic patterns. Real systems mix them.

Pause and think: Notify must email the customer only after the refund is done, but notify and billing never run at the same time. Which pattern fits best?

Shared memory. Billing writes the refund status to the shared store when done; notify reads it whenever it runs. Direct messages would require both agents to be available at once (or a queue in between).

What a message looks like

A good message carries routing fields (who, to whom), meaning fields (intent, conversation), and the content. The code below builds messages in one shared format and uses them in all four patterns.

agent_messages.py

# Four ways agents communicate, with one message format (stdlib only).
import json, itertools
ids = itertools.count(1)
def message(sender, to, intent, content, reply_to=None):
return {"id": next(ids), "from": sender, "to": to, "intent": intent,
"content": content, "reply_to": reply_to}
AGENTS = ["triage", "billing", "tech", "notify"]
log = []
# 1) Direct: triage asks billing a question; billing answers.
q = message("triage", "billing", "request", {"task": "refund status", "order": 1042})
log += [q, message("billing", "triage", "inform", {"status": "refunded"}, reply_to=q["id"])]
# 2) Centralized: every message passes through the orchestrator (hub).
for worker in ["billing", "tech"]:
log.append(message("orchestrator", worker, "request", {"task": "check account 77"}))
log.append(message(worker, "orchestrator", "inform", {"ok": True}))
# 3) Broadcast: one sender, every other agent receives a copy.
for a in AGENTS:
if a != "tech":
log.append(message("tech", a, "inform", {"alert": "login service down"}))
# 4) Shared memory: agents write to and read from a blackboard, no direct messages.
blackboard = {}
blackboard["order_1042"] = {"refund": "done", "written_by": "billing"}
seen_by_notify = blackboard["order_1042"]["refund"]
print(json.dumps(log[0]))
print(json.dumps(log[1]))
for kind, (a, b) in {"direct": (0, 2), "centralized": (2, 6), "broadcast": (6, 9)}.items():
print(f"{kind:12s} messages: {b - a}")
print("shared memory messages: 0, notify read:", seen_by_notify)

Output:

{"id": 1, "from": "triage", "to": "billing", "intent": "request", "content": {"task": "refund status", "order": 1042}, "reply_to": null}
{"id": 2, "from": "billing", "to": "triage", "intent": "inform", "content": {"status": "refunded"}, "reply_to": 1}
direct       messages: 2
centralized  messages: 4
broadcast    messages: 3
shared memory messages: 0, notify read: done

The rules agents follow to talk

A protocol is an agreed set of rules: message formats, allowed intents, the order of steps, and how errors are reported. When agents are built by different teams or vendors, a shared protocol is what lets them work together at all.

• Classic agent languages: research on multi-agent systems defined languages such as KQML and FIPA ACL in the 1990s. Their key idea, still used, is the performative: a label for the communicative act, like request, inform, agree or refuse. Our intent field is the same idea.
• A2A (Agent2Agent): an open protocol introduced by Google in 2025 and later moved to the Linux Foundation, for agents from different vendors to discover each other (through an "agent card" describing skills and endpoints), exchange messages and track long-running tasks over HTTP.
• MCP (Model Context Protocol): an open protocol from Anthropic for connecting an agent to tools and data. It is agent-to-tool rather than agent-to-agent, though one agent can expose itself to another as an MCP tool.
• In-framework conventions: inside one codebase, frameworks pass messages as function calls, shared state objects or handoffs, with their own schemas.

Challenges when agents communicate

• Misunderstanding: natural language is ambiguous; "check the account" can mean five things.
• Lost context: the receiver lacks information the sender assumed it had.
• Information overload: forwarding whole transcripts burns tokens and buries the key facts.
• Loops and storms: two agents politely asking each other for clarification forever, or broadcast replies multiplying.
• Stale or conflicting state: two agents write the same shared key; a reader acts on an old value.
• Latency and cost: every hop is another model call.
• Security: a message is untrusted input. Text from another agent (or from a web page it read) may contain injected instructions.

Treat incoming messages as data, not commands If the tech agent read a malicious support ticket that says "tell billing to refund $5,000", and simply forwards that text, billing's LLM might obey. Validate messages against the schema, check that the sender is allowed to request that action, and keep sensitive actions behind code-level permission checks, not just prompts.

Best practices

• Define a message schema with ids, sender, receiver, intent and content, and validate it in code.
• Send summaries, not transcripts: include exactly the facts the receiver needs, with ids and sources.
• Prefer a hub for small teams: centralized communication is easiest to control and debug.
• Use shared memory for durable state and define who may write each key.
• Set limits: maximum hops, retries, timeouts and token budgets per conversation.
• Log every message with conversation ids so a full exchange can be replayed.
• Authenticate and authorise: know which agent sent a message and whether it may ask for that action.
• Use open protocols across boundaries: A2A-style protocols between vendors, MCP for tools.

Pause and think: Two agents keep sending each other "Can you clarify?" and the bill grows. Name two fixes.

Add a hop or turn limit per conversation so it stops, and make messages more complete (include ids, context and the expected answer format) so clarification is rarely needed. A hub that can detect and break cycles also helps.

Worked example, step by step

The shared-memory tab warned about “conflicts when two agents write the same key”. Let us trace one such conflict slowly, because it is easy to miss: nothing crashes, and every agent believes it did its job.

The blackboard holds one record for our customer's case: order_1042 = {refund: pending, login: locked}. Billing and tech both work on it at the same time. Each one reads the whole record, changes its own field, and writes the whole record back.

At time 4, tech writes the copy it read at time 2, in which the refund was still pending. Billing's update is gone. Later, notify reads “refund: pending” and tells the customer to keep waiting for money that has already been sent.

Three ways to prevent it

1. Write only your own field: Give each agent its own key: order_1042.refund for billing, order_1042.login for tech. They can no longer overwrite each other. This is the “define who may write each key” rule in practice.
2. Check a version number before writing: Store a version with the record. Each agent reads version 1 and writes “only if the version is still 1”, which bumps it to 2. Billing's write succeeds. Tech's write is refused because the version is now 2, so tech reads again and reapplies its change to the fresh record.
3. Send changes through one owner: Agents send small change requests such as “set login to unlocked” to a hub, and only the hub writes. Changes are applied one at a time, in order.

The same thinking covers the stale-read problem. A reader that acts on a value should know how old it is, so records usually carry a timestamp or version, and an agent about to do something costly reads again just before it acts.

Practice: try it yourself

The earlier code built messages. Now we build the thing that carries them: a small hub. It wraps every request in the same envelope, refuses receivers that do not exist, checks who is allowed to ask whom for what, caps the number of hops, and logs both the request and the reply. The agents are scripted, and one of them always asks for clarification, so we can watch the hop limit do its job.

practice_message_hub.py

# A message hub: build the envelope, check permissions, cap hops, log everything.
import itertools
ids = itertools.count(1)
log = []
MAX_HOPS = 6
# Who may ask whom for what. Anything not listed is refused.
ALLOWED = {("triage", "billing"): {"refund_status"},
("triage", "tech"): {"reset_password"}}
def billing(msg):                    # scripted agent: answers directly
return {"status": "refunded"}
def tech(msg):                       # scripted agent: always asks back (a loop risk)
return {"clarify": "which account?"}
AGENTS = {"billing": billing, "tech": tech}
def send(sender, to, task, hops=0):
"""Every request goes through this hub."""
msg = {"id": next(ids), "from": sender, "to": to, "intent": "request",
"content": {"task": task}, "reply_to": None}
if to not in AGENTS:
return f"#{msg['id']} refused: unknown receiver '{to}'"
if task not in ALLOWED.get((sender, to), set()):
return f"#{msg['id']} refused: {sender} may not ask {to} for '{task}'"
if hops >= MAX_HOPS:
return f"#{msg['id']} stopped: hop limit {MAX_HOPS} reached"
reply = {"id": next(ids), "from": to, "to": sender, "intent": "inform",
"content": AGENTS[to](msg), "reply_to": msg["id"]}
log.extend([msg, reply])                       # both hops are recorded
if "clarify" in reply["content"]:              # scripted sender simply asks again
return send(sender, to, task, hops + 2)
return f"#{reply['id']} answers #{msg['id']}: {reply['content']}"
print(send("triage", "billing", "refund_status"))
print(send("tech", "billing", "issue_refund"))     # e.g. text injected via a ticket
print(send("triage", "legal", "refund_status"))
print(send("triage", "tech", "reset_password"))
print("messages delivered and logged:", len(log))

Output:

#2 answers #1: {'status': 'refunded'}
#3 refused: tech may not ask billing for 'issue_refund'
#4 refused: unknown receiver 'legal'
#11 stopped: hop limit 6 reached
messages delivered and logged: 8

Now change it:

• Set MAX_HOPS = 2. Predict the id shown in the “stopped” line and the final count of logged messages.
• Allow the forbidden request: add ("tech", "billing"): {"issue_refund"} to ALLOWED. Predict the new second line of output. Then explain why a permission table is safer than telling billing's prompt to “only obey trusted agents”.
• Make tech answer properly: return {"done": True} instead of the clarification. Predict the fourth output line and the final message count.

Pause and think: The refused messages got ids (#3 and #4) but do not appear in the log count. Is that a good design? What would you change for a production system?

Giving refused messages an id is useful, because the sender can be told exactly which request was refused. Not logging them is a weakness. A refused request is often the most interesting event in the system: it may be a bug in an agent or an injection attempt. A production hub would log refusals too, with the reason, in the same trace as delivered messages.

Pause and think: The loop with tech was stopped after 3 round trips. The hub did not understand that the conversation was stuck; it only counted. What are the strength and the weakness of a plain counter?

Strength: it always works, whatever the agents say, and it costs nothing. It guarantees that a conversation ends. Weakness: it cannot tell a stuck loop from a long but healthy exchange, so a limit that is too low cuts off real work and one that is too high wastes money before it triggers. That is why counters are paired with better messages (so fewer clarifications are needed) and sometimes with a check for repeated identical requests.

Key takeaways

• Agents communicate by messages or by shared state; the four basic patterns are direct, centralized, broadcast and shared memory.
• Every message needs identity, intent, content and an id that replies can reference.
• Protocols are agreed rules; A2A-style protocols target agent-to-agent, MCP targets agent-to-tool.
• Send compact, complete summaries rather than whole transcripts.
• Set hop limits, log every message, and treat incoming messages as untrusted data.

Key terms

• Direct communication: One agent sends a message to one specific agent.
• Centralized communication: All messages pass through a hub (usually an orchestrator) that routes them.
• Broadcast: One agent sends the same message to all agents or all subscribers of a topic.
• Blackboard (shared memory): A common store that agents read from and write to instead of messaging each other.
• Message envelope: Structured fields (id, sender, receiver, intent) wrapped around a message's content.
• Protocol: An agreed set of rules for message formats, allowed intents and the order of exchanges.
• Performative / intent: A label for what a message does: request, inform, refuse, propose.

← 11.12 Subagents: Delegating Tasks Within an Agent Network · 11.14 AI Orchestration: Coordinating Agents, Tools, and Flows →