Agent Mesh: Private Network for AI Agents, Tools and Models

What Agent Mesh is

Agent Mesh is an Apache-2.0 project from the google GitHub organisation that builds a private network for AI agents. A small program, agentmesh-node, runs next to an agent or a service and gives it three things: a way to publish tools and models to the network, a way to find and call what other nodes publish, and an identity every other node can verify. Nodes connect directly when they can and through relays when they cannot, so a mesh can span laptops, containers, Kubernetes clusters and phones behind NAT.

The problem it addresses is what happens once agents need to use each other's tools and models across machines and networks. Exposing an MCP server or an inference backend usually means opening ports, managing TLS and writing access rules against IP addresses. Agent Mesh replaces that with named services, identities issued from your own identity provider and a deny-by-default policy. It is aimed at platform teams and developers wiring agents, MCP servers, A2A agents and self-hosted models together across environments. The README notes that it is not an officially supported Google product.

How it works

A mesh has three kinds of component. The control plane, agentmesh-control-plane, is an HTTP service backed by SQLite or PostgreSQL. It admits nodes that present an OpenID Connect token or an operator-minted bootstrap token, issues each node a signed Biscuit credential carrying its peer ID, roles, identity facts and grants, holds the mesh policy and tracks routers. The documentation stresses that it is the only component that has to be trusted and that it is not on the data path: tool calls and model requests never pass through it.

Routers, agentmesh-router, are libp2p peers with stable addresses. They keep the mesh's service directory as a Kademlia DHT and relay traffic for nodes that cannot accept inbound connections. They verify every peer's credential but hold no policy and cannot read relayed traffic or mint credentials, so a compromised router can deny service but not grant access.

Nodes are libp2p peers with their own Ed25519 keys. Towards the mesh, a node publishes the services declared in its configuration file, verifies callers' credentials and evaluates policy before proxying to the local backend. Towards the agent, it exposes a local API on 127.0.0.1:8080 and a Unix socket, including an MCP server whose tools discover and call services across the mesh and an OpenAI-compatible /v1 endpoint that routes model requests to whichever node serves the model.

Services are addressed by type and name, such as mcp://code-reviewer, inference://vllm-eu or a2a://triage. Policy grants are written against these names, never against addresses, so a node can move networks or sit behind NAT without any rule changing.

Key features

• Nothing reachable by default: a node exposes no services until its configuration says so, and no node may call a service the mesh policy has not granted.
• Identity from your IdP: nodes enroll with an OIDC token or a one-time bootstrap token and receive a short-lived, offline-verifiable credential bound to the node's own key.
• Three service contracts: inference for OpenAI-compatible APIs, mcp for MCP servers and a2a for A2A agents. The node only advertises a backend that actually speaks the declared protocol.
• Caller-side checks: a calling node verifies the provider's credential and attested labels before sending any data, and the hosting node can add local conditions beyond what the control plane granted.
• NAT traversal: direct peer-to-peer connections where possible, relays through routers where not.
• All-in-one mode: agentmesh-one runs the control plane, a router and a web console in one process on one port for laptops, Cloud Run and small meshes.
• Several packagings: binaries for Linux, macOS and Windows, container images under ghcr.io/google/, and Helm charts for the control plane stack and for a node beside a service container.
• Web console: a separate program for viewing members, services, bootstrap tokens and editing the mesh policy.

Getting started

The README's quickest path joins a shared developer testnet and gives a local agent the mesh tools:

curl -sL https://google.github.io/agentmesh/install.sh | bash  # agentmesh-node, mcp-client and friends
agentmesh-node join https://bananas.sam-mesh.dev               # one-time login
agentmesh-node run --daemonize                                 # local MCP server on 127.0.0.1:8080
agentmesh-node skill install                                   # teach your agent to use it

The testnet has no uptime promise. To run a mesh of your own, start agentmesh-one locally; it prints a banner with the API URL, the web console address, an admin token and a join token:

agentmesh-one --data-dir ~/agentmesh-one

A member then declares what it serves. The documentation's example puts a small Ollama model on the mesh as an inference service, so that Ollama stays on loopback and is reachable from other machines only through the node, which checks the caller's credential and the policy on every request:

ollama pull gemma3:1b

cat > ~/node-a.yaml <<'EOF'
version: "v1alpha1"
services:
  - type: inference
    name: laptop-llm
    description: "Ollama on my laptop"
    target_url: "http://127.0.0.1:11434"
EOF

agentmesh-one also works as an admin client, reading the admin token from its data directory, from an environment variable or from a file path, never from a flag value:

agentmesh-one token list   --server $URL --data-dir ~/agentmesh-one
agentmesh-one token create --server $URL --data-dir ~/agentmesh-one --description "node c" --max-usages 1

The repository also ships a dev container, and a GitHub Codespaces configuration runs a testnet control plane on a public https URL with make testnet.

Use cases

• Sharing a local model: serve a model from a laptop or GPU box to agents elsewhere, with the OpenAI-compatible endpoint routing requests to whichever member serves it.
• Cross-team MCP tools: publish an internal MCP server once and let authorised agents discover and call it by name, without opening it to the network.
• Agent-to-agent calls: expose A2A agents and let an orchestrator, whether an agent harness such as Claude Code, Codex or Antigravity or a custom MCP client, call them.
• Documented patterns: the use-case pages cover chat over A2A, multi-tier guardrails, sandboxed agents and a warm agent pool, each with runnable source under development/examples/.
• Hybrid deployment: guides cover Kubernetes, Cloud Run, SkyPilot and headless enrollment.

How it compares

Agent Mesh overlaps with two familiar categories without being either. Like an overlay VPN, it connects machines across NAT and issues identities, but its access control is expressed on service names and protocol types (MCP, inference, A2A) rather than on hosts and ports. Like a service mesh, it mediates calls between services with verified identities, but it does not depend on a single Kubernetes cluster and is designed to include laptops and phones. Teams that already run an overlay network or a service mesh should weigh whether the agent-specific pieces, such as the local MCP server, model routing and per-service grants, justify another control plane.

Things to know before adopting

• Pre-1.0: the README says the node, routers, control plane, identity and policy model are stable in shape and exercised by tests and two public testnets, with a release plan in ROADMAP.md. Sandboxed agent blueprints and the mobile app are in preview.
• Open development policy: on first boot agentmesh-one seeds a policy in which any enrolled member may publish and call any service, and logs a warning. The documentation says to replace it before sharing a mesh.
• HTTPS required off-host: a node refuses to fetch its trust root over plaintext from a remote address, so remote members need an https control plane URL, for example via the built-in Cloudflare tunnel option or a reverse proxy.
• Control plane is the trust root: whoever controls it controls membership and policy, so it deserves the same care as an identity provider.
• Mobile app permissions: the privacy page for the preview Agent Mesh Connect app says it requests foreground and background location access to keep its mesh node running, while stating that location history is not stored on central servers and that the app contains no telemetry.
• Support status: it is not an officially supported Google product and is not eligible for Google's open source vulnerability rewards programme.

Project activity

As of October 2026 the repository has about 1,100 stars. It was created in April 2026, is written in Go and is licensed under Apache-2.0, with pushes as recent as mid-October 2026. Documentation, built from the repository's site/ directory, is at google.github.io/agentmesh, and the source is at github.com/google/agentmesh.