VOX OS: personal AI operating system architecture

VOX OS is AR Labs' design for an operating layer over AI agent work: an architecture for a personal AI operating system in which one person can see, order and steer many AI agents (language models run in a loop with tools, so they can act as well as reply) and the tasks they are working on, without opening each agent's conversation to find out where things stand. It treats all of our work as one task graph, draws that graph in the terminal and the browser, and hands well-described tasks to coding agents, AI agents that write code, such as Claude Code and Codex. Several of its parts are working tools; the whole is a design. This page is for engineers and anyone supervising agent work, and describes what VOX OS is for, how the parts fit together, and which parts exist today.

What it is for

We run most of our engineering through agents. As the number of agents grows, the hard part is knowing what each one is doing, what is waiting on a person, and what should happen next. Agent conversations produce a great deal of text, and reading it is the slowest way to answer those questions.

VOX OS answers them from recorded state instead. Every piece of work is a bead: one tracked task in Beads, Steve Yegge's open-source issue tracker for coding agents, which stores tasks as a tree of parents and children with dependency edges between them. All the tracked tasks and the dependencies between them make up the task graph. The design has a person work from views over that tree: the whole portfolio, one line of work, a single task, and the agents running now. Voice is meant to become the main input and each task a place where an agent can be opened, steered or closed. Neither of those is built yet.

How the parts fit together

The system map stacks the parts in four layers: presentation, orchestration, execution, and the data underneath. Solid boxes are built and in use, dashed boxes are designed but not built, and the parts marked rented are other people's tools used as they come.

• Beads and git hold the state: tasks, dependencies and each task's position in the coding pipeline in Beads, code and documents in git. Nothing else is a store of record.
• Taskgraph works out where a branch of the work stands and what comes next, and prints it as JSON so every view shows the same interpretation.
• VOX Torch (terminal) and Vox Canvas (browser) draw the task graph and Taskgraph's maps. Both also read Beads directly, along with the records of running agent sessions, and Torch stores nothing of its own.
• The goal map places every project and the agents working on it on one interactive page.
• Coding Planner takes a feature from idea to merged code, running each step as a fresh agent session; the software factory is our design for running many of those agents at once.
• gc-torch is a sibling terminal view over Gas City, Steve Yegge's public agent orchestrator, which we run as an experiment.
• The resident agents are long-running agents with their own roles, such as a marketing manager, that live on a server and talk to us through a shared mailbox and a chat workspace.

Each of these has its own page.

Design principles

Build the supervision layer, rent the rest. We build the presentation and orchestration layers, the interface through which a person sees and controls agent work, because we expect that to stay hard while much general agent tooling becomes commodity. We rent the execution substrate: agent sessions (tmux with Claude Code or Codex inside), task state (Beads), networking (Tailscale) and code hosting (GitHub). Our interface sits over these rented layers and does not reimplement them.

Graph engineering. We design our work and our agent system as one dependency graph. Each node has one job, structured input and output, and a failure state; an edge is a real dependency that carries something, and sequence alone is not a dependency. State is durable, so the graph can say what happened and where work can safely resume. The graph engineering page sets out the full set of rules.

Derived, never stored. Whose turn it is and what the next action is are worked out from the task graph each time, never kept in a separate status field. A status field that depends on someone updating it goes stale.

Trust sets the pace. The coding pipeline, the route every code change takes (spec, test-first build, second-model review, a person's merge), runs one agent at a time, and a person merges to the main branch. Running more agents in parallel is designed but waits until the single-agent process has earned it.

The target architecture

The design separates three layers of responsibility. Presentation is what a person sees and speaks to. Orchestration is how agents are managed: each task as an agent context, the agents' lifecycle, and the intent behind each task re-delivered to the agent working on it. Execution is what runs: agent sessions, builds and deployments.

It also separates where things run. Every surface and agent reads and writes one data store, which is Beads today. A planned intelligence plane, an agent with our context loaded and reachable over an HTTP API, would let web, phone and voice interfaces reach one shared brain; simple reads and writes would bypass it and go straight to the data.

The design also names a vendor-neutral runtime: work to keep the same context, skills, operating rules and ongoing work usable from more than one agent program, such as Claude Code and Codex, and from product repositories outside the lab's own. The agent programs execute; they do not own the work or its meaning. Part of this already holds in the coding pipeline, where the reviewer always runs on Codex and the spec author can be chosen per task. Carrying a piece of work across from one agent program to another is the goal, not yet shown to work.

A further layer of design covers how agents hand work to each other. A thread is a durable line of work that outlives any one device, session or model; a seat is an organisational role, such as strategy or engineering, filled for a time by one agent; and a handoff is the explicit record made when work crosses from one seat to another, carrying decisions, open questions and the exact next action. This model is at the design stage. Coding-pipeline workers stay fresh for each step instead of holding a seat, so that each step depends only on recorded state.

What exists today

Built and in use on our own work:

• Coding Planner, which has run unattended, one agent at a time;
• Taskgraph, whose first release is a tested command-line tool in its own repository;
• VOX Torch, a read-only terminal prototype over live task data;
• Vox Canvas, a local browser viewer over the task tree that draws Taskgraph's maps;
• the goal map, generated from a sweep of running agent sessions;
• gc-torch, whose snapshot client and screens are built;
• resident agents running as services on a server, with a verified message round trip between a local coding session and the marketing manager agent.

Designed but not built: running several coding agents at once with a merge queue; launching agents from Torch; making the task graph reachable from every machine (the chosen design is one writable database server with a read-only copy on the laptop for offline viewing); the intelligence plane; the phone app and voice input; the thread, seat and handoff model; and an associative memory layer over our documents.

VOX OS is a design, not an integrated product, and is not offered as one. The parts are working tools we use on our own work, and the design sets the order in which the rest would be built.

How it was built

VOX OS grew out of earlier attempts to run several agents on one codebase. An early design coordinated agents through Beads plus an agent-to-agent mail system. The mail layer did not give reliable coordination, and we concluded that shared, observable state matters more than messaging. A survey of the agent-orchestration field in September 2026 found tools that manage sessions, orchestrators that run agent teams over a task graph, and pipeline factories, but no single tool that was a complete factory. Every credible report put the ceiling on throughput at checking and landing work rather than at the number of agents. That finding shaped the design: we keep our own coding methodology, borrows design from outside systems where it is good, and spends its effort on the supervision interface joined to the dependency graph.