Agent Messaging

A crash course on Agent Messaging

Agent Messaging is an open standard for agents that talk in messages. An agent sends a signed message to another agent's inbox, where it waits if that agent is offline. It publishes events that reach every agent subscribed to them. And it can see which agents are online right now. This is the whole standard in ten minutes.

The idea in one picture

• The sender signs. Every message travels in an envelope the sending agent signs with its own key.
• The inbox waits. If the receiver is offline, its inbox holds the message until it comes back.
• The receiver checks. When the receiver collects the message, it checks the signature itself, so it never has to trust the connection or the server that carried it.

Three ways agents talk

Those six primitives are the only message types on the wire. Tasks, streaming, feeds, heartbeats and everything else in the standard are built from them.

The envelope

Every message is an envelope with a wire version, a type, a sender, a receiver, a payload and a signature. The signature is Ed25519, made with the sending agent's own key, and the receiver checks it on arrival. Every envelope also carries trace context, so one piece of work can be followed from agent to agent.

Messages that wait

Messages are asynchronous. A sender does not hold a connection open while it waits. The answer comes back as a message to the sender's own inbox, matched to the request by its id. If the receiver is offline, the message waits: the receiver's node keeps its inbox, and while the node itself is away the network holds a redelivery buffer for up to seven days or 25 MB.

A sender learns what happened from what comes back:

• Accepted. A live handler admitted the request and is about to run it.
• Queued. A node is holding the message in an inbox, and the reply will arrive later.
• Silence. The receiver's node is offline and the network may be holding the message, so a sender treats silence from a registered agent as possibly queued.

Presence

Each node sends a signed heartbeat, every 30 seconds by default, and one heartbeat covers every agent it runs. An agent is online, busy, degraded or offline, and two missed heartbeats mark the node offline. Presence is kept apart from the registry on purpose: a laptop that sleeps goes offline in presence and comes back when it wakes, and its registration stays as it was. Discovery joins the two, so an agent can ask for agents that can do a job and are online now.

Trust between agents that have never met

• Agents hold their own keys. An agent's public key is its id, its node vouches for it, and every message carries the agent's own signature.
• Owners decide who gets in. Each owner allows, holds or blocks each sender. A newcomer may read an agent's public description and may knock, and a knock carries no message.
• Receivers check every message. They reject duplicates, refuse messages outside a freshness window or addressed to someone else, cap the size of what they accept, and fence a stranger's text so the agent reads it as the stranger's own words.
• There is a kill switch. An owner or operator can pause or terminate one agent, everything an account holds, or the whole network. Connections are revoked live, and every press is recorded.

Identity: the default, or your own

By default, an agent makes its own key pair where it runs, enrolls once with a one-time key from the operator, and signs everything it sends. A company that already gives its agents identities with OAuth, SPIFFE or a cloud's agent platform can use them instead. A native agent uses that identity to enroll and then signs with its own key. A bridged agent keeps its identity in charge and reaches the network through a bridge that signs for it. Either way, every message still proves its own sender.

Work that takes time

• Tasks. Work that takes time becomes a task: submitted, working, needing input or authorization, then completed, failed, canceled or rejected. A task can stream its progress and be canceled.
• Files. A file too large for a message goes into the artifact store, and the message carries a reference to it. The store checks each file's digest.
• Rooms. A room is a shared conversation among several agents, with a durable record and a drive for files.

Any reliable messaging system can carry it

The standard is written separately from the messaging system underneath it. A binding maps it onto real infrastructure, and the specification says what any binding must provide, starting with subject addressing with wildcards and ordered, at-least-once delivery. There are bindings for NATS and for RabbitMQ today. In our measurements the two were within a few milliseconds of each other, and a message reached the receiving agent's inbox in about 60 milliseconds: see How much latency does asynchronous agent messaging add?

What a server must implement

The specification defines two profiles. Every server implements the core profile: the envelope and signing, the key chain and live revocation, stopping agents, the registry, discovery and presence, requests, responses and tasks, events and feeds, files, rooms, admission and the knock, and the binding. The full specification adds what a deployment decides for itself, such as the tenancy model, verified names and metering. A conformance suite checks a running server against either profile.

Where A2A fits

Agents that speak A2A reach an Agent Messaging network through a gateway, which turns A2A calls into messages on the way in and back into A2A on the way out. That crossing costs a few milliseconds. Between your own agents, messages are the better choice: see The case for connecting your own agents over A2A is close to zero.

Where to start

• Read the specification at agentmessaging.ai.
• Check a server with the conformance suite.
• Run your own with the open-source Agent Messaging Server, on NATS or RabbitMQ: the Run it guide has two agents talking in five minutes.