Anatomy of a Ring Zero Session

You're eight minutes from home. Traffic isn't bad. You speak into your phone using handsfree: "Queue a PR that adds a rate-limit header to the /login endpoint. Let me know if you have any design questions..."

Your phone confirms it caught the intent, then goes quiet.

By the time you're pulling into the driveway, the PR is filed. Tests pass. There's one small design question — should the header live in the middleware chain or the router itself? Voice comes through the car's speakers: "One question waiting; I can hold it or take it now."

You take it now. Say a sentence. The choice lands.

You get out of the car. Nothing else needs you tonight.

That's the shape of the interaction. What happens between "queue a PR" and "one question waiting" is what this post is about — the pieces that make that flow work, where they live, and why the shape has to be what it is.

The phone #

The phone is your gateway, not your compute. The actual work — the coding agents, Ring Zero, model calls — runs on your home server or a cloud instance, or both. The phone brings the microphone, the speaker, the touch surface, and enough browser to render whatever Ring Zero decides to show you. It's the always-with-you endpoint.

Most of what runs on the phone is a webview — HTML plus WebRTC for audio, Canvas and WebGL for richer surfaces. That choice is deliberate. The same shape works across phone, tablet, the car's browser, whichever device happens to render a modern web page. Your phone hits your Ring Zero instance directly — yours, not a shared multi-tenant service.

On Android there's a native wrapper around that webview, for the places where tighter OS integration earns its place: audio focus during a call, notification handling, background lifecycle. A desktop wrapper isn't there yet; if desktop integration ends up wanting closer OS access, it's the same pattern — wrapper on the outside, webview inside, with as much of the surface as possible staying in the webview so the same experience travels.

Under the hood, the browser is doing three things: streaming microphone audio to Ring Zero via WebRTC (STT happens server-side, not on the phone), playing back TTS when the system speaks, and rendering the chat interface for text fallback and history. The voice pipeline includes target-speaker filtering — it locks onto your voice specifically so a car's radio, a kitchen fan, or someone else talking in the room doesn't derail the interaction. When you're driving, the audio channels do the work. When you're standing in the kitchen with wet hands, same thing. When you sit down at the desk later to look through what happened, the chat interface is right there in the same tab.

This is the "untethered from your desk" pillar from an earlier post, in concrete form: your phone is the always-there endpoint. Everything else — the TV, the laptop, the paired second screens — is bandwidth amplification you call in when the moment needs it.

Ring Zero #

The voice comes in. Ring Zero has to decide what to do with it.

The first job is interpretation. "Queue a PR that adds a rate-limit header" is a code task. "Remind me to move the trash before work" is life admin. "How much did we spend on groceries last week?" is a research query. Different intents get different pipelines. Ring Zero holds the dispatch logic that sends each request to the right worker.

For code tasks, the next decision is which backend. Vibr8 talks to several — Claude Code, Codex, opencode, potentially others. Not all of them are equal at all tasks, and not all of them are equal in cost. A quick refactor of test names might route to a local model. A hard architectural change goes to a top-tier hosted agent. The routing is a policy, not a hard-coded assignment. As new agents arrive or old ones get better or cheaper, Ring Zero's dispatch table updates without touching what the phone does or what the second screens show.

Then Ring Zero spawns the worker in a fresh worktree. This is unglamorous plumbing that matters. Two parallel sessions can't share a working directory without stepping on each other's edits. Worktrees keep them separate. Ring Zero picks the branch, sets up the directory, hands the worker its assignment, and moves on.

Everything after that is happening in parallel. The worker is doing its work. Ring Zero is listening for state changes — did the worker finish, did it get stuck, did it hit a permission prompt, does it want your input on something. Ring Zero is also aware of whatever else is in flight: three other sessions from earlier in the day, a batch review queued for Friday, a status question from your last conversation that's still waiting for you.

The concern of the coding agent is the code. The concern of Ring Zero is you. Your focus, your calendar, your other sessions, the device you're on right now. That's a different kind of state, and it can't be held inside the coding agent because the coding agent has no reason to know any of it.

That framing was the point of last week's post — the orchestrator has to be a separate tier. This post is what "separate tier" actually looks like in pieces.

The worker #

The worker session — Claude Code, opencode, Codex, whichever one Ring Zero routed the task to — does the actual code work.

It reads the endpoint file. It thinks about where the rate limiter belongs. It writes the change, runs the tests, writes a commit message, and pushes the branch. If the tests pass and the code looks defensible to itself, it opens a PR with a summary of what changed and why. If the tests fail, it iterates until they pass or hits a stopping condition and flags for review.

This is what the vendors have gotten genuinely good at. Background sessions, agent teams with a lead, batch fan-out — the coding agents are solving the coding-work parallelization problem, and they're the right ones to solve it.

Ring Zero doesn't compete with any of that. It uses it. In this specific flow, opencode is the backend of choice — a deliberate priority for the v0.1 focus. Codex and Claude Code are wired in and available too. Post-v0.1, a plugin-based approach lets other backends slot in the same way.

Routing back #

The worker finishes. Now what?

That's the interesting question. In the naive design, the worker's output just streams back to the user — line by line, verbose, real-time. That's what happens today in most coding-agent tools. It's exhausting because it treats every unit of the worker's output as equally deserving of your attention.

Ring Zero doesn't do that. When the worker finishes, Ring Zero looks at the situation and picks a shape and a surface.

Still driving? Voice only. Condensed status: "PR filed, tests pass, one question waiting." No diff shown; there's no screen to show it on. If you have a question about the change, ask; the answer comes back the same way.

Home now, TV on in the living room? The diff goes to the TV. Voice for the one question: "Should the header live in the middleware chain or the router itself?" You look at the diff on the big screen while you answer.

Phone in your hand, walking through the house? Chat surface with the diff inline. Touch to approve. Voice if you'd rather.

In a focus block, doing something else that needs your full attention? Ring Zero doesn't interrupt. It batches with two other pending items and surfaces them Friday morning with your coffee, when you've told it that's a natural review time.

This is what "modality-elastic" turned into. The system reads the moment — which device is active, whether you asked for silence, what the calendar says, whether you can see or only hear — and picks the surface that fits. And the intelligence isn't just choosing a channel. It's translating between them. The verbose text stream that the coding agent naturally produces is not what your voice channel needs; another agent inside Ring Zero condenses it into voice-suitable dialog. The same content becomes a two-sentence spoken status, a diff on the TV, a widget in the browser — depending on where you are and what the moment can support.

That's choreography, in the language of the framework from two weeks ago. Modality routing is choreography made concrete.

State #

None of that routing could happen without state no single worker session holds.

Ring Zero knows: which sessions you have active right now (three PRs in flight from three sibling workers, all awaiting some kind of response from you); which of those sessions are in the foreground of your attention right now versus which are running in the background without needing you (a coding session you're actively talking to versus two others running their own tests without interrupting); what your focus hours are (either declared explicitly or learned from calendar and behavior); what your trust rules say (auto-approve edits inside the worker's own worktree; ask for anything that touches the network or deletes; never auto-approve anything that spends money or touches secrets); which device you last engaged with and how (voice on the phone at 4:47pm; touch on the TV at 6:02pm); what your history of decisions looks like on similar past cases.

Foreground versus background matters more than it sounds. If you're actively talking to session A about a refactor, session B finishing its tests shouldn't hijack your attention — it should batch. If A stops needing you and B needs you, Ring Zero moves B to foreground. The whole point of the tier is that this switching is Ring Zero's job, not yours.

That state doesn't fit inside a coding-agent session. It's a different kind of state. A coding session's state is a repo, a diff, a test run — held for a few hours at most, updated by tool calls. Ring Zero's state is you — held for months, updated by signals no coding session ever sees. Try to shove both kinds of state into a single execution agent and you get the pathologies you've felt: chatty voice output (the agent doesn't know it's talking to a phone in a car), permission prompts on every action (the agent doesn't know which rules you've already declared for this kind of task), no cross-session visibility (the agent doesn't know its siblings exist).

Ring Zero is the tier that holds the "you" state. That's what makes it a different kind of agent, and that's why it has to live where it lives.

What's built, what's rough, what's coming #

Some of this is real today. Some is rough. Some is coming.

Built: the voice pipeline through Ring Zero works — STT on the way in, TTS on the way back, streaming through the phone browser. Second-screen paired-display support works — when voice or the phone's screen isn't enough bandwidth, Ring Zero can push a diff, a widget, or a richer view to a nearby TV, tablet, or browser. Claude Code and opencode are wired in as workers. Ring Zero's session dispatch and worktree management works end-to-end. Node-to-hub re-pointing is validated — you can move a Ring Zero instance between environments without state corruption. CPU-only installs work; voice E2E validated on a cloud instance. Side-by-side instances run without stepping on each other. The infrastructure to run your own instance at a subdomain — DNS + Caddy + auto-renewing SSL — takes a couple of hours to wire up cleanly.

Rough: multi-backend dispatch is uneven; opencode and Claude Code are priority one for v0.1, Other backends need a plugin story that isn't there yet. Permission-rule tuning is manual. Some install paths need polish. Documentation lags scripts by a few days at any given moment.

Coming: more backends post-v0.1. An iOS wrapper (same OS-integration considerations as Android; matters for reaching most of the Apple-side audience). Cleaner install. Ring Zero responsiveness improvements (the car-and-commute demo wants sub-second time-to-first-speech). And a direction that's forming but not yet built — see the close.

Coming next #

Four posts, one shape.

The vision was that AI would become an elastic interface, taking whichever modality the moment allows and translating between them. The framework was that any orchestrator worth using optimizes across three axes at once — bandwidth, attention, choreography — and the interesting design work is doing all three, not just one. The principle was that the orchestrator has to be a separate tier from the execution agents; it can't live inside them. This post was one specific system built around all three of those ideas.

Where this goes next is the packaging problem: how do you bundle up "a bot-like facility" as an installable, versionable, upgradeable thing? The life system I use to run my day, the software factory pattern from two posts ago, a code-while-commute session — these all feel like instances of the same primitive. That's the direction post-v0.1.

Interested in being a beta tester when Ring Zero (vibr8) is released? Sign up for the mailing list now.

Follow along at storminthecastle.com — v0.1 ships end of October — or reply if you're building in this space.

• Previous: Ring Zero: The Meta-Agent for Coding Agents