Your agents got fast. Your workflow didn't. OTTO is the suite around them — parallel work in isolated checkouts, review wired into every handoff, and a session that remembers what was decided. Volume goes up. Accuracy holds, because nothing lands without a step that checks it.
THE PROBLEM, IN THREE LINES
One terminal, one agent, one thread. You sit and watch a single agent think, and when it finishes you paste its output into the next one by hand. You are the message bus, the scheduler, and the merge queue.
Agents are cheap and parallel. Attention is expensive and serial.
Every design decision in OTTO follows from that line.
01 · THE GRID
Nothing here is a wrapper or a re-implementation. It is the agent you already use, with its full TUI, in a pane you can type into. Split horizontally or vertically, up to sixteen.
02 · ISOLATION
Sixteen agents editing one directory would overwrite each other silently — no conflict, no error, no warning. So every terminal gets its own worktree and its own branch. That is not bookkeeping OTTO does carefully; it is git's own guarantee.
An agent that did nothing leaves no branch behind. An agent that committed keeps its work.
03 · WORKFLOWS
Each node is an agent with its own role, brief, required reading, scope and limits. Each named outcome it can finish with is an outlet you wire to whatever happens next — including back to an earlier node.
A DAG can't express the thing you actually want: the reviewer rejected it, so go back to the builder. A workflow is a walk — run a node, read its outcome, follow that edge.
Returning to a node resumes that agent's session and passes only what changed — a reviewer's second pass doesn't start from a blank slate.
Drop into the exact live terminal the agent is running in and type at it. Hand the run back to the workflow on any outlet.
Backend and model are per node. Every field is editable in the app — never by hand-editing JSON.
04 · PERSISTENCE
Workspaces, pane layouts, workflows, run history and the agents' own transcripts follow you. A workspace is identified by its git remote rather than a filesystem path — so the same project resolves wherever it happens to live.
Verified, not assumed: an agent taught a fact on one machine recalls it on another. In build now — carrying local-only commits and uncommitted work across machines too.
Hold a key. Talk. The focused agent receives it as text — or broadcast the same instruction to a selected group. Punctuation and code identifiers handled properly, so you are not correcting the transcript.
Most productivity claims are vibes. OTTO already sees every agent-second, run and word: parallelism multiplier, dead time reclaimed, the node that fails most, cost per landed change.
Sixteen agents produce sixteen branches, and the queue just moves. Every diff side by side, conflicts surfaced before you merge, a suggested landing order, one place to approve or send work back.
A budget per run, per workflow or per day — enforced, not reported. A projection before you press run. And workflows you publish, version and fork across your org.
Everything else helps one agent do one thing well. OTTO is what you need once that stopped being your constraint.
You would find these out in ten minutes anyway.
Draw the handoffs once. Let sixteen agents work at the same time.