Agent Fleets Push NATS From Plumbing Toward AI's Coordination Layer

Messaging systems have spent most of their lives as background plumbing. Agent fleets are changing that. When thousands of short-lived sandboxes spin up and down and software agents pass work between each other, the messaging layer stops being a quiet dependency and starts deciding whether the whole system holds together. That's the argument coming out of a recent discussion with two maintainers of NATS, the open-source system that lets applications and services exchange messages by topic.

Why ephemerality breaks old assumptions

Most infrastructure was tuned for workloads that stick around. Servers and services connect, stay connected for a long time, and change slowly. AI-driven systems don't behave that way. Andrew Connolly, a NATS project maintainer at Synadia, which provides managed NATS services, put the problem plainly: "Everything is really ephemeral. If you take the Lovable example, connections coming and going really fast, tons of churn, tons of sandboxes, all these things spinning up, spinning down. Not every technology can handle that."

Lovable, an AI tool that turns a plain-language prompt into a working web app, is the example Connolly keeps returning to. Every generated app wants its own short-lived environment, and every environment needs updates delivered to it reliably while it exists. Multiply that by many users and the messaging layer is handling connection setup and teardown at a pace that steady-state designs never had to absorb.

Here's the thing: that churn is a different load profile, not just a bigger one. Systems optimized for long-lived connections can spend a surprising share of their effort on bookkeeping when connections keep appearing and disappearing. The question for teams running agent workloads is whether their messaging substrate treats that bookkeeping as cheap.

From single cluster to multi-region fabric

NATS has moved well past its original footprint. Waldemar Quevedo, also a project maintainer at Synadia, described how the system now spans data centers, regions and clouds. "NATS has evolved to be able to communicate multiple data centers with a super cluster topology with the gateways," he said. "It is smart [at routing] the interest graph out to multiple regions, multiple availability zones, multi-cloud."

The interest graph is the part worth paying attention to. Rather than broadcasting everything everywhere, the routing layer tracks which subscribers care about which subjects and forwards messages only along those paths. That matters when a message needs to reach a handful of agents in one region and telemetry needs to reach monitoring in another, without either flooding the other.

Scale is the other proof point. Quevedo noted that one AI app builder recently rebuilt its real-time service on NATS to serve millions of subscriptions. Subscription count is a more demanding metric than message throughput alone, because every open subscription is state the system must hold and route correctly as clients come and go.

Three jobs NATS is taking on in AI infrastructure

The use cases described fall into three groups. The first is infrastructure telemetry. Some data center operators use NATS to carry power and cooling data, which is continuous, high-volume and time-sensitive. Nvidia built its AI factory event bus on NATS as part of its DSX reference architecture, according to Connolly. For an organization building GPU-dense facilities, a shared event bus for physical and operational signals is a sensible place to standardize.

The second is sandbox workloads, covered above. The third, and the most specific to agents, is handoff. NATS can route messages across fleets of AI agents, and two components do the heavier lifting. JetStream, its persistence engine, retains messages so a consumer that drops out can pick up where it left off. The key-value store holds the state an agent needs to pass work to another agent. Together they let a task move between workers without the sender and receiver needing to be online at the same moment.

Connolly's framing is that this isn't a new category of problem. "In some sense, agentic systems are just microservices systems, but at a bigger scale," he said. "NATS was good for microservices. It's going to be great for AI agents." I'd read the first half as the more useful claim. If agent orchestration is largely a microservices problem with different failure modes, teams already running event-driven architectures have a head start, and the open questions shift toward scale and state rather than whole new design vocabularies.

What to pressure-test before adopting it this way

Several caveats are worth holding onto. The perspective here comes from maintainers, and one of them works for a company that sells managed NATS, so the framing favors the system's strengths. Persistence through JetStream and key-value state adds operational responsibility: someone has to size storage, manage retention and understand what happens during partitions between regions. Multi-region routing via gateways is powerful, but it also means the topology decisions made early become expensive to revisit.

Teams evaluating messaging for agent fleets should probably test three things: how connection churn behaves at the rates their sandboxes actually produce, how interest-based routing performs when subscriber counts climb into the millions, and how agent handoff recovers when a worker disappears mid-task. Those tests will tell more than any architecture diagram.

NATS graduating from the Cloud Native Computing Foundation in November 2026 signals that the project is being treated as production-ready infrastructure for this kind of load, according to the foundation's own announcement. My read is that the more interesting shift is conceptual: the messaging layer is moving from something you configure once to something that determines how agents find each other, share state and recover from failure. Watch how the next wave of agent platforms describe their coordination layer, because that's where these choices are going to get made.