What Are the New Assumptions for Communication Infrastructure in the Agent Era

Continuing from the previous post: a16z's view is that AI changed the design assumptions underlying software. The current generation of databases, messaging, and storage were all built on old assumptions and need to be rebuilt.

Let's take that view as correct for now, without debating whether it holds. If it does, the useful question isn't "where did the old assumptions go wrong." The old assumptions weren't wrong — they were right for their era. The useful question should be: what are the new assumptions in the AI era? Only by identifying the new assumptions can we know what to build on. What follows is a record of reasoning through that question.

First, let's set aside symptoms. Throughput is no longer the bottleneck, latency is no longer worth obsessing over, traffic has become bursty and recursive — all true, but these are consequences, not the assumptions themselves. We're looking for the assumption that, once it changes, everything else changes with it. Tracing backward, we land on one point: the endpoint.

Old Assumption: Endpoints Are Dumb

The foundational software of the past several decades — brokers, databases, RPC systems — all default to a particular notion of an endpoint. It is dumb: intelligence is elsewhere; it's just a pipe. It is cheap: a connection is lightweight for the system. It is stable: once started, it stays up indefinitely. It is deterministic: behavior is hardcoded, predictable.

Messaging systems get messages from A to B. Who A is, what B is doing, whether it can be trusted — none of that is their concern. The engineering difficulty therefore fell on the data plane, on moving ever larger volumes of data ever faster. These assumptions were correct for their era. The engineering genius of Kafka and its generation was built on them.

New Assumption: Endpoints Are Agents

Agents replace all four of these. An agent is intelligent — it makes its own decisions, will fan out more calls as needed. It is expensive — each response involves an inference, measured in seconds and dollars. It is ephemeral — started on demand for a task, gone when done, reconnecting at any time. It is non-deterministic — the same input doesn't guarantee the same behavior, and it will fail in ways you didn't anticipate.

Intelligent, expensive, ephemeral, non-deterministic. This is what endpoints look like in the AI era. It's also what we believe is the assumption that actually changed.

Following the New Assumption to Its Conclusions

If endpoints are truly like this, reasoning forward, several things change with it.

The first is where the bottleneck sits. Endpoints are cheap enough to spin up in massive quantities — numbers grow from thousands to millions — but each endpoint carries low traffic. The difficulty therefore shifts from "how much data can a single channel move" to "how to manage the existence, state, and location of enormous numbers of endpoints." The scarce resource is no longer throughput; it's the ability to maintain order across large numbers of highly mobile endpoints.

The second goes deeper: responsibility boundaries. In the dumb-pipe era, discovery, reliability, tracing, and control were all left to the application layer — each team assembled their own version as needed. Once endpoints become agents, these things can no longer stay fragmented; one by one they get pushed down into the infrastructure.

Agents are dynamic — you can only find them by what they can do, not by a fixed address, so discovery must be a foundational capability. Every message carries an expensive, potentially long-running task behind it, and the endpoint may go offline mid-task, so delivery must be reliable, persistent, and replayable — losing one message means a few minutes of work wasted.

A request and its result — which might not come back for minutes — need to be correlated; long-running task state needs to be trackable. Agents are intelligent and non-deterministic; they will take unauthorized or harmful actions, so the infrastructure must be able to see and control them — something a dumb pipe never needed to do.

The Core of mq9

Following this line of reasoning, the conclusion becomes clear. The new assumptions require infrastructure to natively do four things: make agents discoverable (discovery), reliably reachable (durable mailbox), trackable (correlation), and controllable (identity + interception).

So mq9's core isn't "a better message queue." It's taking these four things — previously scattered across the application layer, each team assembling their own version — and sinking them into the foundation as primitives. One broker, one SDK: what you get isn't transport capability, it's a complete set of "agent coordination" capabilities.

Of these four, discovery and reliable delivery are the foundation — do them well and there's immediate value. The genuinely hard and genuinely important ones are the latter two: tracing and control. They require the broker to understand that what flows through it isn't a sequence of bytes, but a stateful, bounded thing an agent is doing.

These Are Still Assumptions

To be clear: every step from "the endpoint changed" to the conclusions above is still an assumption, not a conclusion. Whether this is the assumption that actually changed, and whether the downstream implications look exactly like this — all of this needs validation against real workloads.

We're building mq9 and running it inside real Agent systems precisely to see where this thinking holds and where it needs revision. If you're also working on Agent-to-Agent communication, let's figure these questions out together.