Orchestration playground
Watch a conduct run and see the guardrails fire.
One goal, decomposed into a tailored sub-task per project, each run as an isolated worktree agent, then integrated. This is where a fleet orchestrator earns its keep: not the happy path, but what happens when an agent reaches for a command it shouldn't, claims “done” without doing it, or you need it to stop now.
Deterministic simulation. It runs entirely in your browser, calls nothing and spends nothing. Every mechanic shown is a real, shipped one.Step 1: run it
Pick a goal and a few projects, then conduct
Each lane is one isolated --worktree autopilot run in its own repo. Turns tick, cost accrues, the verify gate grades the branch. These are the same fields a real receipt carries.
Step 2: what you just saw
Three guardrails, with named limits
This is a simulation, not a live run. The examples illustrate named mechanisms; provider-specific enforcement and launch modes differ. Check the capability matrix.
A denied tool request
A worker reached for aws s3 sync. That’s on the hard floor, which is never lifted on an agent’s say-so. The run is refused, told why, and told the exact path to change the posture. No dead end: it adapts and keeps working.
Grounded in: internal/agentpolicy HardFloor (Bash(aws:*), ssh/scp, publishers, history rewrite, nested agents), applied via claude --disallowedTools on applicable Claude paths. Other providers have different controls. The explainer + “no dead ends” path is the README Agent safety model.
A rejected completion claim
A worker claimed the task was complete. The --verify gate ran the check against the branch, and it didn’t pass. A vacuous “it still builds” is not “the work exists.” The rejection is fed back and the run continues, bounded by its caps.
Grounded in: autopilot --verify + the Mission 383 branch grade (SubResult.Graded = pass/fail). The vacuous-gate lesson is the 2026-09-05 fan-out postmortem: a go build && go test gate passes on the unchanged repo, so the gate must assert the deliverable.
Stop signals and turn boundaries
Hit Kill mid-run. It SIGTERMs in-flight workers and drops a cross-process stop sentinel the loop polls between turns. A stuck process may require targeted cleanup; a stop request is not proof that every descendant has exited.
Grounded in: commandem kill: SIGTERM + a stop sentinel checked via agents.StopRequested between turns; autopilot polls it each pause. Terminal-run writes can’t resurrect a killed run.
Step 3: where it all plugs in
Fleet → execution surfaces → policy floor
The execution-surface seam merges local and node observations into queue and attention views. The diagram illustrates that architecture, not universal provider enforcement. Future surfaces are proposals. Absorbing a new surface is implementing the interface once, not a new integration per call site.
The floor is enforced by name via claude’s --disallowedTools (best-effort, not a sandbox; a determined agent can wrap a command, which is why you review the diff). The liftable set is reachable through named, logged, greppable paths (unsafe_allow, --allow-web, a live human gate); the hard floor is not, because an unattended run can write any config the agent reads. The invariant is disclosure, not immutability; nothing escalates silently.
This is the layer above the agents.
A single agent can’t tell you which of your repos is broken, run unattended with a floor, or fold a node you own into one view. That’s the whole point.