The human in the loop for a swarm of agents

Something changes when you stop running one coding agent and start running several. One Claude Code in a terminal, a second refactoring a different package, a background reviewer, a Cursor window on a third thing. Each is fast. The system is not — because the moment any of them needs a decision, it waits for the same scarce resource: you, noticing, context-switching, and answering.

Add more agents and you don’t get more throughput. You get a longer queue at a single checkout lane. The bottleneck has moved off the machines and onto the one human they all depend on. That is the real unsolved problem of multi-agent work, and it is an attention problem before it is a coordination problem.

The tempting wrong answer: “build a bus”

The obvious reframing is: if there are many agents and a human, they need a shared channel to talk — a message bus — and the human plugs into it. And since OpenWhisp already sits between agents and the person, maybe OpenWhisp is that bus.

We want to argue against that, out loud, because it’s the version of this idea we find seductive and think is a trap.

• A bus and a consent gate are opposites. Everything that makes a local agent bridge trustworthy is about isolation: a private per-connection channel, signed clients only, per-scope consent, no way for one agent to reach another through the trusted process. A bus does the reverse — its whole job is to route messages between parties. The instant OpenWhisp relays Agent A’s message to Agent B, a prompt-injected agent can reach other agents through a process that holds microphone and accessibility permissions. You’d be dismantling the isolation to add the routing.
• A bus is a commodity; a voice endpoint is not. If agents just need pub/sub to talk to each other, that problem is crowded and unspecial — a queue, a shared file, an orchestrator, an agent-to-agent protocol. None of it needs a microphone or on-device transcription. Competing there means fighting on plumbing where OpenWhisp has no advantage.
• It quietly turns you into a different product. A bus is always-on, stateful, and long-lived. Bolt that onto a dictation app and you either lose the “costs nothing when it’s off” property that your main audience relies on, or you grow a second product wearing the first one’s clothes.

The better frame: be the node, not the wire

Here’s the thing OpenWhisp can be that almost nothing else can. It already owns the highest-bandwidth human input channel on the Mac: the microphone, the on-device transcription, the overlay, and the hard-won system permissions behind them. When an agent needs a person, “ask by voice, the human answers by voice, keep working” is simply a better interaction than a typed question rotting in a terminal nobody is looking at.

So the role isn’t the bus. It’s the endpoint where a swarm of agents reaches the human — the star at the center of the diagram, not the mesh between the points. Whatever coordination layer wins between agents, they all still need one thing OpenWhisp is uniquely placed to provide: a fast, private, voice-first way to reach the person. Stay an endpoint. Let someone else build middleware.

What this could look like

Three directions follow from “be the node.” None of these exist yet; they’re where the thesis points.

1. A star, not a mesh

Every agent gets its own private, isolated, human-mediated channel to you. Many agents can each independently ask you things; none of them can reach each other through OpenWhisp. This is most of the value of “human in the loop for a swarm” — and it doesn’t require breaking any of the isolation the bridge is built on.

The genuinely new problem is multiplexing: five agents wanting your attention at once. But that’s a UI problem, not a message-routing one — a small queue of pending questions in the overlay, each tagged with the agent that asked, that you clear by voice one at a time:

┌─ agents waiting on you ───────────────┐
│ ● claude-code (api)  deploy target?   │  ← you answer
│ ○ reviewer           ok to force-push?│
│ ○ cursor             which schema?     │
└───────────────────────────────────────┘
   speak your answer · it routes to the one asking

2. Let the orchestrator route; you voice the human step

In real multi-agent setups there is already a coordinator — a lead agent, a workflow runner, something that spawned the others. That is the bus. OpenWhisp’s job is to be the tool that coordinator calls at the one step in its plan that needs a person. You never route between agents; the orchestrator does, and it reaches for a voice channel at the human-decision node. This keeps OpenWhisp a leaf and lets it ride whatever orchestration layer wins, instead of betting on one.

3. If ever more than a leaf, be the audit surface — not the transport

The one “bus-like” thing that actually fits is observability of the human moments: a local, private, searchable record of every decision a person made across all their agents — what you approved, when, and which agent asked. Those interactions happen on your machine, which makes it something a cloud orchestrator structurally can’t own. That’s still an endpoint feature, not a transport feature.

Why we’re confident about the shape, if not the timeline

OpenWhisp is open source and local-first by construction. The current Agent Bridge is already a private, signed, consent-gated, per-agent channel on your Mac — which happens to be exactly the primitive a star topology is made of. Getting from “one agent can ask you a question” to “a swarm of agents queues for your attention, one calm voice channel” is additive. It doesn’t ask you to trust a new network service or hand a cloud a log of your decisions.

The one-sentence version: being the place agents reach the human is a moat we mostly already have; being the wire agents reach each other on is a commodity we’d have to demolish that moat to build. So the plan is to build the star, let someone else build the mesh, and be the node they all have to route through.