Why we stopped saying multi-agent coordination

For about a year, we described what we were building as a multi-agent coordination layer. It was technically accurate. It was also, we eventually realised, the wrong pitch.

This is a short note about why — and what changed when we stopped.

The problem with the pitch

Three things, mostly.

One: almost nobody is actually running multi-agent systems in production yet. Some teams are. Most are not. Most teams are building one agent, sometimes two that don’t talk, and trying very hard to get that into production without it falling over. Selling them coordination is selling for a future they have not yet hit.

Two: the phrase pattern-matches to the wrong drawer. When a developer hears "multi-agent coordination," they reach for frameworks — LangGraph, CrewAI, AutoGen, Mastra. Not infrastructure. So we kept getting filed alongside SDKs we don’t actually compete with. The conversation would start in the wrong place and we’d spend the first ten minutes correcting it.

Three: it understates the product. Multi-agent coordination is a thing our runtime supports. It is not the most important thing it supports. The most important thing is making one agent proactive. Multi-agent comes for free once shared state is real-time — two agents watching the same workspace is a multi-agent system, mechanically — but it’s the second-order story, not the first.

What we say now

We say we build proactive agents. The runtime is a proactive runtime. The product is the runtime.

This sounds like a small thing. It is not.

The first thing it does is rename the market we’re in. Reactive agents are the dominant pattern; everyone shipping an agent has a reactive one and is, on some level, embarrassed about it. The phrase "proactive agent" picks a fight with that pattern. It says here is what your agent should be, and here is what it currently is, and here is the gap.

The second thing it does is admit that single-agent customers are still the bulk of the market. They become first-class. A team building one agent that needs to be triggered on schedule, on data change, and on message? That’s a proactive agent. They get the runtime. Multi-agent is what happens later, if ever.

The third thing it does is make the architecture — the thing we already built — legible. The repos finally tell the truth:

| Old framing | What it actually is | |---|---| | Scheduling service | The clock | | Integration filesystem | The watcher | | Headless Slack | The inbox | | Hosted control plane | The runtime | | Workflow reliability | The durability ring |

Nothing about the code changed. The names changed. The story changed. The conversation changes too.

What we kept

We kept everything technical. None of the actual product changed. Pricing didn’t change. The ICP didn’t change. The integrations roadmap didn’t change.

What changed is which sentence comes first.

Old first sentence: We’re a multi-agent coordination layer for cloud agent products.

New first sentence: We make agents proactive — schedules, triggers, watchers, durable wake/sleep. Framework-agnostic.

The old sentence asked the listener to imagine a system they don’t have yet. The new sentence describes the agent they’re writing right now and the next thing it needs.

What we’re betting on

We’re betting that proactive becomes a category the way frontend cloud became a category — by being the obvious word for a thing developers were already trying to do, and by being unowned at the moment we plant the flag.

There’s a 2024 paper from Tsinghua and Huawei that uses the word proactive in exactly the sense we mean it. There’s an empty slot in dev tooling for someone to be the proactive runtime. There’s a body of work we’ve already shipped that maps onto the concept one-to-one.

The flag goes here. Multi-agent coordination is what it’s standing on.