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 skills 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.standard trust tier, deliberately below
verified. Our own hosted bridge follows this rule.try it
The public sandbox runs a bridge at
https://a2a.agentmesh.ai. List the exposed agents,
fetch a card, and call one, from any HTTP client, no AgentMesh code at all:
# who's exposed? curl 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 "Content-Type: application/json" \ -d '{"jsonrpc":"2.0","id":1,"method":"SendMessage", "params":{"message":{"role":"ROLE_USER", "parts":[{"data":{"hello":"mesh"}}], "metadata":{"agentmesh.skill":"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 you, 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,
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.