You talk to a leader.
It runs the team.
Neta delegates work to tiered worker agents and drives them until the problem is done. The leader never edits files — that restriction is enforced by your CLI's own machinery, not suggested in a prompt.
And it owns no session UI. You stay in Claude Code, Codex or OpenCode — the UI you already use and pay for. Neta injects instructions, tools and restrictions, then gets out of the way; the one surface it draws is the per-worker watch pane.
A lead, not an implementer
The leader reads, decides, delegates and verifies. Its edit tools are removed by the vendor's own permission system, and shell writes are blocked too — a leader with a way to edit eventually edits.
One writer per session
Reads parallelize; writes serialize. Each session has a single writer slot: a second writer is queued, not raced, and starts when the slot frees. A writer is told to commit everything before handing off, and a dirty handoff is called out loudly in its result.
Enforcement over instruction
Every restriction that matters is a mechanism: a permission rule, a hook, a kernel sandbox, a protocol rejection. A rule that lives only in a prompt is a suggestion.
Finish, then report
A CHARTER.md says which decisions the leader may take on your behalf. Inside that boundary it just does the work. Workers are quiet; only terminal events, blocking questions, and room posts the leader opts into push.
Tiers, not model names
you decide what each one costsThe mechanical floor: run a named command and report output, apply one exactly specified small change, or answer one bounded question about a named file.
Mechanical work with a precise spec: renames, applying a reviewed diff, running tests and reporting output. It only gets exact instructions.
Well-scoped features, bug fixes with tests, code review.
Ambiguity: unknown-cause debugging, design work, debates.
The leader asks for an apprentice, journeyman, expert or architect worker; you map tiers to backends in settings, and you can mix vendors — putting architect work on Codex while everything else stays on Claude. Unconfigured tiers spread deterministically across whatever you have installed, and reviewers prefer a different vendor than the last writer.
The leader cannot write
enforced by each vendor, not by usCodex's is the strongest — the kernel refuses the write. Claude Code relies on Neta's guard, which is a denylist, and a denylist can be incomplete. OpenCode denies bash outright and allows only read-only commands — an allowlist fails closed, but both are weaker than a kernel. That is worth knowing rather than papering over.
Workers you can take over
a pane each, and a door outA worker is an ordinary session of the CLI that ran it. neta attach rw3 hands the worker's own session id to that CLI's resume command and drops you inside the conversation, where you can read what it did and keep talking to it yourself. Neta drove it; you can finish it.
With Zellij or tmux, each worker also gets a tab streaming its log — prose as markdown, tool calls as one-liners, changes as coloured diffs, and an input line that talks to the worker. Panes read without consuming, so nothing shown there is taken from the leader. Without a multiplexer, workers run headless and nothing else changes.
Backends & playbooks
one ACP path, three vendorsEvery worker runs on a login you already have
claude-agent-acp — its own logincodex-acp — its own loginopencode acp, native — its own configDriven over ACP through one internal transport — one code path, not one conditional per vendor. Each worker launches with that CLI's own auth; whether that is a subscription or API credit is that CLI's configuration.
Flavors — playbooks the leader reaches for
Ordinary markdown you can override per project — as are the roles: scout, worker, reviewer, debater.
Working end to end, and young
what is verified, what isn'tRun it in a repo you know
Neta needs Node 22.19+ and at least one agent CLI on PATH. Nothing else to configure — tiers spread themselves across what you have until you say otherwise.