Skip to content
AI360XpertBeta

Agent Communication Protocols

A communication protocol is the envelope every agent message travels in: who sent it, what kind it is, and where the task stands, checked before anyone acts.

A researcher hands work to a writer inside a typed envelope of sender, intent and step 2 of 4, where pointers hold five handoffs to 1600 tokens instead of 7500.
A researcher hands work to a writer inside a typed envelope of sender, intent and step 2 of 4, where pointers hold five handoffs to 1600 tokens instead of 7500.

Why Does This Exist?

One agent can keep its plan in its own prompt. Three agents cannot. The moment a researcher collects facts, a writer turns them into prose, and a checker verifies names, the work has to move between minds that share nothing. The lazy wiring pipes raw text: paste whatever the researcher wrote into the writer's prompt and hope. It works twice. Then the writer must guess who sent the text, what to do with it, which draft it continues, and whether the numbers are checked or merely collected. Nothing was written down, so every agent re-reads the whole thread, repeats questions, and sometimes redoes finished work.

A communication protocol fixes the handoff. Every message travels in the same typed envelope: the sender, the receiver, one intent word from a fixed list, the payload, and the task state with a step counter. The harness checks the envelope before waking the receiver, so a malformed or out-of-range message gets rejected instead of misread. That check-before-wake order is the entire reliability gain.

This page covers the envelope and how receivers read it. Running several agents as one system lives in multi-agent orchestration. The boss-and-workers shape lives in supervisor subagent patterns. What each agent remembers between handoffs lives in agent memory types, and keeping untrusted agents caged lives in agent sandboxing ethics.

Basics first: an intent is one verb from a closed list, such as ASSIGN_TASK or REPORT_ERROR, saying what kind of message this is. A closed list matters because four allowed words can be validated, while free prose can only be guessed at.

Think of It Like This

The office memo

A sticky note on your keyboard says 500. The memo version of the same number reads: To: you. From: Accounting. Subject: Q3 expenses. Action: approve by Friday. Step: 2 of 4. Same number, zero guessing.

The agent envelope maps the same way. From is the sender, To is the receiver, Subject plus Action is the intent, the body is the payload, and the stamp in the corner is the task state. The writer agent reads it the way you read the memo: who it is from, what to do, and where things stand.

Where it stops: a perfect memo cannot fix a vague body, a wrong address, or a forged signature. Clear payloads, correct routing, and sender checks still belong outside the paper.

How It Actually Works

Call one handoff message M. It carries five fields: s, which agent wrote it; r, which agent must act next; k, the intent, one word from the fixed list; p, the payload with the facts or text; and t, the task state holding the step counter plus a pointer to shared memory. The harness parses M, validates it, and only then wakes r.

The envelope

Every M uses one shape, validated against a schema rather than by hope. The intent vocabulary stays small on purpose:

  • ASSIGN_TASK: start this subtask and report back.
  • PROVIDE_INFO: here are facts you asked for, no action needed.
  • REPORT_ERROR: something failed, here is what and where.
  • FINAL_RESULT: the work is done, here is the deliverable.

Four intents route without guessing, and anything outside the list is rejected. Validation runs in order: k must sit on the allowlist, s must be a known sender, and the step inside t must fall within range, such as 2 inside 1 to 4.

How the receiver reads it

When r receives M, the harness runs four steps. First it parses the envelope and confirms the shape. Then it validates intent, sender, and step range. Third, it fetches shared state through the pointer in t instead of rereading the thread. Last, it builds r's prompt from the verified pieces: who sent this, what kind, where the task stands, and the payload. Then r acts and emits the next M with the counter moved forward.

Worked example: a 128 token handoff

Take a realistic payload p of 96 tokens, with header budgets of 8 for s, 8 for r, 6 for k, and 10 for t. Add the header: 8 + 8 + 6 + 10 = 32. Add the payload: 32 + 96 = 128 tokens per handoff, which is what the diagram draws from researcher to writer at step 2 of 4. Five such handoffs cost 5 × 128 = 640 tokens on the wire.

The pointer inside t hides the real saving. Suppose the shared history runs 1500 tokens across 5 handoffs. Forwarding everything every time resends 5 × 1500 = 7500 tokens. Sending a 20 token pointer per handoff plus one 1500 token fetch costs 5 × 20 + 1500 = 1600. The difference is 7500 − 1600 = 5900 tokens saved, close to four fifths of the naive cost. That is the trade stated plainly: about one third of overhead per message plus schema upkeep, in exchange for handoffs that route without rereading history. Skip the protocol for a single agent or a fixed two-step chain. Use it once three or more agents hand work back and forth.

This rests on two assumptions: the shared store answers when asked, and senders report their step honestly. A stale store means competent work on an old step. A lying header routes everyone to the wrong job. Both look like progress until someone checks the log.

Code

The point here is the check, not the arithmetic. This stdlib-only snippet builds the same envelope the diagram draws, rejects bad intents and out-of-range steps, and confirms the wire math:

from dataclasses import dataclass
ALLOWED_INTENTS = {"ASSIGN_TASK", "PROVIDE_INFO", "REPORT_ERROR", "FINAL_RESULT"}
@dataclassclass Envelope:    sender: str    receiver: str    intent: str    payload: str    step: int    steps: int

def build(sender: str, receiver: str, intent: str, payload: str, step: int, steps: int) -> Envelope:    if intent not in ALLOWED_INTENTS:        raise ValueError(f"unknown intent: {intent}")    if not 1 <= step <= steps:        raise ValueError("step out of range")    return Envelope(sender, receiver, intent, payload, step, steps)

msg = build("researcher", "writer", "ASSIGN_TASK", "draft findings", 2, 4)print(f"{msg.sender} -> {msg.receiver} [{msg.intent}] step {msg.step}/{msg.steps}")# -> researcher -> writer [ASSIGN_TASK] step 2/4print(8 + 8 + 6 + 10 + 96)  # -> 128print(5 * 1500)  # -> 7500print(5 * 20 + 1500)  # -> 1600print(7500 - 1600)  # -> 5900

The outputs confirm the worked example: a 128 token handoff, 7500 naive against 1600 with pointers, and 5900 saved. In production the same checks live in the harness, never in the agent, and the agent cannot edit the allowlist.

Watch Out For

Calling plain JSON a protocol

The symptom is integration that works in the demo and rots in the team. Two agents agree on keys this week, a third joins with different keys next week, and every pair needs custom parsing. There is no intent field, so the receiver guesses the action, and one guess eventually ships the wrong thing.

Fix it with the full envelope: sender, receiver, one allowlisted intent, payload, and step state, all schema-checked before the receiver wakes. JSON is the paper. The protocol is what is printed on it.

Blocking the sender while it waits for a reply

The symptom is a team that freezes together. Agent A sends a request and stops everything until B answers, B is busy or offline, and within minutes every agent is waiting on another. Nothing crashes, so the dashboard looks calm while all work halts.

Fix it with async handoffs: send, keep working, handle the reply when it lands, and time out with a fallback agent or a clean error. Never hold a main loop hostage to one reply.

The Quick Version

  • A communication protocol is a typed envelope around each handoff: sender, receiver, intent, payload, and task state.
  • A 32 token header on a 96 token payload totals 128 per message, and five handoffs cost 640 on the wire.
  • A state pointer beats resending history: 1600 tokens with pointers against 7500 without, saving 5900.
  • Four fixed intents let the harness route without guessing and reject anything outside the list.
  • Check the envelope before waking the receiver, then build the prompt from verified pieces only.
  • One agent or a fixed pair needs no protocol. Three or more agents handing work back and forth does.

What to Read Next