Agent-to-Agent Messaging over AMQP and RabbitMQ

A2A is an open protocol for communication between agents that cannot see inside each other, because they come from different teams, frameworks or vendors. It was originally developed by Google and donated to the Linux Foundation, and the current release of the specification is 1.0.0. The project describes it as complementary to MCP: MCP equips one agent with the tools and data it needs, and A2A lets that agent work with other agents.

An Agent Card is a JSON document describing an agent's identity, skills, service endpoints and authentication requirements. The standard place to publish it is /.well-known/agent-card.json; clients can also find cards through a registry or by direct configuration. Cards may be signed with JSON Web Signature over an RFC 8785 canonical form.

Work is a Task, with an ID, a context ID that groups related interactions, a status, artifacts and history. Its states include submitted, working, completed, failed, canceled and rejected, plus two that matter for agents: input-required and auth-required, which is how a task pauses for a person or a credential. A Message carries a message ID, a role and one or more Parts (text, file or structured data), and results come back as Artifacts built from Parts. The specification defines eleven operations: sending a message, sending one with streamed updates, getting, listing, canceling and subscribing to tasks, four operations for push notification configuration, and fetching the extended Agent Card.

A2A 1.0.0 specifies three protocol bindings: JSON-RPC 2.0 over HTTP(S), gRPC, and HTTP+JSON/REST. On the HTTP bindings, streaming uses Server-Sent Events, and push notifications are HTTP POST requests to a webhook the client supplies. Production deployments must use encrypted transport.

The specification has no AMQP or message broker binding. It does have a section on custom bindings: implementers may create them, but a custom binding must support all the core operations, keep data structures functionally equivalent to the A2A data model, map every A2A error type, implement the authentication schemes the Agent Card declares, and be declared in the Agent Card's supportedInterfaces with a URI that identifies it. If it streams, it should document event ordering, reconnection and how a stream ends. Everything below is a pattern for building that on RabbitMQ. Until it is written up as a binding that meets those rules, run it as an internal transport behind agents that also expose a standard binding to outside callers.

Agent-to-agent calls look like service calls but behave like jobs: they run for minutes, pause for input and fail in ways worth retrying. A broker fits that shape. Requests are asynchronous, so a caller does not hold a connection open through a long task. They are durable on quorum queues, so a task survives the receiving agent restarting. Discovery becomes routing: a client publishes to a skill, and whichever agent has bound that skill receives it, without the client knowing its address. Results return to a reply queue the client already reads, so no client has to expose a webhook for push notifications. And every request and reply can be copied to a stream, giving an audit trail of which agent asked what, and what came back.

One workable mapping, kept close to the JSON-RPC binding so the payloads stay standard A2A:

Use a durable quorum reply queue per client for anything long-running. Direct reply-to (amq.rabbitmq.reply-to) is lighter, but its replies are not stored and are lost if the requester disconnects, which suits quick lookups and not tasks that run for minutes. Keep ordering simple: RabbitMQ preserves order for messages published on one channel through one exchange and one queue to one consumer, so an agent that publishes a task's updates on one channel, into a reply queue with one consumer, delivers them in the order it sent them.

RabbitMQ has supported AMQP 1.0 natively since 4.0. Its address format v2 lets a client send to /exchanges/a2a.requests/billing.refund-agent or straight to /queues/<queue>, which maps directly onto the topology above and suits agents written in languages with a good AMQP 1.0 client. One property matters for agents in particular: RabbitMQ keeps the AMQP 1.0 bare message immutable, so a sender can sign the body, properties and application properties, and the receiver can verify the signature after the message has passed through the broker.

Declare a stream and bind it with # to both a2a.requests and a2a.replies, and every A2A request and update is kept in order beside the queues the agents consume. Set retention to match your audit requirement with max-age or max-length-bytes, and replay a disputed task by attaching at a timestamp. Because a stream is read without removing messages, compliance tooling, evaluation jobs and debugging sessions can all read the same history independently.

• One RabbitMQ user per agent. Shared credentials make the audit trail meaningless. Authenticate with passwords, X.509 client certificates through the EXTERNAL mechanism, or the OAuth 2.0 backend, and never use guest, which RabbitMQ only accepts over loopback anyway.
• A virtual host per trust boundary. Agents from different teams, tenants or vendors belong in separate virtual hosts, and permissions are granted per virtual host.
• Narrow permissions. Give each user configure, write and read patterns that cover only its own queues and the exchanges it publishes to. Topic permissions add a routing-key check when publishing to a topic exchange and on AMQP 0-9-1 bindings, and patterns can use {username}, so an agent can be limited to the keys for its own skills.
• Validated sender identity. When a publisher sets the user_id property, RabbitMQ requires it to match the connection's user, so a receiving agent can trust who sent a request. Do not give agents the impersonator tag.
• TLS on every connection. Use TLS on port 5671 with verify_peer and fail_if_no_peer_cert for mutual TLS. The A2A specification requires encrypted transport in production, and a broker hop should not be the exception.
• Message signing. TLS protects the hop, not the message. Sign request and response bodies with each agent's key, as JWS for example, and verify before acting; on AMQP 1.0, RabbitMQ leaves the signed sections untouched. Sign Agent Cards with JWS as the A2A specification describes.

Solace Agent Mesh is an open-source (Apache 2.0) framework for multi-agent systems, built on Google's Agent Development Kit and running on the Solace event broker. It carries A2A as JSON-RPC 2.0 over broker topics, with request topics shaped like <namespace>/a2a/v1/agent/request/<agentName>. Agents publish their cards on discovery topics at startup, replies are routed through a replyTo user property, and each task carries a signed JWT holding the user's identity and scopes. Solace documents that topic layout as Agent Mesh's own wire format.

Kafka-based approaches treat agent messages as events on topics. Confluent's Streaming Agents run on Confluent Cloud for Apache Flink and can call MCP tools and external A2A agents as tools. Where a Kafka platform is already the system of record for events, putting agent traffic on it keeps that history in one place.

On RabbitMQ, the RabbitMQ documentation does not define an A2A binding, so the pattern above is assembled from standard features: topic exchanges, quorum queues, reply-to and streams. The choice between the three usually follows what the estate already runs and whether the traffic is mostly task hand-off, where per-message acknowledgement, delivery limits and priorities help, or mostly event streaming, where retention and replay come first.