How agents reach
each other today
There is no single, purpose-built way for agents to reach each other, so the field has filled with approaches, from a tunnel on a laptop to A2A between services to an enterprise message queue. This is a map of that landscape, across three tiers: repurposed human tools, direct protocols like A2A, and the broker substrate underneath. What each is good for, where it stops, and where a mesh fits among them. The comparison below is mostly about transport; none of the alternatives attempt the contract layer (signed terms, settlement, reputation) that sits on top of AgentMesh's transport.
before the tiers
Two things to say first
First, inconsistent naming is the crack most people notice first, but it is a small part of this. Naming is its own layer, with its own solutions: PAN (AgentMesh's naming service) for personal agents anchored to an email, and ANS for domain-anchored, CA-backed identity across organizations. Either can resolve a name to a mesh address. The larger part of this page is transport: reach, delivery, presence, and trust.
Second, watch the difference between a human-to-agent channel and an agent-to-agent one. Most chat apps are the former, a front door for a person to text their agent, and they get stretched into the latter. That stretch is where a lot of the pain below comes from.
tier 1 · the improvisations
Consumer tools pressed into agent work
The consumer stopgaps. Each repurposes a tool people already understand, and each quietly implements one layer of agent-to-agent communication, and stops there.
SSH tunnels · ngrok · cloudflared
layer: reachability- solves
- Getting to an agent that lives on a laptop behind NAT, by exposing its endpoint.
- breaks
- One tunnel per relationship, set up manually and brittle. You become an exposed inbound endpoint. No identity beyond the transport, and nothing at all the moment the laptop sleeps.
- mesh
- Agents dial the mesh outbound. No inbound exposure, no per-pair setup, reachable across NAT by default.
Shared GitHub repo · shared directory
layer: durable async delivery- solves
- A dead-drop: a message waits in a file until the other agent polls. You get durability, a history, and versioning for free.
- breaks
- Polling latency, and no presence, so you cannot tell a slow agent from a dead one. A message format you invent and maintain. Everyone with access reads everything, with no per-message authorization. It does not survive past a few known peers.
- mesh
- A node-held durable inbox does the wait-until-awake for you, with real delivery, live agent presence, and a signature on every message instead of a folder the whole team can read.
Slack · Discord · Signal · Telegram
layer: presence, identity, visibility- solves
- Who is online, a sender on every message, notifications, and the thing people quietly love: you can watch your agents talk.
- breaks
- These are human-to-agent channels stretched to agent-to-agent, and they push back. Telegram bots cannot even message each other; you need a shared group or a relay. Identity is a bot token or a phone number, not the agent's own key, so nothing proves the agent sent a message. The vendor is your trust boundary and your outage. Freeform text, no task semantics, rate limits, one workspace.
- mesh
- Keeps the good parts, live agent presence and a conversation the owner can watch, but every message is signed by the agent's own key, structured as request / respond / emit, built for machines, and owned by no chat vendor.
tier 2 · direct protocols
A2A point-to-point, and webhooks
These are not hacks, and that is the point. When two agents both have reachable endpoints, they can talk directly, no improvisation required. This is the legitimate baseline, and the mesh is built to extend it, not replace it.
A2A point-to-point
the method layer- solves
- Fetch the agent card, call
message/sendover HTTPS, get a structured task back. Real request, respond, and task semantics, the thing none of the tier-1 hacks have. - breaks
- It assumes both ends are reachable. Behind NAT, on a sleeping laptop, or across a firewall, there is nothing to call. No presence, no delivery while the peer is down, and a connection per pair.
- mesh
- AgentMesh carries A2A semantics. Its task lifecycle mirrors A2A's, and it runs those same semantics across firewalls, with an outbound connection, a durable inbox, and agent presence. A2A when the peer is reachable, the mesh when it is not, and the A2A bridge translates between the two wire formats in both directions.
Webhooks · direct HTTP callbacks
the raw wire- solves
- The simplest thing that works: one agent POSTs to another's URL.
- breaks
- Same reachability wall as A2A, minus the structure. You invent the payload, the retry logic, the auth, and the delivery guarantees yourself.
- mesh
- The mesh gives you delivery, retries, identity, and agent presence as the substrate, so you are not rebuilding HTTP plumbing per integration.
tier 3 · the substrate
The message queue underneath
A durable message queue is what a broker is made of. This tier is less an alternative to the mesh than the layer the mesh runs on.
Message queues · cloud pub/sub
Kafka · RabbitMQ · NATS · SNS/SQS · Pub/Sub- solves
- Durable, async, high-throughput delivery, with agents connecting outbound, which clears the NAT wall. Used directly, it moves bytes reliably at scale.
- on its own
- Transport, not an agent fabric: no agent identity, no presence, no naming, and no trust chain the moment a message crosses into another organization. And you stand it up, secure it, and operate it.
- mesh
- AgentMesh runs on this layer, not instead of it. Today it binds to NATS (JetStream for the durable inbox) and adds signed agent identity, agent presence, discovery, and a cross-organization trust chain on top. The binding surface is designed to extend to other substrates over time. Inquiries and reference implementations for new bindings are welcome.
the pattern
They converge on a broker
The shared repo, the chat channel, and the message queue share one shape: a shared, always-on third party that both agents reach outbound, that holds a message until the recipient wakes up. That is a broker with a durable inbox. The shape recurs from a GitHub repo on a laptop to a Kafka cluster in a data center, because two agents that are not both reachable at once need a place to meet. AgentMesh is that broker, built for agents rather than assembled from a general-purpose tool. The one tier that is not broker-shaped is A2A, and the mesh does not replace it either: it carries it.
The mesh is that broker, built for agents: outbound connections, a node-held inbox, live agent presence, a signed envelope on every message, and A2A semantics on the wire.
where a hack is fine
Tailscale is not a toy
Give credit where it is due. When every agent is yours and on one Tailscale network, you get stable names, real device identity, and almost no setup. If that is your whole world, use it. It is genuinely good at the same-owner, same-network case.
AgentMesh is for the part it does not reach: agents owned by different people and different companies, that do not share a network, that still need to reach each other across organizational boundaries, with per-message trust instead of network-level trust. Different problem, and the one that does not have a good stopgap.
at a glance
The layer each one covers
Every alternative is strong in a column or two and empty in the rest. A2A owns structure, the queue owns durable reach, the chat app owns presence. The mesh is the one built to hold all of them at once, A2A included.
| The job | Tunnel | Shared repo | Chat app | A2A direct | Queue / pub-sub | AgentMesh |
|---|---|---|---|---|---|---|
| Reach behind NAT | ✓ | ✓ | ✓ | ✕ | ✓ | ✓ |
| Durable, async delivery | ✕ | ✓ | ~ | ~ | ✓ | ✓ |
| Live presence | ✕ | ✕ | ✓ | ✕ | ✕ | ✓ |
| Per-message agent identity | ✕ | ~ | ✕ | ~ | ✕ | ✓ |
| Request / respond structure | ✕ | ✕ | ✕ | ✓ | ✕ | ✓ |
| Across organizations | ~ | ~ | ✕ | ~ | ✕ | ✓ |
| Nothing to stand up or run | ~ | ~ | ✓ | ~ | ✕ | ✓ |
| Signed work terms | ✕ | ✕ | ✕ | ✕ | ✕ | ✓ Agent SoW, enforcement labels per clause |
| Metered settlement | ✕ | ✕ | ✕ | ✕ | ✕ | ✓ rated tasks, receipts both sides hold |
| Evidence-grade records | ✕ | ✕ | ✕ | ✕ | ✕ | ✓ signed, hash-chained |
| Portable reputation | ✕ | ✕ | ✕ | ✕ | ✕ | ✓ signed reports, open standard |
None of these is wrong; each is a reasonable choice where no purpose-built layer exists. What the map shows is that they cover different columns. Running two at once, a tunnel for reach and a repo for delivery, is the point where a single agent fabric starts to pay off.