Orchestration that meets the engineer where they are

The tools that run agents for you tend to come with a place to run them: their harness, their model choice, their cloud. The work goes to them, and the engineer goes to the work. That is a reasonable way to sell compute. It is a poor way to run an engineering team, because the team already has harnesses it trusts, models it has opinions about, and a machine under every desk that is idle sixteen hours a day.

We took the other side of that trade. sleds orchestrates; it does not host, and it does not pick a harness for you.

A request that is too big for one session becomes a route

ENG-503, large exports by email, is more than an afternoon. The plan writes it as a route: eight nodes an agent can land one at a time, in four waves, each wave unblocking the next. A and B first (the job table, the email template). Then C, the worker, which needs both. Then three in parallel. Then the last two, one of which depends on how C turned out.

Each node is a small, complete request with its own band. The route has a band too, which is the sum of its nodes and the thing the business sees.

The engine runs it where you say

The engine is one command on the engineer's machine, sleds engine, and it is deliberately dull. It watches for armed nodes it is allowed to start, opens each one in its own worktree and session, follows the PR to the merge, and starts the next wave. It never merges. A person does, or a rule the person wrote does.

What makes it useful is what it does not care about:

• The harness. A node runs in Claude Code, Codex CLI or Cursor's agent, whichever the seat is. The engine passes the pack (the brief, the field book, the decisions so far) and reads the PR. It does not know what happened in between, and it does not need to.
• The runner. tmux, so you can attach and watch. Orca, if that is your cockpit. A plain terminal you name. Headless, for the overnight.
• The machine. Your Mac, while it is awake. A coworker's sled, if theirs has headroom and yours does not. A managed agent in Anthropic's cloud, for routes that should not wait for a laptop lid. The node is the same node. The receipt is the same receipt.

The menu bar app is where you watch it: what is running, what is at PR, what needs you. Approve, where nothing starts until you press Start, or Auto, where armed nodes start as they become ready.

When a node has a question, it parks

Wave four. E moved the link logic into a new module, so F's brief may no longer hold. The agent running F does not guess. It parks the node with a decision: two options, each a sentence, and what each one means for the band. The menu bar app shows one needing you. Slack shows the same card. Samantha, who owns that area and is not an engineer, answers A from her phone at 2:16. F resumes with her answer in its pack. Nothing after F was blocked, so H landed in the meantime.

Decisions are the record of the route as much as the PRs are. Six weeks later, the question "why does F extend that module" has an answer with a name and a time on it.

The record does not care where it ran

Every node lands the same way: actual against band, seat, model, signed, in the PR and on the row. 31 min · $7.40 · in band for ENG-503, across eight nodes, two machines and one person's phone. The lead reads one line. Nobody reconciles anything.

Why neutrality is the feature

Harnesses are improving monthly, and the right one for a node changes with the node. Models are priced differently every quarter. A machine under a desk is free, a coworker's headroom is nearly free, and the cloud is for when the alternative is waiting. An orchestrator that owns any of those layers has to defend its choice. One that owns none of them can take the best option every time, and keep one record while it does.

That is the bet. The orchestrator should be the smallest thing in the room, and the record should be the only thing that is the same everywhere.