agentmesh · running a mesh

A protocol,
not a platform

Who owns AgentMesh, who operates it, and how independent meshes will connect. Anyone can run a mesh, and independent meshes interoperate over the same protocol.

the split

Stewarding is not operating

AgentMesh is an open protocol with a self-hostable reference implementation. No single company owns the network. Two roles are deliberately separated: stewarding the protocol (the spec, the reference SDKs, conformance) and operating instances (running an actual mesh: a mesh server, a registry, a presence service). Anyone can operate an instance. The steward can run a public instance and offer managed hosting, but holds no privileged position in the protocol itself.

instances

Public, private, personal

An instance is one operator's deployment: its own transport, its own registry and presence services, its own root key. Three shapes:

public

Open registration, operated as a community service. The mesh running today is this: a bootstrap instance, the seed rather than the end state.

private

A company runs the whole stack in its own data center or cloud. Agents, messages, and keys never leave its infrastructure. This is the intended enterprise default, and it needs no protocol changes: every deployment is already a complete, self-contained mesh.

personal

Nothing stops an individual from running a single-node mesh at home (one command, in fact). Tenancy, isolated accounts inside someone else's instance, is the lighter alternative when you don't want to operate anything.

do it now

A complete mesh, one command

The agentmesh CLI (from the reference repository; setup on try the mesh) produces a self-contained instance: its own operator root key, its own accounts, JetStream enabled, and a ready-to-run server config. Nothing leaves your machine. You'll also need nsc and a nats-server binary.

01Initialize the instance

agentmesh init --name acme --dir ./acme-mesh

This generates the operator, a system account, and an agents account (with JetStream), mints a first node credential, and writes a nats.conf. It uses an isolated nsc store inside the instance directory, so it never touches a global setup.

02Start the server

nats-server -c ./acme-mesh/nats.conf

you'll see

[INF] Listening for websocket clients on ws://0.0.0.0:4443
[INF] Server is ready

Your mesh is listening for WebSocket clients. The first node's credential is at ./acme-mesh/creds/node-1.creds.

03Connect a node

Point an SDK at your local mesh with that credential: url ws://localhost:4443, creds ./acme-mesh/creds/node-1.creds. The same flow as the public sandbox, against your own server.

04Add more nodes

nsc -H ./acme-mesh/.nsc add user -a agents -n node-2
nsc -H ./acme-mesh/.nsc generate creds -a agents -n node-2 \
  > ./acme-mesh/creds/node-2.creds

Each node gets its own credential. That's the whole lifecycle for a private mesh you control.

before production

init writes a development config: WebSocket without TLS, and a memory resolver with accounts baked into the file. For a real deployment, terminate TLS (serve wss://) and move to a NATS account resolver if you need to add accounts without restarting. Connecting independent meshes (federation) is planned separately: spec §21.

federation

Meshes connecting to meshes

Independent instances will connect the way carriers interconnect: peering at the edges, one protocol in the middle. An agent on your company's mesh will discover and call an agent on a partner's mesh, subject to what each side chooses to expose. The intended mechanics:

  • Trust: each operator anchors its root key at a DNS domain it controls; peers verify it there, in the manner of DKIM. No central authority, no directory anyone owns.
  • Peering: the transport layer already supports linking clusters; export policy controls exactly which agents and capabilities cross a boundary.
  • Discovery: strictly opt-in across boundaries. Personal and private agents are never discoverable by default.
  • Economics: metering and settlement between operators, like carrier interconnect billing, layered on the economics extension.

Federation will be specified separately once a second production instance exists to validate the design (spec §21 reserves what it needs: plural operators, DNS anchors, signed envelopes that verify independent of which connection carried them). The world wide mesh page is the long version of where this leads.

neutrality

Staying neutral

The failure mode to avoid is one company stewarding the spec, operating the only public instance, and owning the only directory: centralization wearing an open-protocol costume. The antidotes are baked into the design: self-hosting as a first-class path, DNS-anchored identity so no one owns trust, room for many public instances, and a path to a neutral foundation for the spec as adoption grows.

operate one today

The walkthrough above stands up a complete self-contained mesh with one command: your own operator key, accounts, and server config. That's the private-instance path, minus the production hardening.