Agent Mesh built successfully in our sandbox, then failed three integration checks involving failover, policy permutations, and router discovery. Those are consequential failures for software whose job is connecting agents safely across machines. I'd try it on a controlled network with replaceable workloads. I wouldn't make it the only route to a critical tool yet.
Service permissions follow names instead of machine addresses
The Agent Mesh README describes a node beside each agent that publishes local tools or models, discovers remote services, and verifies peers. Nodes connect directly where possible and use relays where necessary. A laptop behind NAT can therefore offer a model to another member without exposing that model's server directly to the internet.
Our checkout contained 823 files and about 154,316 source lines, so this is substantial infrastructure for that task. A control plane handles enrollment and policy, routers relay traffic and host discovery, and nodes connect applications. The appeal is service-level permission: allowing an agent to call a named calculator is more precise than merely putting its computer on the same private network.
What happened when we ran it
Our run installed 347 packages in 39 seconds and built Agent Mesh in 94 seconds at commit 9fc9aaa. We used an unprivileged Debian container with 3 CPUs, 8 GB of RAM, the golang:1.24-bookworm image, and no secrets on October 14, 2026. The checkout occupied 26.3 MB. Both installation and build completed successfully, which gives contributors a workable starting point.
The test command exited with status 1 after 539 seconds. Our lab summary reported 50 passed and 3 failed out of 53. The log tail names TestFailoverUpdatesRelay, TestPolicyPermutations, and TestCallerTransitsARouterItsCatalogMissed, followed by failure of github.com/google/agentmesh/tests/integration. Several preceding package lines say ok. The tail provides no underlying assertion messages, so it cannot establish the causes or connect these failures to a particular upstream fix.
The scan found 16 CI workflow files and a tests directory, with no Dockerfile detected. That is useful evidence of automated development work, alongside a suite that did not pass in our environment. These results cover repository mechanics. They give us no measured network throughput, inference speed, or proof that authorization holds under every deployment condition. The failures warrant reproduction before adoption.
The standalone server starts with permissive development policy
The self-hosting guide makes agentmesh-one attractive for a laptop: control plane, router, and console share a process. Its first boot seeds an open development policy under which enrolled members may publish and call any service. That qualification matters beside the README's general description of services being unreachable until configuration and policy allow access.
A 94-second successful build doesn't prepare a shared deployment for you. Replace the development policy, restrict enrollment, and preserve the data directory containing the database, router key, and generated tokens. Remote members require an HTTPS control-plane address. The guide supports a temporary Cloudflare tunnel or your own hostname, and offers PostgreSQL for durable state. Choose those deliberately before distributing join credentials.
A local API token carries the node's full authority
The client guide documents a local MCP server and an OpenAI-compatible inference endpoint. Claude Code connects over HTTP, and the bundled skill teaches discovery and remote calls. The node must already be running. A Unix socket gives local scripts access without a token, while TCP clients authenticate with the node's API token.
The same guide says a client holding that token receives everything the node's credential grants. That's a meaningful boundary if you run code from several trust levels on one workstation. Sandboxed-agent arrangements and the mobile app remain previews. Our 539-second test run doesn't establish isolation between those clients, so I would keep untrusted code away from a broadly authorized node and evaluate the preview separately.
Policy removal can wait for credential refresh
The authorization documentation explains a subtle operational limit: removing a grant doesn't erase permission facts already embedded in a credential. Those remain valid until refresh or expiry. Operators who expect an edited policy to withdraw every permission immediately should examine that behavior before using the mesh for sensitive tools. Offline credential verification brings a concrete lifecycle obligation.
Our 3 failed checks don't prove a permission bypass, and their names alone cannot explain that result. They do prevent a clean endorsement of failover and policy behavior at the measured commit. I'd require a repeatable explanation of each failure, then exercise grant withdrawal and router loss with the actual services intended for the mesh. Keep an independent route available while deciding whether it meets your operating requirements.
October activity supports a trial, with release-candidate limits
GitHub records the last push on October 14, 2026, and release v0.1.0-rc.10 that day. It listed 1,062 stars and 29 open issues and PRs when checked. The recently updated queue includes closed automated testnet-health reports and an open router-redial change. Together, those dates and discussions show active maintenance. They don't show that our measured integration failures have been resolved.
Agent Mesh is explicitly pre-1.0 and isn't an officially supported Google product. Choose it when service discovery and named tool permissions justify operating this additional infrastructure. For ordinary private machine connectivity, compare Tailscale or NetBird. Headscale suits a self-hosted Tailscale control server. Those choices address a different permission layer, so the deciding experiment is whether your agent workflow needs Agent Mesh's service model enough to own its policy and recovery behavior.