Agents build in parallel. People decide.
A request that is too big for one session becomes a route: nodes an agent can land one at a time, in waves. An engine on an engineer's Mac runs them through whatever harness they already use, follows every PR to the merge, and stops to ask when the brief no longer holds. Nothing starts, changes scope or ships without a person's yes.
14:02:11 ENG-503/A ▸ started watch: tmux attach -t sleds-eng-503-a 14:02:11 ENG-503/B ▸ started watch: tmux attach -t sleds-eng-503-b 14:19:40 ENG-503/A ◐ pr #1192 · following it to the merge 14:23:05 ENG-503/B ◐ pr #1193 · CI green first try 14:31:18 ENG-503/A ✓ landed 18 min · $2.10 · in band 14:31:19 ENG-503/C ▸ started wave 2 · after A, B 14:58:02 ENG-503/F ◉ parked E changed the module F lists · asked Samantha 15:00:40 ENG-503/F ▸ answered A · from Slack · resumed
One request. Eight nodes. Four waves.
Watch one play out. ENG-503 was sized M and drafted into eight nodes. Two run at once in the first wave; each wave unblocks the next. When E lands and moves a module F depends on, F parks with a question instead of guessing. Samantha answers from Slack, and it resumes. The menu bar app beside it shows the same run from the engineer's Mac.
Your sled
0 running · 0 at PRApprove: nothing starts until you press Start.
It runs on your Mac, through the tools you already use.
The engine is one process on an engineer's machine. It reads what is armed on their sled, starts a session per ready node in its own worktree, and follows the PR. Nothing in the cloud runs an agent on your code unless you set that up yourself.
A session per node, named for it. tmux attach is the watch handle; the menu bar app opens it for you.
The plain runner: the same agent command in a terminal you name, or headless. Nothing to install beyond the CLI.
A worktree and a terminal per node inside Orca, with its notifications. The same engine, a different window.
A seat that runs on the provider's side for overnight and routes, with no laptop open. Priced and receipted like any other seat.
Your sled, from the top of the screen.
What is running, what is at PR, what needs you. Approve each start or let armed items go on their own. Set how many run at once, which runner opens the session, and which model builds, decides and drafts. The profile lives on sleds, so the same settings follow you to any machine.
It starts no agent and holds no login of its own: it reads the engine and arms items for it. A blink in the menu bar means a node is waiting on a person.
When the agent is unsure, it asks. What it learns, it writes down.
A node parks with a question instead of guessing: the brief no longer holds, a conflict, CI failed twice. An answerer proposes options with sources; a person picks one, answers their own way, or overrules, from the app, Slack or the terminal. When a run lands, the session says what the next one would not know, and it goes on the item.
A route change needs a person's yes. The node waits; the rest of the wave keeps going.
Pick an option in the menu bar, reply in Slack, or route answer from the CLI. All three land on the route.
Which approach won and why, what was flaky, what in the setup was wrong. The next run reads it first.
What a run may never do.
Every session starts with the same rules, and the engine enforces the ones it can see. Orchestration is only useful if the people on the sled can trust what happened while they were not looking.
— never force-push, or rebase past a conflict · a conflict stops the run — never deploy to production outside the window the playbook allows — never commit a secret, or write one into a note — never change the brief · scope is a person's · if the request is wrong, stop and say so — a session that exits without a PR goes back once, then fails — when you finish, say what you learned that the next run would not know
Put a route on your sled.
Request an invite. One engineer, one engine, the first route the same day.