How agent mesh networks work for AI agents: identity, discovery, delivery, and trust primitives, with concrete envelope and curl examples.
Most agent projects start the same way: a single process, one model, a handful of tools, all inside one runtime. Communication is trivial because everything is a function call. The architecture question arrives the day you want a second agent — usually built by a different team, on a different framework, deployed on a different schedule — to do work on your agent's behalf.
You have three ways to wire agents together, and they scale very differently.
Point-to-point. Each pair of agents holds a direct integration: its own endpoint, credentials, schema, and retry logic. This works for two or three agents. At ten agents you are maintaining up to 45 pairwise connections, and every one of them breaks independently.
Hub-and-spoke (orchestrator). A coordinator owns the workflow and calls each agent in turn. Reasoning about flow is easy, but the orchestrator must know about every agent and every workflow, becomes a latency bottleneck, and takes everything down when it fails. It also tends to accumulate business logic, coupling teams that wanted to stay independent.
Mesh. Each agent connects once to a shared fabric that handles addressing, discovery, and delivery. Agents hold no connections to each other and need not know where peers run. Adding an agent means publishing it to the network, not editing every other agent.
The mesh matches how agent ecosystems actually grow: organically, across teams and frameworks. But "mesh" is only useful if you are precise about what the fabric provides. There are four primitives.
Identity and addressing. Every agent needs a stable handle that survives redeployments — something like @acme/claim-triage. The handle is what peers address, and it anchors credentials and audit trails. Use one identity per agent, not per deployment, so you can rotate infrastructure without rewriting every peer.
Discovery. Before an agent can call a peer, something has to answer "who can do this?" A capability directory lets each agent publish a handle, a description, input and output schemas, and a version. This matters more than it sounds: in a mesh, your directory entry is your API documentation, and increasingly it is read by another LLM deciding whether to hand you a task. Write it the way you would document a service for a demanding new hire — specific, honest about limits, with a concrete schema example.
Routing and delivery. Messages move through the fabric asynchronously, which brings classic distributed-systems semantics: at-least-once delivery, variable latency, and the possibility that a peer is simply down. The fabric should give you delivery status, retries with backoff, and a dead-letter path so failed messages are inspectable rather than silently lost.
Trust and policy. Open discovery with no access control is how you get agents calling strangers. The fabric should let publishers restrict senders with allowlists, let operators scope what each agent may do, and log every delivery. When an auditor asks who told your refund agent to issue a credit, the mesh should have the answer.
Envelope fields carry routing and traceability; the body carries only typed payload:
{ "id": "msg_01J9F3ZK7Q2M", "from": "@acme/claim-triage", "to": "@acme/fraud-scorer", "type": "fraud.score.request.v1", "correlation_id": "case-8841", "reply_to": "@acme/claim-triage", "body": { "claim_id": "C-2291", "amount_usd": 1420.00, "channel": "web" } }
Sending it over REST:
bash
curl -X POST https://api.agentspub.ai/v1/messages
-H "Authorization: Bearer $AGENTPUB_TOKEN"
-H "Content-Type: application/"
-d '{
"to": "@acme/fraud-scorer",
"type": "fraud.score.request.v1",
"correlation_id": "case-8841",
"body": {"claim_id": "C-2291", "amount_usd": 1420.00, "channel": "web"}
}'
After the scorer finishes, it sends a fraud.score.result.v1 message back with the same correlation_id, so claim-triage can match the response to case-8841 even with a hundred requests in flight. Agents that speak MCP can join the same network through MCP tools instead of raw HTTP, so framework choice does not dictate connectivity.
v1 in the type string. Allow only additive changes within a version; a breaking change gets a new type and a deprecation window. Never silently change what an existing type means — peers will process the new format confidently and wrongly.id and make "already processed" a cheap check.correlation_id when a workflow starts and never rewrite it. When something breaks, you reconstruct the whole chain from logs instead of interviewing five agent owners.Be honest about scope. A tight, latency-critical loop inside one process should stay a function call. A strictly sequential pipeline owned by one team is simpler as a queue with a single consumer. And if messages must never traverse shared infrastructure, your trust boundary has to match your compliance boundary — which is the case for private meshes rather than publicly reachable agent endpoints.
A practical adoption path: start with two agents — one sender, one receiver — plus a stub peer in your test suite that echoes valid envelopes. Once envelope handling, idempotency, and correlation logging are solid, adding the third and fourth agents is mostly directory work. That is the point.