Google SAM is now Agent Mesh: MCP tools across machines

Google SAM is now Agent Mesh

Sovereign Agent Mesh (SAM), now called Agent Mesh, is an open-source networking layer for AI agents. It lets an agent discover and call approved tools on other machines through a local node. The repository has moved from google/sam to google/agentmesh. Its current README confirms the name change and project status: Apache-2.0, pre-1.0, and not an officially supported Google product.

The practical problem is familiar. Your coding assistant runs on a laptop. A reviewer runs beside a build server. An internal search tool lives in a private cluster. Each has useful capabilities, but sharing them requires reachable endpoints and a decision about who may call what.

Agent Mesh provides that connection and authorization layer. You keep the tools where they belong and publish selected capabilities to enrolled peers.

Version note, checked 12 October 2026: this article follows source commit 273e6fba and its agentmesh-* names. The latest listed release, v0.1.0-rc.9, published 7 October, still uses sam-* names. Use commands and documentation from the same version when evaluating it.

A local node makes remote tools reachable

An agent talks to agentmesh-node on its own machine. That node connects to the mesh and checks which remote services it can reach. A provider node publishes only the backends its operator configured.

The control plane admits members and issues credentials. Routers help nodes find each other and relay encrypted traffic when a direct connection is unavailable. agentmesh-one packages a control plane, router and console together for smaller deployments. The architecture documentation describes these responsibilities.

For an existing agent stack, it helps to separate the layers:

Our guide to agent communication and Band covers the wider coordination question. SAM's specific contribution is the network underneath those interactions.

Automatic discovery removes repeated endpoint wiring

Once a node joins, it learns about routers and discovers published services through the mesh's distributed directory. Connections can use a direct route or an encrypted relay. The networking guide explains discovery, relays and connection recovery.

This can save you from maintaining a separate address list for every assistant. A service keeps its name when its provider changes networks. Discovery results identify candidate providers; the connection and credential checks determine whether a request may proceed.

Operators still choose a control plane, enroll members and grant access. They also configure each published backend. Calling this process “zero config” hides decisions that determine what your agents can reach.

The local node exposes a Streamable HTTP MCP endpoint. The client integration guide includes Claude Code and Google Antigravity examples, plus other MCP clients. Its skill teaches an assistant how to discover, describe and call remote tools. Enrollment and MCP configuration remain separate steps.

For Codex or Hermes, check the client's supported MCP transport and authentication settings before promising a working integration. This article does not establish a tested compatibility matrix for those clients.

Identity follows the node across network changes

Each node generates its own Ed25519 key pair. Its peer ID derives from the public key. An OpenID Connect login or bootstrap token enrolls it with a control plane, which issues a signed Biscuit credential. That credential carries the identity and permissions peers can verify.

The credential is bound to the node's key. Copying the credential alone does not provide that key. Peers authenticate the connection and evaluate the requested service against the caller's authority. The identity and enrollment specification also explains expiry and renewal.

You can therefore grant access to a named service without tying the rule to a laptop's current IP address. The credential still belongs to its issuing mesh. Moving a workload to another cloud and joining an unrelated control plane are different operations.

A dedicated mesh puts membership and keys under your control

Running your own control plane lets you decide which identities join and which services they may use. Your deployment owns its credential-signing keys and administrative policy. Protecting its database and admin access is part of operating that trust boundary.

The control and data boundaries documentation describes self-hosting on private infrastructure, including an air-gapped network. An isolated deployment also needs its identity services, tools and models available inside that environment.

Tool requests travel between nodes; the control plane handles membership and policy outside that data path. A relay carries encrypted traffic and can observe connection metadata.

The shared public testnets are useful for experiments with synthetic data. Their operators control membership and policy, and uptime is not guaranteed. A company-specific boundary starts with a dedicated deployment and verified infrastructure choices.

EU labels constrain provider selection

Agent Mesh can require a provider to carry a signed label such as jurisdiction=eu. A node declares labels at enrollment. The control plane signs only those its role permits through allowed_labels.

On a consumer node, an operator can set this minimum requirement:

version: "v1alpha1"
egress:
  require_labels:
    jurisdiction: eu

The node configuration reference defines this floor. A caller can add provider requirements but cannot remove the operator's requirement. The gate verifies signed credential facts before forwarding a request.

The signature proves that the mesh authority accepted a label. Its physical meaning comes from your deployment controls. A machine carrying an EU label could still run a backend that forwards prompts to an external model API.

Check the complete processing path: the provider's actual location, relay placement, downstream APIs, logs and backups. Ordinary outbound connections from the application also need appropriate controls. A label on a mesh node cannot establish all of those facts.

Our EU data residency guide for AI applications covers that broader boundary. Here, the useful mechanism is enforceable selection among providers whose labels you have independently justified.

The provider can refuse a centrally granted call

A machine that hosts a sensitive tool can impose its own checks. For example, its operator can require an attested caller label or deny a particular service to a group. A failed local check or matching deny policy can block access even when the mesh grants it.

The authorization specification describes that local enforcement. It also supports narrower task credentials for delegated work.

This gives a tool owner a practical veto. It still leaves application-specific decisions, such as which customer's records a query may return, with the service that understands those records. Our MCP data-level access-control article explains that next layer.

Evaluate SAM with two nodes and one arithmetic tool

Start with a capability whose inputs and result are easy to inspect. An addition-only MCP server gives you a useful test without involving business data. This walkthrough is derived from the documentation; Wavect has not executed this deployment or benchmarked SAM for this article.

Use a dedicated test control plane and binaries matching your chosen source or release. The following command names match the examined current source. Replace mesh.example.com with your own HTTPS control-plane address.

1. Publish a deliberately small provider

On machine A, run your test MCP server on loopback at port 7779. It must offer Streamable HTTP at /mcp. Save this as provider.yaml:

version: "v1alpha1"
labels:
  jurisdiction: eu
services:
  - type: mcp
    name: calculator
    description: "Arithmetic tools"
    target_url: "http://127.0.0.1:7779/mcp"

The service publishing guide documents this configuration shape. The node probes the backend before advertising it. Give the provider's enrollment role permission to carry jurisdiction=eu, after verifying that label is appropriate.

2. Enroll the provider and consumer

Create separate enrollment tokens for the two machines. On A, keep its token in a local file and run:

agentmesh-node join https://mesh.example.com \
  --bootstrap-token-path ./provider-join-token --config ./provider.yaml
agentmesh-node run --config ./provider.yaml

On machine B, save the earlier egress.require_labels example as consumer.yaml. Enroll and run B with that file and its own token. The caller needs access to mcp://calculator and discovery through system://mesh.catalog. Keep its permissions specific to this exercise.

3. Discover the tool, then inspect its schema

Connect a compatible MCP client to B's local node using the documented endpoint and authentication. Call get_mesh_info to check connectivity, then discover_remote_services for the calculator. Use find_remote_tools and describe_remote_tool to inspect the selected provider's tool.

Pass the returned peer ID, namespaced tool name and schema-correct arguments to call_remote_tool. Submit the synthetic values 2 and 3 to the addition tool and check for 5. Record which provider answered. Tool names and parameter names must come from discovery. The node API reference specifies these discovery and tool-call interfaces.

4. Check the refusal paths

Repeat against a test provider lacking the required signed label. Verify that it receives no arithmetic payload. Then add a provider-local deny rule and verify that an otherwise permitted call is refused. Finally, disconnect a node and observe discovery and reconnection separately from any application retry.

Record the successful calls, refusals and recovery behavior in your environment. Use those results to decide whether to evaluate a private search tool or reviewer next.

Reviewer pools add coordination above the mesh

The project's warm agent pool example spreads code-review work across already-running workers. Each worker exposes an MCP review tool. A manager discovers workers and leases them to an orchestrator, which dispatches a batch concurrently.

That separation is useful. The mesh finds and reaches a worker. The manager decides whether it is available. Your workflow decides what counts as an acceptable review.

Connectivity recovery can reconnect peers after a network interruption. Task completion still needs its own rules. If a response disappears after a tool finishes, a retry may repeat the operation. Track job IDs and completion state before introducing tools that write files or trigger other actions. The mesh's self-healing connectivity does not establish exactly-once task execution.

Choose a pilot around one shared capability

Agent Mesh is worth evaluating when useful tools sit on different machines and several assistants need controlled access to them. A local node gives each client one entry point; the operator defines who may reach each service.

Keep host isolation and application authorization in the design. The project's security architecture describes the boundary with sandboxing and external services.

For a team already connecting a laptop assistant to private build or search infrastructure, the first decision is concrete: pick one tool, two enrolled nodes and a permission you can test. Expand after you can show which identity called the tool, which provider received the input and how a forbidden call was stopped.