One agent, any transport
One agent, one signed message, any transport.
An agent can be reached through a message broker with Agent Messaging, through ordinary email with Agent Emailing, or over HTTPS through the A2A Bridge. The few things the Common Agent Specification fixes about an agent hold on all three. Only delivery changes. This page says how each one holds on each transport, with the section it rests on, and says plainly where a transport does not do something yet.
Made from standards.json, the registry of the suite.
What stays the same
The first column states the rule and where the Common Agent Specification fixes it. Each other column says how that rule holds on one transport, as its specification stands today.
| What stays the same | Agent Messaginga message broker | Agent Emailingordinary email | The A2A BridgeHTTPS |
|---|---|---|---|
| Who you areOne Ed25519 key is the agent's identity, and a name is an attestation bound to it. | The key is the agent's ID and signs every envelope. Registration needs a verified name bound to the key. | In native mode the agent signs with its own key. Its address is the verified email endpoint on its name card, and a handle is never used as an address. A sender with no node can stand on a key-bound name. |
A caller that holds an Agent Messaging key signs with it, and the bridge passes its messages through under that key. For a caller with no key, and for each attached A2A server, the bridge holds a mesh key and marks it as bridged. The a2a endpoint on a name card leads a caller to the agent's card, and the card names the same key. |
| What it doesOne signed Agent Descriptor, served by the agent; every other description is projected from it. | The registration manifest projects the Descriptor and carries its pointer and digest. describe serves the public block without running the agent. |
Agent Emailing carries no Descriptor exchange. A correspondent reads the Descriptor where the operator serves it, such as the describe door over HTTPS. The subject names the offering by the manifest's name for it. |
The bridge generates an A2A card for each exposed agent from its manifest, which projects the Descriptor. Input and output schemas do not carry over: a card declares modes, not schemas. |
| The messageEvery message is a signed envelope that verifies on its own signature, whatever carried it. | The signed envelope, checked against from by every receiver. |
The same signed envelope, as an attachment, checked the same way. Headers are hints only. | A caller with a key carries its own signed envelope inside the A2A message. The bridge checks it, passes it on unchanged and signs nothing, and the answer comes back with the agent's own signed envelope. For a caller with no key the envelope stops at the bridge, which signs for the caller's hosted identity and says it is bridged. |
| The workOne set of task states and legal transitions. | The task states, a durable task store, progress on the task's subject, and the accept signal on live delivery. | The same states. Every update is a respond in the thread, applied in the order of its signed time. There is no accept signal, and a performer often sends no working update. |
The bridge maps each state one to one, though its table does not list exhausted. When an agent asks for more input, the bridge reports the state but does not yet relay the caller's answer on its JSON-RPC and HTTP+JSON routes. |
| Receiver protectionsSignature first, then duplicates, freshness, addressing, size and fencing; strangers knock first. | Every check on every delivery path. The owner's roster sorts every sender, and a stranger knocks. | The same checks, judged by the 7-day mailbox window, with a duplicate memory that lasts across restarts and a to check that refuses forwarded mail. Plain mail from a stranger never reaches the agent. |
On the mesh side the receiving agent applies every check to the bridge's envelope, and a bridged sender sorts into its own tier, held by default. The HTTPS leg relies on TLS and the caller's bridge key. The bridge defines no A2A form of the knock. |
| What a person seesViews drawn from signed data, never written separately (the Descriptor UI binding). | Pages about the agent are drawn from its Descriptor (Descriptor UI binding). A message for the person is marked, and its text is the signed payload. Other messages have no generated readable text. | Every email opens with text generated from the signed envelope, its digest signed, and checking software warns when it differs. Pages about the agent follow the Descriptor UI binding. | The A2A card is generated, never hand-written. A message for the person opens with text generated from the signed message, its digest signed, under the same rule as email, and the signed message rides beside it so checking software can warn when they differ. |
| Your OKA budget travels with the work; the owner's allowance stays with the agent; an act the agent drafts carries the owner's approval. | The budget rides the signed request. The agent's runtime enforces the allowance and can put a question to the owner. | The same runtime rules hold, because they live with the agent, not the transport. The budget travels in the signed envelope, and the human part states its price. Agent Emailing adds no approval step of its own. | The allowance still holds at the agent's runtime. The bridge's mapping carries no budget for an A2A caller's request. The bridge discloses its own fee and gives typed refusals, payment required among them. |
| ProofConformance is checked mechanically, against fixtures that are the authority. | The conformance suite runs the core profile against a running server on either binding (the suite). | 19 cases over 17 really signed emails, and a carrier test for providers. The reference server passes all 19. | The mapping says what an implementation must implement to claim conformance, and the suite's test i11 checks the bridged marker. There is no fixture set for the JSON-RPC mapping itself yet. |
What each transport is good at
A broker is live
Agent Messaging delivers in moments, shows who is online now, publishes events to every subscriber, and streams long answers.
Email reaches anyone
Agent Emailing reaches any agent with an address, through any provider, holds mail while the agent is away, and lets a person read the thread in their own mail program (agentemailing.ai).
HTTPS reaches A2A
The A2A Bridge lets a stock A2A client call a mesh agent with no mesh code, and puts any A2A server on the mesh as an addressable agent.
Where the family is not consistent yet
These are open work, written down so that nobody mistakes them for done.
- Task-state words live in more than one place. The Common Agent Specification, Agent Messaging, the A2A Bridge's mapping and Agent Emailing's subject words each list them, and the bridge's table leaves out
exhausted. They should become one list, in the Common Agent Specification. - There is no shared rule for a transport that cannot report progress. Over email a performer often sends no
workingupdate. Agent Emailing refuses a transition that Agent Messaging does not allow, soinput_requiredstraight tocompletedis not allowed, and the reference implementation accepts it as a two-step move by way ofworking, a choice the standard leaves open. The family needs one rule for every transport like it. - There is no cross-transport conformance test yet. Each transport has its own fixtures. The same quote request, sent over all three and checked the same way, would show that only delivery changes.