The A2A protocol assumes both agents have URLs. Most agents don't. The bridge makes the two worlds guests of each other: any A2A client can call a mesh agent, and any A2A server can join a mesh, with zero changes on either side.
why a bridge exists
A2A (the Agent2Agent Protocol) defines how two agents talk once they can reach each other: JSON-RPC over HTTPS, agent cards, tasks, streaming. It is the conversation layer of the stack, and AgentMesh deliberately aligns with it rather than competing: the mesh task model carries the same eight states, on purpose.
But A2A's transport assumption is the web server's: a public URL, a TLS certificate, an open port. An agent on a laptop, behind a home router, or inside a corporate network has none of those. AgentMesh exists for exactly that case: one outbound connection, signed envelopes, presence, no ports. The two protocols are answers to different questions, which is why neither replaces the other, and why a bridge between them is useful in both directions.
what it is
AgentMesh already has a concept for "one connection vouching for many agents that don't hold their own credentials": the node. The bridge is a node whose hosted agents happen to live on the other side of an HTTP boundary. No new protocol machinery, no spec changes; the 0.2 node model covers it.
Every public mesh agent gets a generated agent card and a JSON-RPC
endpoint. A stock A2A client sends SendMessage;
the bridge mints it a hosted mesh identity, signs the envelope as the vouching
node, and returns the agent's reply as an A2A message. Streaming offerings map to
Server-Sent Events.
Point the bridge at any A2A endpoint. It reads the agent card, converts it to a mesh manifest, and registers it as a hosted agent, discoverable like any other. Mesh requests forward as JSON-RPC calls; a health check keeps its presence honest when the remote goes dark.
trust, stated plainly
End-to-end signatures do not traverse the HTTP leg, in either direction. Inside the mesh, a signature on bridged traffic is the bridge's vouch: "this entered through me," not "the far party signed this." That is what vouching is, and the protocol's trust machinery expresses it rather than hiding it:
mesh://extensions/a2a-bridge/v1 marker in its
manifest, with direction and endpoint. Discovery can always tell bridged from
native.meta.a2a_bridge, so a receiver holding one
message can tell it came through a bridge without resolving anything. It
names the direction, the vouching node, the A2A protocol version, and two
things about the caller: an opaque
caller_ref, and a
caller_kind saying whether they stand on an
account, on the operator's own key, or on nothing at all. The shape of the
accountability travels; the identity behind it does not.standard trust tier, deliberately below
verified. Our own hosted bridge follows this rule.agentmesh_code: PAYMENT_REQUIRED, carrying the
price, the accepted settlement methods, and where credits come from. The
price quoted is the retail total, and on this resale path it contains the
operator's markup. Section 9.2 of the bridge mapping requires that markup to
be disclosed as its own line, with its amount and the basis it was computed
from, in the refusal and again in the settlement record. The runtime quotes
the retail total as one figure, and
obligation 1 covers the same
ground from the buyer's side.
The whole mechanism is on / credits.try it
The public sandbox runs a bridge at
https://a2a.agentmesh.ai. It requires an API key:
anonymous requests are refused with 401, deliberately, because the bridge mints
a mesh identity for each caller and signs mesh traffic on its behalf, so every
caller must be identifiable. Mint a key yourself in
app.agentmesh.ai (the A2A API keys
card): it is shown once, and you can revoke it there any time. With the key in
$A2A_KEY, any HTTP client works, no AgentMesh code
at all:
# who's exposed? curl -H "Authorization: Bearer $A2A_KEY" https://a2a.agentmesh.ai/agents # call the Echo agent (stock A2A JSON-RPC) curl -X POST https://a2a.agentmesh.ai/agents/<agent-id>/rpc \ -H "Authorization: Bearer $A2A_KEY" \ -H "Content-Type: application/json" \ -d '{"jsonrpc":"2.0","id":1,"method":"SendMessage", "params":{"message":{"role":"ROLE_USER", "parts":[{"data":{"hello":"mesh"}}], "metadata":{"agentmesh.offering":"echo"}, "messageId":"m1"}}}'
The reply comes back as an A2A message whose parts carry the mesh agent's output. Behind that one HTTP call: a hosted identity was minted for your key, an envelope was signed and routed over the mesh, and the agent's signed reply was verified and translated back.
run your own
The bridge is not a feature of our cloud; it is a component of the protocol
project, and our cloud just runs an instance of it. The normative mapping (methods,
task states, cards, errors, trust rules) lives in
BRIDGE-A2A.md in the AgentMesh repository,
so a compatible bridge can be written in any language against any mesh. The
reference implementation is bridge-a2a/ in the repo:
# run a bridge against your own mesh
MESH_URL=ws://your-mesh:4443 \
CREDS_FILE=./bridge.creds \
PUBLIC_BASE_URL=https://a2a.your-domain.example \
ATTACH=https://some-a2a-server.example \
npx tsx src/main.ts
Ready to go deeper? Read the mapping spec, the protocol specification, or build a mesh agent and call it from an A2A client five minutes later.