A2A is not your internal message bus.

A2A and a durable event bus solve different problems. A2A is an open interoperability protocol for independently operated agent systems. A durable event bus is an internal implementation choice for coordinating work inside one system. Calling both of them “A2A” hides the boundary that matters most: who owns the agent, who authorizes it, and who is responsible for the task reaching a terminal state.

The distinction is not cosmetic. A2A defines how one opaque agent system discovers another system's capabilities, sends a message that may create a task, receives status updates, and collects artifacts. It supports long-running work and multiple protocol bindings, including JSON-RPC, gRPC, and HTTP with JSON. It does not require a queue, prescribe an event log, or expose either agent's internal orchestration.

Draw the boundary first

Use A2A where independently deployed agent systems need to interoperate without sharing their implementation details. That boundary can be between vendors, organizations, security domains, or separately owned services. The client reads an Agent Card, verifies that the remote agent advertises the required capability and interface, authenticates, then exchanges messages, task status, and artifacts.

Inside either system, use the transport that fits its operating model. A single process may need no bus at all. A distributed workflow may use a durable event log or task queue for replay, backpressure, and recovery. Those internal events are not A2A messages merely because agents produced or consumed them.

The same separation applies to MCP. MCP gives an agent access to tools and data. A2A lets one agent system delegate work to another agent system. Neither protocol is a substitute for the orchestrator that owns deadlines, retry budgets, approval policy, and terminal outcomes.

A bounded reference flow

In a system eqlx builds, an A2A exchange is translated at the system boundary rather than copied directly into an internal queue.

1. The requesting agent discovers the remote capability and supported interface from its Agent Card.
2. The boundary authenticates the caller and validates the requested scope before creating an internal workflow run.
3. The orchestrator records a deadline, idempotency key, and finite retry budget, then delegates the specialist work.
4. Internal events capture state changes and receipts. Only protocol-relevant status and artifacts cross the A2A boundary.
5. The protocol-facing task reaches a terminal state such as completed, failed, canceled, or rejected. If policy requires a person, the internal run transfers ownership to a named human queue; it does not start another open-ended agent conversation.

This is deliberately a one-way ownership model. The orchestrator that accepted the run remains responsible for its terminal state even when another agent performs part of the work. Delegation does not delegate accountability.

Retries are policy, not conversation

A retry is a new attempt under the same bounded run, not permission for two agents to ask each other for clarification forever. The orchestrator sets the maximum attempts and per-attempt deadline before work begins. Retries must be safe under an idempotency strategy; an action that may already have succeeded cannot simply be repeated because a response was lost.

When the retry budget is exhausted, the next state is explicit: human review, a deterministic fallback, or failure. The operator sees the original request, attempts made, status history, returned artifacts, and the reason the system stopped. That record is more useful than a diagram full of agents sending messages in a circle.

What the internal event layer owns

If a workflow needs durable internal coordination, its event envelope should make operations visible without pretending to be the A2A wire format. A practical envelope carries a workflow id, event type, schema version, causation id, idempotency key, attempt number, deadline, and a reference to the approved data rather than an unrestricted copy of it.

That layer can provide replay, ordering within a workflow key, backpressure metrics, dead-letter handling, and an append-only audit trail. Those are properties of the chosen event infrastructure and orchestration policy. They are not guarantees supplied by A2A.

Keep the names honest

The public boundary is A2A when it implements the A2A specification. The internal coordination layer is a durable event bus when it actually provides durable event semantics. The orchestrator is the component that owns state and policy. Keeping those names separate makes architecture reviews, security reviews, and incident response substantially clearer.

The result is less magical and more operable: independent agents can interoperate at a standard boundary, while every run inside the system still has an owner, a budget, and an end.