Agent Mesh

agentmesh-node

Mon, 01 Jan 0001 00:00:00 +0000

agentmesh-node is the mesh member that runs beside an agent or a service.

agentmesh-node join [control-plane-url] [flags] enroll and store a credential
agentmesh-node run [flags] run the node
agentmesh-node forward egress://<name>:<port> [local-addr] forward a local TCP port to a named egress tunnel
agentmesh-node reset [--all] [--yes] forget the credential or everything
agentmesh-node state export|import <dir> move the identity to or from a state directory
agentmesh-node skill install|list|show manage the agent skill document

Files

The data directory is --data-dir if set, otherwise $AGENTMESH_DATA_DIR, otherwise the user configuration directory of the operating system (~/.config/agentmesh on Linux, ~/Library/Application Support/agentmesh on macOS). It is created with mode 0700 and holds:

Architecture

Mon, 01 Jan 0001 00:00:00 +0000

An agent mesh has a small control plane, one or more routers, and any number of nodes. The control plane decides who is in the mesh and what they may do. Routers make the nodes reachable. Nodes do the work: they publish services and call each other’s services on behalf of the agents next to them.

flowchart LR
 subgraph cp["control plane"]
 CP["agentmesh-control-plane<br/>identity · policy · signing key"]
 DB[("database")]
 CP --- DB
 end
 IDP["identity provider<br/>(OIDC)"]
 R["agentmesh-router<br/>bootstrap · relay · DHT"]
 A["agentmesh-node A"]
 B["agentmesh-node B"]
 AG["agent"]
 SVC["your tool or model"]

 CP -. verifies tokens .-> IDP
 R -- lease --> CP
 A -- enroll / refresh --> CP
 B -- enroll / refresh --> CP
 A <--> R
 B <--> R
 A <-. direct when possible .-> B
 AG -- "MCP · OpenAI API<br/>(local)" --> A
 B --- SVC

The control plane

agentmesh-control-plane is an HTTP service backed by SQLite or PostgreSQL. It is the only component that has to be trusted. It is not on the data path: tool calls and model requests never pass through it.

Exposing services

Mon, 01 Jan 0001 00:00:00 +0000

A node does not publish any service by default. You declare the services it offers in agentmesh-node.yaml. This guide covers the three kinds of service a node can serve and what the mesh policy must contain before anyone can reach them.

The configuration file

agentmesh-node reads agentmesh-node.yaml from the working directory, or the file named by --config. Both join and run read it, because labels are declared at enrollment. A minimal file with one service:

Quick start

Mon, 01 Jan 0001 00:00:00 +0000

This page installs agentmesh-node, enrolls it in the public bananas.sam-mesh.dev testnet, and calls a tool hosted by another node. It takes a few minutes.

The testnet is a shared developer playground with no uptime commitment. See About the public testnets. The steps are the same for any mesh: replace the URL with your own control plane.

1. Install

On Linux and macOS, the install script downloads the latest release and places the binaries in /usr/local/bin:

Sandboxed agents

Mon, 01 Jan 0001 00:00:00 +0000

An autonomous agent runs untrusted or model-generated code and prompts. To run one safely, you need two things that work together:

OS and network confinement, provided by a dedicated sandbox runtime (NVIDIA OpenShell, Kubernetes agent-sandbox with gVisor or Kata, or Docker Sandbox docker sbx), so the process can only talk to the local gateway.
Task-scoped authorization and credential brokering, provided by Agent Mesh (agentmesh-node or agentgateway + agentmesh-node), so the sandbox never holds a standing cloud credential or ambient workload token and can only call the services, MCP tools, HTTP paths, and cloud resources permitted for its current task.

This page shows the four deployment blueprints for connecting sandboxed agents and multi-hop sub-agents to an Agent Mesh.

Testnets

Mon, 01 Jan 0001 00:00:00 +0000

The project runs two public meshes for its own testing and for anyone who wants to try the software without deploying anything.

	`bananas.sam-mesh.dev`	`hub.sam-mesh.dev`
Built from	every push to `main`	every `v*` tag
Image tag	the commit SHA	the release version
Purpose	continuous integration of unreleased code	the latest release, for interoperability testing

Both are deployed by .github/workflows/deploy.yaml to a GKE cluster from the templates in .github/k8s/. Each testnet has a control plane Deployment on PostgreSQL, a router StatefulSet that announces /dnsaddr/bootstrap.<env>.sam-mesh.dev (a DNS-sync CronJob keeps the record current), the console, and a few canary nodes that publish demo services: the MCP everything server, an OpenRouter proxy, and a vLLM instance when one is running. Identity comes from a Dex instance at auth.sam-mesh.dev that accepts Google and GitHub logins, and from the cluster’s own issuer for in-cluster workloads.

Agent architecture

Mon, 01 Jan 0001 00:00:00 +0000

This page explains how Agent Mesh authenticates workloads and users, scopes authority to individual tasks and sub-agent hops, integrates with existing gateways and sandbox runtimes, and brokers short-lived credentials to external cloud APIs without placing standing cloud credentials inside the agent environment.

A courier network for tasks

Agent Mesh moves tasks between environments that trust nothing on arrival, the way a courier network moves parcels between post offices:

agentmesh-control-plane

Mon, 01 Jan 0001 00:00:00 +0000

agentmesh-control-plane admits nodes, mints credentials, holds the mesh policy and tracks routers. It is an HTTP server over SQLite or PostgreSQL.

agentmesh-control-plane [flags] run the server
agentmesh-control-plane admin ban --peer <id> ban a node directly in the database
agentmesh-control-plane admin unban --peer <id> lift a ban

Flags

Flag	Default	Meaning
`--issuer`		OIDC issuer URL(s), comma-separated. At least one of `--issuer` or `--workload-issuer` is required. The first issuer is advertised to enrolling nodes on `/info`.
`--workload-issuer`		Workload OIDC issuer(s), comma-separated (`<issuer>` or `<issuer>=<email-suffix>`, such as `https://accounts.google.com=.gserviceaccount.com`). Automatically added to `--issuer`. Workload tokens can enroll, refresh, and exchange credentials (`/register`, `/refresh`, `/token/exchange`), and are refused at `/user/*` and `/oauth/authorize`.
`--allowed-audiences`	`agentmesh-audience`	Audiences accepted in OIDC tokens, comma-separated.
`--oidc-client-id`	first audience	OAuth client ID advertised on `/info`, for providers where it differs from the audience.
`--insecure-skip-tls-verify`	`false`	Skip TLS verification when fetching issuer metadata and keys. For a cluster issuer served with the cluster CA, or a local development issuer.
`--bind-address`	`0.0.0.0:8080`	HTTP listen address.
`--db-driver`	`sqlite`	`sqlite` or `postgres`.
`--db-dsn`	`control-plane.db`	Database DSN. A PostgreSQL DSN contains a password, so the next two options are preferred for PostgreSQL.
`--db-dsn-path`		File containing the DSN. Overrides `--db-dsn`. Can also be set with `AGENTMESH_DB_DSN`.
`--admin-token-path`		File containing the bearer token for `/admin/*` and `POST /policies`. Can also be set with `AGENTMESH_ADMIN_TOKEN`. Without a token, the admin API cannot be used.
`--auto-approve-enrollment`	`false`	Issue credentials for valid bootstrap-token enrollments immediately instead of queueing them for approval.
`--biscuit-ttl`	`24h`	Lifetime of each credential. If the OIDC token expires sooner, the credential expires with it.
`--oidc-session-ttl`	`2160h` (90 days)	How long a human OIDC enrollment may keep refreshing before the identity must log in again.
`--workload-session-ttl`	`48h`	How long a workload OIDC enrollment (`--workload-issuer`) may refresh without presenting a fresh platform JWT in `TokenRefreshRequest.jwt`.
`--key-rotation-interval`	`24h`	How often a new signing key is generated. `0` disables rotation.
`--key-grace-period`	`1h`	How long a rotated-out key stays accepted. Credentials signed by a retired key cannot be verified or refreshed. Nodes and routers must pull `/keys` well within this window (`agentmesh-node --control-plane-sync-interval`, `agentmesh-router --keys-sync-interval`).
`--lease-duration`	`15m`	How long a router lease lasts without renewal.
`--node-retention`	`720h` (30 days)	How long the record of an enrolled node is kept after its session expires. Banned nodes are kept forever. `0` keeps every record.
`--mesh-reconnect-interval`	`30s`	How often the event publisher re-reads the router leases and dials any router it is not connected to.
`--log-level`	`info`	`debug`, `info`, `warn`, `error`. `LOG_FORMAT=json` selects JSON output.

HTTP API

Every request and response is a message in api/agentmesh.proto, in one of two encodings. Routes that mesh components call use binary protobuf (application/x-protobuf). Routes for operators and the console use protojson of the same messages, with proto field names; unknown fields are rejected. POST /policies accepts either and answers in the encoding of the request.

Connecting agents

Mon, 01 Jan 0001 00:00:00 +0000

An agent uses the mesh through the agentmesh-node that runs on its own machine. The node is an MCP server, so you can point any MCP client at it. This guide gives the configuration for the common clients and explains what the agent gets.

What every client needs

Three values, all printed by agentmesh-node run --daemonize:

The endpoint: http://127.0.0.1:8080/mcp (Streamable HTTP).
The token: the contents of ~/.config/agentmesh/api-token, or the AGENTMESH_API_TOKEN you started the node with. It goes in the header X-Mesh-Authentication: Bearer <token>.
The socket: ~/.config/agentmesh/agentmesh.sock. Anything the agent runs in a shell can use the socket without a token. This is the easier way to reach the node’s /v1 inference endpoint from scripts.

The node must be running before the client starts. MCP clients start and manage stdio servers themselves, but agentmesh-node is an HTTP server that they connect to. You can run agentmesh-node run --daemonize as often as you like, so it is safe to put it in a shell profile or to let the agent run it.

Identity and enrollment

Mon, 01 Jan 0001 00:00:00 +0000

Every participant in a mesh, node or router, has a key that it generated itself and a credential that the control plane issued for that key. Callers that reach the mesh through a node (workloads, users, and sandboxed agents) exchange their platform JWTs into delegated credentials bound to that node’s channel, and narrow them offline per task. This page follows credentials from enrollment and exchange to attenuation, outbound federation, renewal, and revocation.

Security architecture

Mon, 01 Jan 0001 00:00:00 +0000

This document describes the security architecture and posture of Agent Mesh for developers and security reviewers. It covers how Agent Mesh acts as an authority, Policy Decision Point (PDP), and task-scoped credential layer across environments, what problems it solves, what responsibilities remain with the surrounding platform, how its cryptographic and policy mechanisms work across agentmesh-control-plane, agentmesh-node, agentmesh-router, and the native SDKs, and which extensions are deferred on purpose.

1. Current security posture: a courier network for tasks

Your own mesh

Mon, 01 Jan 0001 00:00:00 +0000

This page gets a mesh of your own running in a few minutes: a control plane, a router and a web console on your laptop, in one process called agentmesh-one. You then put a member on it, open the console, and see a model that runs on your machine answer a request from another member. agentmesh-one runs the same code as a Kubernetes deployment, so what you learn here applies there too.

Agent Mesh Connect (Android)

Mon, 01 Jan 0001 00:00:00 +0000

Preview

Agent Mesh Connect currently supports Android only. There is no iOS app. The app is tested in CI on an Android emulator. Its screens, the on-device tools it exposes and the FFI surface may change.

Agent Mesh Connect is a Flutter app that runs agentmesh-node on an Android phone. The Go node is compiled into a shared library and driven over Dart FFI. The app is the UI around it, plus a small MCP server that exposes the phone’s sensors to the mesh. A phone enrolled this way is a node like any other. It has a key, a credential and a peer ID, and it appears in discovery with its phone-sensors service.

agentmesh-router

Mon, 01 Jan 0001 00:00:00 +0000

agentmesh-router is a libp2p peer with a stable identity that new nodes connect to first. It hosts the DHT, relays traffic between nodes that cannot reach each other, and forwards the control plane’s signed events. It has no policy of its own.

agentmesh-router [flags]

Enrollment

A router enrolls like a node, requesting mesh:role:router, with one of:

Flag	Meaning
`--jwt-path`	File containing an OIDC token (a projected service account token, for example).
`--bootstrap-token-path`	File containing a bootstrap token minted with `"role": "mesh:role:router"`.
`--oidc-token`, `--bootstrap-token`	The same tokens as values. Visible in process listings. The file forms are preferred.

The mesh policy must bind the router’s identity to mesh:role:router. The agentmesh-p2p Helm chart handles this: its bootstrap job binds the router’s service account and mints a bootstrap token with max_usages equal to the replica count.

Authorization

Mon, 01 Jan 0001 00:00:00 +0000

Authorization in Agent Mesh answers one question: may this caller perform this operation on this service on this node right now? Four sources contribute to the answer, and the destination node combines them:

The caller’s credential (Block 0 authority facts signed by the control plane).
The standing mesh policy (roles, bindings, HTTP narrowings, and egress destinations distributed by the control plane as Datalog rules).
Any appended TaskAuthorizationRule blocks (tar_block) on the credential, which narrow authority for a specific task or sub-agent hop.
The hosting node’s local attenuation configuration.

Each layer can only narrow what the others allow. If standing policy or any appended task block denies the request, the answer is no.

Reaching services outside the mesh

Mon, 01 Jan 0001 00:00:00 +0000

An agentic application calls APIs that are not on the mesh: a source forge, a ticketing system, an internal REST service, a model provider. This guide puts a agentmesh-node in front of such a destination as a policy enforcement point. The application changes one base URL. The admin writes one policy document. The node decides every request on the method, the path and the caller, holds the credential the destination needs, and keeps it out of the application.

Headless enrollment

Mon, 01 Jan 0001 00:00:00 +0000

Servers, containers and routers cannot complete an interactive login: there is no browser, and no person to log in. Such a machine enrolls in one of two ways: with an OIDC token that it already holds, or with a bootstrap token that an operator mints for it. This guide covers both, and then explains what happens when the credential of such a node expires.

With an OIDC token that the workload already has

If the platform gives the workload a token from an issuer that the control plane trusts, no operator step is needed. Mark workload issuers with --workload-issuer on the control plane so workload tokens can enroll, refresh, and exchange credentials (POST /register, POST /refresh, POST /token/exchange), while being refused at human operator endpoints (/user/*, /oauth/authorize).

agentmesh-one

Mon, 01 Jan 0001 00:00:00 +0000

agentmesh-one runs a control plane, a router and the web console in one process on one port. The router’s libp2p transport is WebSocket on the same port as the HTTP API, so a node needs only one https URL. The same binary is also the admin client for a running instance.

agentmesh-one [flags] run the mesh
agentmesh-one token create|list|revoke|qr manage bootstrap tokens on a running instance
agentmesh-one admin ban <peer-id> ban a node

Files

Everything lives in --data-dir (default .): agentmesh.db (SQLite), the router key, join-token and admin-token when generated, and bin/ for a downloaded tunnel connector.

Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

This guide deploys a control plane, a router and a console into a cluster with the agentmesh-p2p Helm chart, then puts services on the mesh with the agentmesh-node chart. The last section lists the settings to change when you move from a test cluster to one that you keep. The public testnets run this setup on GKE. Their manifests are in .github/k8s/ in the repository.

What gets deployed

Component	Kind	Notes
`agentmesh-control-plane`	Deployment (2 replicas)	Stateless. All state is in PostgreSQL.
PostgreSQL	StatefulSet	In-cluster by default (`database.postgres.deployInternal`). You can point the chart at your own database instead.
`agentmesh-router`	StatefulSet	A PVC holds `router.key`, so the peer ID survives rescheduling.
`agentmesh-console`	Deployment	Optional (`console.enabled`).
bootstrap Job	Job (post-install hook)	Seeds the mesh policy and mints the router’s bootstrap token.
Gateway + HTTPRoute	Gateway API	Optional (`gateway.enabled`). Routes the enrollment paths and the console.

The chart does not include an identity provider, and the control plane needs one to start. The cluster’s own OIDC issuer is a good choice, because every pod can then enroll with a projected service account token and no secret has to be distributed.

Networking and the node API

Mon, 01 Jan 0001 00:00:00 +0000

This page follows a request from an agent to a service on another node: how the calling node finds the provider, how the two connect, and what the agent sees at each end.

The node’s local API

An agent does not speak to the mesh directly. It speaks to the agentmesh-node on its own machine, through one of two listeners:

TCP, 127.0.0.1:8080 by default (--bind-addr). Every request must carry the node’s API token as X-Mesh-Authentication: Bearer <token>.
A Unix socket, <data-dir>/agentmesh.sock by default (--socket-path), created with mode 0600. No token is needed, because only the user who owns the socket can open it. docker.sock works the same way.

You can turn either listener off by passing an empty value. With --bind-addr=, the node has no listening port and no secret to manage. This is a good setup when everything that uses the node runs as the same user.

Scale report: what an agent costs

Mon, 01 Jan 0001 00:00:00 +0000

Preview

These measurements are of the sandbox datapath described in Sandboxed agents. They were recorded on 2026-08-21 at commit e5b2966, when the boundary spoke SOCKS5. The boundary has since moved to HTTP CONNECT and has not been measured again. The shape of the results is what matters. Single figures are indicative.

The design gives every agent its own boundary, which resolves names and enforces policy on each flow. That sounds expensive. This page measures it. The method is written down so that the result can be challenged, and a script is provided so that it can be run again. There are two experiments: a sweep of boundaries attached to one node, and a thousand agents in microVMs on one host.

Control and data boundaries

Mon, 01 Jan 0001 00:00:00 +0000

When you run your own control plane, you decide everything about the mesh. On the public testnets, someone else decides who joins and what the policy says. This page lists the decisions that become yours in a dedicated deployment and the mechanism that enforces each of them.

What you control in a dedicated deployment

Membership. Enrollment goes through your identity provider or through bootstrap tokens that you mint. The bindings in the control plane decide which identities receive which roles. An identity without a binding cannot enroll a node.
The signing key. The control plane generates its Ed25519 signing keys and stores them in its database. Every credential in the mesh is signed by one of these keys, and nobody outside the deployment can mint or extend a credential. The keys rotate on the schedule you set.
The policy. What each role may call, on which nodes and with which labels, is stored in your database. It can only be changed with your admin token or through your console.
Revocation. A ban takes effect on the next credential refresh (within the credential TTL, 24 hours by default) and, through the mesh event channel, immediately on every connected node.
Where the software runs. Agent Mesh is Apache-2.0, sends no telemetry, and does not depend on any hosted service. The control plane, routers and nodes run wherever you put them: a laptop, a private cluster, an air-gapped network.

The public testnets give you none of this. They are useful for trying the software. Do not put anything there that you would not publish.

Cloud Run

Mon, 01 Jan 0001 00:00:00 +0000

agentmesh-one serves its HTTP API, the web console, and the router’s WebSocket transport on a single port (8080), and ships as a pre-built container image (ghcr.io/google/agentmesh-one:latest). Because agentmesh-one automatically infers its public wss:// router address from Cloud Run’s Host and X-Forwarded-Proto headers on /info and /enroll and derives a deterministic router PeerID from AGENTMESH_ADMIN_TOKEN, you can deploy a standalone control plane and router to Google Cloud Run in a single command.

GitHub Codespaces

Mon, 01 Jan 0001 00:00:00 +0000

A codespace is a container that GitHub runs for you, with a terminal, an editor and an https URL for every port you forward. Started from this repository, it gives you a control plane of your own with nothing installed on your machine and no cloud account. agentmesh-one runs inside it, your laptop and your phone enroll over the public URL, and your GitHub account pays with its free Codespaces quota (120 core-hours a month on a Free plan; a 2-core machine is enough). The same setup lets you develop Agent Mesh, or a program that uses one of its SDKs, against a mesh that external clients can reach.

Node configuration file

Mon, 01 Jan 0001 00:00:00 +0000

agentmesh-node.yaml declares what a node is (labels), what it publishes (services), what it requires from callers (attenuation) and what it requires from providers (egress). Both agentmesh-node join and agentmesh-node run read it from --config, by default ./agentmesh-node.yaml. A missing file means an empty configuration. Unknown keys are an error, because a typo under attenuation would otherwise weaken the node without notice.

version: "v1alpha1"

labels:
 region: eu-west-1
 team: platform

services:
 - type: mcp
 name: code-reviewer
 description: "Reviews diffs"
 target_url: "http://127.0.0.1:7777/mcp"
 - type: mcp
 name: filesystem
 command: ["npx", "-y", "@modelcontextprotocol/server-filesystem", "/srv/docs"]
 env:
 NODE_OPTIONS: "--max-old-space-size=256"
 - type: inference
 name: vllm
 target_url: "http://127.0.0.1:8000"
 target_auth_path: /etc/agentmesh/vllm-key
 - type: a2a
 name: triage
 target_url: "http://127.0.0.1:9999"

attenuation:
 rules:
 - 'maintenance() <- time($t), $t > 2026-12-31T00:00:00Z;'
 checks:
 - 'check if label("team", "platform");'
 policies:
 - 'deny if service("mcp", "filesystem"), group("contractors");'
 - 'deny if maintenance();'

egress:
 require_labels:
 jurisdiction: eu

`version`

"v1alpha1", or omitted (read as v1alpha1). A node refuses a version it does not know.

Sandboxed Agent

Mon, 01 Jan 0001 00:00:00 +0000

An agent runs in a sandbox with no route into the office: here, a GitHub codespace. Through the mesh it reaches a model and an MCP server that listen on loopback in the office, and api.github.com with a credential it never holds. The admin decides what it may call, down to the HTTP method and path, watches every decision, and cuts it off when done.

Source: development/examples/sandboxed-agent/. The scenes, the narration and the recording recipe are in its SCRIPT.md.

Scale experiment: reproducing the thousand-agent run

Mon, 01 Jan 0001 00:00:00 +0000

Preview

The scripts under tests/scale/ and scripts/ are research tooling for the scale report. They are kept working but are not a supported product surface.

The report says what was measured and what it means. This page says how to run it again. The setup is one host, one agentmesh-node, and N agents. Each agent is a Firecracker microVM with no network device, and its only way out is a vsock to its own agentmesh-box. A thousand agents have been run on one n2-standard-64.

Mesh policy

Mon, 01 Jan 0001 00:00:00 +0000

The mesh policy is one document held by the control plane: a list of roles, a list of bindings and a list of egress destinations. It is posted as JSON (protojson of PolicyConfig in api/agentmesh.proto) to POST /policies, read back from GET /admin/policy, edited in the console, or given to agentmesh-one --policy-file for first boot.

{
 "roles": [
 {
 "name": "mesh:role:node",
 "allowed_services": ["system://mesh.catalog"],
 "allowed_labels": ["region=*", "team=platform"]
 },
 {
 "name": "developer",
 "allowed_services": ["mcp://code-reviewer", "mcp://build-runner.*", "inference://*"],
 "allowed_targets": ["group:dev-nodes", "node:12D3KooWSpecialNode"],
 "custom_datalog": ["tier(\"standard\");"]
 },
 {
 "name": "analyst",
 "allowed_services": ["egress://bigquery.googleapis.com"],
 "allowed_targets": ["*"],
 "http": [
 { "service": "egress://bigquery.googleapis.com", "methods": ["GET", "POST"], "paths": ["/bigquery/v2/projects/my-proj/datasets/*"] }
 ]
 }
 ],
 "bindings": [
 { "role": "mesh:role:node", "members": ["group:engineering", "user:system:serviceaccount:agentmesh-nodes:calc-mcp-agentmesh-node"] },
 { "role": "developer", "members": ["group:engineering"] },
 { "role": "analyst", "members": ["group:analytics"] }
 ],
 "egress": [
 {
 "name": "bigquery.googleapis.com",
 "served_by": ["site=eu"],
 "broker": {
 "oidc_federation": {
 "token_endpoint": "https://sts.googleapis.com/v1/token",
 "audience": "//iam.googleapis.com/projects/123/locations/global/workloadIdentityPools/agentmesh/providers/agentmesh-cp",
 "scopes": ["https://www.googleapis.com/auth/bigquery.readonly"]
 }
 }
 }
 ]
}

The whole document is replaced on every post. Unknown fields are rejected, so a misspelt key fails the request instead of dropping a grant without notice.

Native SDKs

Mon, 01 Jan 0001 00:00:00 +0000

An agent written in JavaScript or Python can be a member of the mesh itself, with no agentmesh-node beside it. The SDK enrolls with the control plane, joins through a router, finds services, calls MCP tools and inference or A2A endpoints, and answers A2A requests for the agent itself. Every caller of the agent is checked against the mesh policy before anything reaches your code.

This guide takes you from nothing to two programs on a mesh: an agent that other members can call, and a caller that reaches a service by name and the agent by its peer ID. Both programs are in the repository under sdk/js/examples and sdk/python/examples, and the repository’s tests run them against a real mesh, so what you read here is what runs.

SkyPilot

Mon, 01 Jan 0001 00:00:00 +0000

SkyPilot provisions and manages compute across Google Cloud, AWS, Azure, OCI, and Kubernetes using your existing cloud credentials (sky check). The repository includes a ready-to-run recipe, deploy/skypilot/agentmesh-one.yaml, that deploys a standalone agentmesh-one control plane and router with a persistent disk and an outbound Cloudflare HTTPS tunnel (requiring no inbound firewall rules).

(Note: While deploy/skypilot/agentmesh-one.yaml defaults to production VM sizing (cpus: 2+, memory: 8+, matching e2-standard-2 on GCP or t3.large on AWS), you can also set cpus: 0.25+ and memory: 1+ to run on cloud provider free tiers such as GCP e2-micro or AWS t4g.micro for testing.)

Node API

Mon, 01 Jan 0001 00:00:00 +0000

The local API that agentmesh-node run serves to agents, gateways, and scripts on the same machine or cluster. It is available on TCP (--bind-addr, default 127.0.0.1:8080) and on a Unix socket (--socket-path, default <data-dir>/agentmesh.sock). The Envoy ext_authz and ext_proc endpoints are served on the same listeners.

Authentication

Listener	Requirement
TCP (`--bind-addr`)	`X-Mesh-Authentication: Bearer <token>` on every request, or `Authorization: Bearer <token>` on non-proxy endpoints (`/mcp`, `/v1/`, `/egress/`, `/oauth/*`), or a client certificate when `--tls-ca` is set.
Unix socket (`--socket-path`)	None required for node-level access (the socket has mode `0600`). A caller may still pass an Agent Mesh Task Biscuit or platform JWT in `X-Mesh-Authentication` or `Authorization` to scope the request to that caller’s identity and task rules.

The bearer <token> accepted by agentmesh-node can be:

Warm Agent Pool

Mon, 01 Jan 0001 00:00:00 +0000

Spread a batch of work across a pool of identical, already-running worker agents. The pool is built from ordinary mesh MCP services, with no gossip and no changes to the node.

Source: development/examples/code-reviewer-pool/.

The idea

Some agent tools are expensive to start but cheap to reuse: a reviewer that calls an LLM, a sandbox that boots a runtime, a service that holds a warm model in memory. You do not want to start one per request, and you do not want a single instance that handles all your work one job at a time. What you want is a pool of identical, already-running workers, and something that hands them out one job at a time.

Gemini Buddy

Mon, 01 Jan 0001 00:00:00 +0000

Hold a real multi-turn conversation with a second LLM exposed as an ordinary mesh service. Your agent never resends the conversation, because the service remembers its own side.

Source: development/examples/gemini-buddy-mcp/.

The idea

Sometimes you want your agent to talk to another model: for a second opinion, to discuss a design, or to use a specialist that builds up its own context over many turns. The simple approach is to carry both conversations in the orchestrator. Your agent would have to store the other model’s transcript and replay all of it on every turn.

Multi-Tier Enterprise Guardrails & Quality Gates

Mon, 01 Jan 0001 00:00:00 +0000

When every developer and team starts shipping AI agents, organizations hit a governance paradox:

Agent Developers want 1-command onboarding from a laptop or Cloud Run without waiting weeks for VPC peering, DNS records, or firewall tickets.
Platform & Networking Engineers want persistent logical service names (a2a://support.acme) that survive replica swaps across environments without static proxy limits.
Central Security (CISO) wants an organization-wide policy floor, automated quality gates before an agent can serve production (env=staging $\rightarrow$ env=prod), and zero raw API credentials inside agent containers.
Department Leads & Individual End-Users want to narrow what an agent can do on their infrastructure or on their behalf—even when the organization’s baseline policy allows it.
Day-2 Operations (SRE) needs a correlated audit trail across every hop and a 1-command kill-switch (agentmesh-one admin ban) if a peer misbehaves.

The runnable example in development/examples/multi-tier-guardrails/ walks through all five personas in four acts using real backends and zero changes to Agent Mesh’s core code:

A2A Chat

Mon, 01 Jan 0001 00:00:00 +0000

Hold a multi-turn conversation with an A2A (Agent2Agent) agent hosted on a remote mesh node, using a stock, unmodified a2a-sdk client. There is no Agent Mesh-specific client code. The mesh regenerates the agent card, and that is enough for the standard SDK to work as it is.

Source: development/examples/chat-a2a/.

The idea

A2A is how agents talk to each other on the mesh. An agent process that speaks A2A over HTTP is declared on its node as a type: a2a service, and remote peers reach it through the proxy path /mesh/{peer}/a2a/{service}/... (see A2A agents).

Privacy Policy

Mon, 01 Jan 0001 00:00:00 +0000

Last Updated: September 17, 2026

This Privacy Policy explains how Agent Mesh Connect (“we”, “us”, or “our”) collects, uses, and protects your information when you use our mobile application. Agent Mesh Connect is an open-source Agent Mesh network client designed for zero-trust, peer-to-peer connectivity.

1. Information We Collect

To function as a background mesh network node, Agent Mesh Connect requests the following device permissions and data:

Location Data (Foreground and Background): We request access to your device’s precise and coarse location (ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION, and ACCESS_BACKGROUND_LOCATION).
Network State: We monitor your WiFi and network connections to maintain the mesh tunnel.
Node Identity: Cryptographic keys (such as Ed25519 root keys), biscuits, and local API tokens used for mesh authentication and zero-trust identity federation.

2. How We Use Location Data

Because Agent Mesh Connect operates as a continuous mesh network router, it requires Background Location access to maintain network stability, handle routing via the Model Context Protocol (MCP), and keep the foreground service alive even when the app is closed.