C# and NATS.io for agentic AI orchestration

What's old is new: A NATS-native protocol for AI agents

Agent systems are becoming distributed systems, and NATS already solves many of the communication problems those systems are rediscovering.

NATS has long been a natural fit for distributed, heterogeneous systems. No matter where your devices run, what languages your services use, or how ephemeral your clients are, it gives them a simple way to find and talk to one another. It also easily bridges different cloud vendors, geographies, runtimes, or hardware—with an integrated security model that naturally extends everywhere NATS does.

These traits make NATS an obvious choice for multi-agent architectures. Set aside the AI language, and agents have many of the same needs as microservices:

Plus, as orgs race to ship products and services enabled by agents (or build internal agentic workflows), they aren’t building on one unified agent stack. They’re mixing models, clouds, runtimes, private data, and physical environments that no layer of their stack can fully understand or control.

At production scale, agentic systems are distributed systems in a trench coat.

And most teams are stuck gluing them together with HTTP or shoehorning everything into a vendor’s gateway or mesh.

The open source Synadia Agent Protocol for NATS lets agents of any kind be addressed on a single fabric. This new protocol on top of NATS isn’t an agent framework, or a runtime, or a product of any kind. It’s a contract that says:

If an agent does these few specific things, anything else on the same NATS system can find it and talk to it without knowing what framework you built the agent with.

The payoff is that callers don’t need to care whether an agent is a Python script, a hosted model wrapper, a CLI session, or a long-running service. They discover capabilities, send a prompt, receive a typed stream, and observe liveness the same way every time.

When all your agents speak NATS fluently, you can build the surfaces that work across them — monitor, audit, orchestrate, whatever your architecture needs.

The protocol itself has three responsibilities: discovery, conversation, and liveness.

An agent registers as a NATS micro service with the service name agents. Its metadata describes itself — what kind of agent it is, who owns it, what protocol version it implements, optionally what session it belongs to. A caller that wants to know which agents are reachable sends a standard micro service ping at $SRV.PING.agents (or asks for full info at $SRV.INFO.agents), and every running agent that matches the caller’s permissions answers. No registry. No service catalog. No coordinator process you have to keep alive. The thing NATS already does for every other micro service on the cluster is the thing it does for agents too.

Discovery returns full endpoint records: the subject to publish prompts to, capability metadata like maximum payload size and whether attachments are accepted, and the queue group the agent has joined. Callers read these from $SRV.INFO rather than constructing them from identity, which means an agent can move subjects without breaking its callers.

Once a caller has an endpoint subject, prompting is one NATS request. The default subject pattern is agents.prompt.{agent}.{owner}.{name} — verb-first, so every endpoint type owns its own slot in the hierarchy and a wildcard like agents.prompt.> cleanly partitions all prompt traffic from everything else.

The agent answers by streaming typed JSON chunks back to the caller’s reply inbox. Each chunk is {type, data}:

Every stream — successful or errored — ends with the same signal: a zero-byte message carrying no headers. Errors arrive as a NATS micro service error-headered message (Nats-Service-Error-Code, Nats-Service-Error) immediately before the terminator, with an optional JSON body for structured detail.

That’s the entire conversation: typed chunks in publication order, ack first, terminator last.

For point-in-time liveness, every agent also exposes a status request/reply endpoint that returns the same payload shape as a heartbeat, freshly built on demand. A caller that just connected can bootstrap its liveness tracker without waiting up to a full interval for the next beat.

What the protocol actually pins down, beyond the three jobs:

The protocol is intentionally narrow. It doesn’t define how an agent thinks, what model it runs, how it persists memory, whether it uses tools, how it bills, or who pays. It doesn’t ship a runtime. It doesn’t mandate a framework. It tells you the smallest possible set of things an agent has to put on NATS so that the rest of the ecosystem can address it, prompt it, and notice it.

That’s deliberately the same shape NATS itself takes. NATS handles subjects, headers, and the request/reply contract, and leaves everything above that to applications. The agent protocol handles a subject convention, a request envelope, a chunk format, and a heartbeat, and leaves everything above that to agents.

The same way a NATS micro service today can be written in any language and consumed from any other, a compliant agent today can be a wrapped Claude Code session, a DSPy ReAct loop, a long-running daemon written in Go, or a one-shot Python script — and any caller that speaks the protocol can talk to all of them with the same code path.

Some pieces are deliberately deferred to keep the initial version small. A few of the areas we expect to touch in upcoming extensions of the protocol:

Reference SDKs in TypeScript and Python implement the protocol, but the NATS CLI can speak it by hand and anything else that knows the rules can join the conversation.