Ring Zero: The Meta-Agent for Coding Agents

The wall you hit #

You've tried it. Voice pipeline on top of your favorite coding agent. STT feeding the session, TTS reading output back. It was kind of working. Then it started fighting you. The output stream was too verbose for voice. You couldn't parallelize — one interactive session, and it wants your attention. Step away from the keyboard and permission prompts pile up unanswered. Background it and you can't tell what any of the sessions are actually doing. Every fix creates a new hole.

Coding agents were built around one dominant assumption — a developer at a keyboard, watching output stream, approving each step — and everything about how they surface information, request permission, and hold session state cascades from that assumption.

This isn't a missing feature #

Nine months ago you could argue coding agents were single-session tools. Not anymore. Background sessions. Worktrees. Subagents. Agent teams with a lead, a shared task list, and a mailbox. Batch commands that fan a change out across a repo. The parallelism problem, as the vendors define it, is getting solved.

And the complaints haven't changed. Same week, same feed. One agent is magic; four in parallel is frozen laptops, silent overwrites, and no idea what any of them are doing. It still feels like watching. People describe themselves as the memory layer between four different agents and ask whether adding a fifth would help. The recurring phrase is some version of it gives me a headache by the end of the day.

Look at those two lists together. Every complaint has a feature that nominally addresses it. Parallel sessions have a dashboard. Background mode exists. Permission modes exist. The pain survives the feature — because every feature is the same shape. Another stream. Another session to check. Another command to know. Visibility got defined as a dashboard of streams. That isn't visibility. Visibility is deciding what you actually need to see.

Diagnosis #

In last week's post I argued that attention is the scarcest input in the system, and that every human-agent interaction is optimized (or not) along three axes: bandwidth when attending, attention required, and the choreography of the exchanges that do happen.

Coding agents raised the bandwidth ceiling. Natural language in, natural language out — the highest-bandwidth interface most developers have ever had. What they didn't do is anything about fit. More information, same receiver. That's why they feel powerful and why they feel exhausting; it's one fact, not two. Raising the bandwidth ceiling is precisely what made attention and choreography the dominant cost.

So the orchestrator's job isn't dispatch. Dispatch is a for loop. The job is translation: taking what the system produces and reshaping it into what your attention can efficiently receive — per modality, per moment, per what else is going on. Batching what can wait. Interrupting for what can't. Condensing a verbose stream into "PR filed, tests pass, waiting on your review," or into a widget on the nearest screen, or into a Friday summary alongside two other sessions' output.

The execution agent's context is the task. The orchestrator's context is you.

Why that can't live inside the coding agent #

Those are different kinds of state. A task is a repo, a diff, a test run — held for hours, updated by tool calls. A person is which device is closest, whether you're driving, what's in focus hours, what else is in flight, what you decided last time this came up — held for months, updated by signals no coding session ever sees.

Put the second kind of state inside an execution agent and you get the pathologies you've already felt. Chatty voice output, because the agent doesn't know it's talking to a phone in a car. Prompts on every action, because it doesn't know what you've trusted before. No cross-session visibility, because it doesn't know its siblings exist.

Three things follow, and they're prerequisites for the real job, not the job itself.

It has to see every session #

Personal orchestration is fundamentally multi-session. You dictate a batch before dinner; seven sessions spin up; one gets stuck, one takes a file another wanted, one finishes clean and files a PR. How those seven get coordinated as coding work — worktrees, a shared task list, a lead session — is a problem the coding agents are increasingly solving for themselves, and Ring0 is happy to let them. What it needs is different: deciding which of those seven things you need to hear about, when, and in what shape. That requires state held above the sessions. Not one vendor's sessions. All of them, including the ones the coding agent spawned on its own.

It has to be outside the session it observes #

The tier above has capabilities no session has: read any session's history, send a command into one ("pause, switch to this"), subscribe to state changes across all of them (blocked, waiting-for-review, errored), and act on cross-session state. These require being outside the thing observed. Build them into a specific coding agent and they only ever work for that agent's own sessions — which brings us to the third.

It has to be backend-agnostic #

Claude Code is Anthropic-specific. Codex is OpenAI-specific. Cursor is Cursor. opencode is model-agnostic with its own conventions. Each has its own permission model, output format, session API. Wrapping them behind a common interface buys portability (bulk cleanup to a local model, hard refactors to a frontier one), best-tool-per-task, and insulation from any one provider changing its pricing or terms under you.

Some of this plumbing exists. Agent-client protocols and parallel-session managers are real and useful. They're the substrate. The part that's still missing is the layer above them that knows you.

Won't the vendors just build this? #

They're building something, and it's worth being precise about what. Agent teams, background sessions, batch fan-out — these are orchestration in the sense of parallelizing the coding work. A lead plans, assigns, and supervises workers; changes get merged; conflicts get resolved. That's a coding problem, and the vendors are the right people to solve it. Ring0 should use it, not compete with it.

What none of that touches is the attention problem. The vendor orchestrator's "you" is still a terminal user. Its notion of visibility is still a dashboard. It has no idea whether you're driving, whether it's your focus block, or that two other tools have things waiting for you too. It manages the sessions. Nothing manages you.

So from Ring0's point of view, an agent team is just a bigger worker. Ring0 hands it a task the same way it hands one to a single session, subscribes to its state changes, and doesn't care how it divides the work internally — the way a window manager doesn't care how an application schedules its own threads. The vendors can get as good at parallel coding as they like. That makes Ring0's job easier, not redundant.

Ring0 #

Ring0 — named for ring 0, the most privileged ring on x86 — is the layer that sits above the coding agents in vibr8. The name is deliberate. It's the layer trusted to act on your behalf, which is a different kind of trust than "edit files in this worktree."

It receives voice input, routes intent, dispatches to worker sessions (Claude Code, opencode, whichever), and translates results back into whatever shape and modality the moment demands. Its concern isn't the code. It's your focus hours, your active session set, your trust history, your calendar, the room you're in, the device that's closest.

The capability surface:

• Voice pipeline — STT/TTS goes through Ring0; coding agents never touch audio
• Modality routing — voice on the phone, a screen on the TV, chat in the browser, whichever surface is closest and appropriate
• Session dispatch — spawn workers in worktrees, run them in parallel, across backends
• Cross-session observation — Ring0 knows what session A is doing while you talk to it about session B
• Permission handling — respond on your behalf via declared rules

That last one deserves more than a bullet, because it's where this goes wrong if you're not careful.

Permissions #

"Responds on your behalf" reads as an auto-approve button with a nicer name. It isn't, but the difference is entirely in being able to learn and apply your preferences and guardrails on a project by project basis. Every decision Ring0 makes on your behalf is logged, and the log is reviewable in the same batched shape as everything else. Trust history adjusts thresholds within the "ask" tier over time — it never moves something out of "never." This helps to impart your taste... your style... your world view... onto the automated workflows.

The architectural principle #

The orchestrator has to be a separate layer from the execution agents. Not a feature of one of them. Not a plugin inside one of them. A layer of its own.

The reason is what a layer is. A layer is a context that can apply a transformation to what the contexts below it produce. The coding agent's context sees tool calls, diffs, test output — and it should; that's what it's good at. The context above sees the same events at a different abstraction: seven sessions as one batch, a verbose stream as a two-sentence status, three pending permission prompts as one decision, a finished PR as something that can wait until Friday. It maps from one modality into another for your consumption. It organizes what has happened so that your next interaction costs less. Those views don't exist at the session level. Not because the coding agent is deficient, but because it's the wrong vantage point — and no amount of feature work at that level will produce them.

The window manager exists because applications can't see each other. Ring0 exists because coding agents can't see you. Each layer earns its place by the transformation it can apply that nothing below it can. If you find yourself squeezing that transformation into a coding-agent plugin, you're going to hit the same wall, for the same reason: the plugin lives in the wrong context.

Get updates like this. Occasional, low-cadence, real-news-only.

Follow along at storminthecastle.com — or reply if you're building in this space.

• Previous: Software Factories