The Agent Message Bus Protocol (AMBP) defines a durable communication protocol for agentic systems that need to coordinate work, exchange status, ask questions, share observations, publish receipts, and replay coordination history without relying on hidden chat state or implementation-specific message queues.
AMBP is concerned with structured internal communication between agents, workflows, tools, runtimes, and operator surfaces. It defines message envelopes, topics, streams, delivery expectations, acknowledgement semantics, replay cursors, provenance, scope, authority, and governance boundaries.
AMBP does not define agent reasoning, tool calling, memory retrieval, or durable capability formation. It defines how agentic systems communicate through a bus-like substrate in a way that remains inspectable, replayable, and safe to govern.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in AMBP documents are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals.
Agentic systems frequently need more than prompt context and tool calls. Agents need a durable way to:
- announce presence
- divide work
- ask and answer questions
- avoid duplicate execution
- publish progress
- share intermediate findings
- request approval
- acknowledge instructions
- hand off unfinished work
- replay what happened after interruption
Without a shared message protocol, each host, app, or agent framework invents an ad hoc channel. Those channels are hard to inspect, difficult to replay, unsafe to authorize, and brittle when multiple agents or runtimes participate.
AMBP defines a standard coordination layer for agent communication.
AMBP is not a queue product, event store, agent framework, prompt format, or database. It is a protocol for durable, scoped, auditable agent messages that can be implemented over WebSocket, HTTP, files, databases, streams, queues, MCP, or other transports.
AMBP defines communication between the following roles:
- Agent Identity: a stable identity for an agent, service, workflow, tool, or runtime across sessions.
- Publisher: an agent, tool, workflow, service, user, or runtime that appends a message to the bus.
- Subscriber: an agent, tool, workflow, service, user, or runtime that reads messages from the bus.
- Bus: the system responsible for accepting, ordering, retaining, filtering, replaying, and delivering messages.
- Topic: a named channel with declared purpose, schema, retention, and authorization policy.
- Stream: an ordered message sequence within a scope. A stream may contain one topic or multiple topics depending on implementation.
- Message: an immutable envelope plus payload appended to the bus.
- Receipt: a durable acknowledgement, rejection, observation, or delivery marker related to another message.
- Cursor: an opaque position used by a Subscriber to resume reading.
- Authority: the person, organization, policy boundary, or system responsible for trust decisions within a scope.
A single implementation may combine multiple roles, but AMBP treats these responsibilities as distinct concepts.
An AMBP Message is the core primitive of the protocol.
Each Message MUST have a stable identifier, protocol version, topic, type, scope, authority, publisher, timestamp, payload, and provenance metadata.
A Message SHOULD preserve causality when it is related to prior work. Causality may include parent message identifiers, correlation identifiers, run identifiers, task identifiers, session identifiers, or ACFS record identifiers.
Messages are immutable once accepted by the Bus. Corrections, retractions, supersession, or status changes MUST be represented by later messages or receipts rather than mutating prior messages.
Topics define what a message is for. A topic SHOULD declare:
- stable topic name
- purpose
- allowed message types
- payload schema or schema reference
- publishers allowed to write
- subscribers allowed to read
- retention policy
- replay policy
- sensitivity classification
- whether messages may influence agent behavior
Streams define ordered message replay. A Bus MUST expose a stable ordering within each stream. Implementations MAY provide global ordering, but Consumers MUST NOT assume global ordering unless the implementation declares it.
AMBP is designed for interruption-prone agent work.
A Subscriber SHOULD be able to resume from a Cursor and receive messages that were appended after that Cursor, subject to retention and authorization policy.
AMBP does not require exactly-once delivery. Implementations SHOULD support at-least-once delivery with idempotent message identifiers and durable receipts. Subscribers MUST be prepared to see duplicate deliveries and SHOULD deduplicate by message identifier.
AMBP is not a replacement for the Agent Capability Formation Standard (ACFS).
ACFS defines how durable agent-contributed records become future capability. AMBP defines how agents communicate while work is happening.
The boundary is:
AMBP messages coordinate work.
ACFS records govern durable capability.
An AMBP message MAY contribute to an ACFS Capability Record after review or policy evaluation. For example:
- a repeated handoff pattern MAY become an ACFS procedure
- a useful observation MAY become an ACFS observation
- a completed run MAY become ACFS evidence or run result
- a failed coordination pattern MAY support an ACFS correction
AMBP messages MUST NOT bypass ACFS lifecycle, authority, scope, review, retrieval, or revocation rules.
AMBP is not a replacement for MCP.
MCP defines how applications expose tools, resources, prompts, and related capabilities to AI systems. AMBP defines a durable communication contract for agents and runtimes that need bus-like coordination.
An implementation MAY expose AMBP through MCP tools or resources, but AMBP message ordering, scope, authority, retention, replay, and authorization rules remain binding regardless of transport.
Agent communication is a trust boundary.
AMBP implementations MUST treat message publishing, subscription, replay, receipt writing, topic creation, retention changes, and authority changes as security-sensitive operations.
Messages may influence what agents believe, what work they claim, which tools they request, what outputs they trust, or when they ask for human approval.
Implementations SHOULD enforce scope, preserve provenance, classify sensitivity, apply least privilege, support redaction policy, and make replay/audit behavior explicit.
AMBP SHOULD make agent coordination visible. It SHOULD NOT become an opaque covert channel that lets agents share authority, data, or instructions outside declared policy.
AMBP does not require a specific runtime, transport, storage engine, or agent framework.
An AMBP-compatible implementation preserves the standard requirements for message envelopes, immutable append, topic policy, scope, authority, provenance, delivery, receipts, replay, retention, and authorization.
Implementations MAY use WebSocket, HTTP, files, databases, event stores, queues, streams, append-only logs, object storage, or other persistence mechanisms.
This repository includes additional specifications for message envelopes, topics, streams, delivery, replay, sessions, presence, ACFS binding, transport bindings, architecture, conformance, versioning, and trust and safety.
Implementations SHOULD use the JSON Schema and examples in this repository when validating basic AMBP message compatibility.
specifications/message-envelope.md: minimal message shape and field rulesspecifications/identity.md: idempotent agent identity and session rulesspecifications/topics-and-streams.md: topic declarations and ordering rulesspecifications/delivery-and-replay.md: delivery, cursors, receipts, and replayspecifications/sessions-and-presence.md: optional agent presence and sessionsspecifications/acfs-binding.md: relationship to ACFS records and capability formationspecifications/transport-bindings.md: WebSocket, HTTP, file, MCP, and stream mappingsspecifications/architecture.md: component boundaries and responsibilitiesspecifications/conformance.md: compatibility profilesspecifications/versioning-and-extensions.md: extension and versioning rulessecurity/trust-and-safety.md: trust boundary, privacy, retention, and safety guidanceschemas/message.schema.json: JSON Schema for basic message validationschemas/topic.schema.json: JSON Schema for topic declarationsexamples/: valid and invalid examples