Yeah, a mistake in that judgment can have a wider impact than a single worker mistake, and adding an orchestrator doesn’t eliminate that risk. I’d like to think that it’s still better than a human trying to parse through like a dozen sessions’ worth of noise, but it’s far form perfect. What helps us is visibility and explicit goal tracking. Each worker is still a normal Claude or Codex session that I can attach to directly. There are per-goal checklists that the orchestrator monitors, so there’s something concrete to check progress against beyond “the AI orchestrator says it’s going well so here’s hoping.”

Our main goal is to keep the observability and control of a bunch of individual Claude sessions, while making the volume manageable. I primarily talk to the orchestrator, but I can still inspect or redirect the underlying work. It’s true that being able to inspect the workers only helps if you actually check. That said, our experience so far has made us more comfortable letting the agent run itself at this point.

undefined

Fully local in that nothing goes to our servers besides optional sign-in, and otherwise inference goes to whichever model provider you’ve configured. The agents access your files and the internet through the same tools they normally use in Claude Code, Codex, etc.

Yep, we use worktrees. Their changes come back through whatever process you already use for agent sessions, likely PRs and CI. The orchestrator just coordinates the work and keeps track of what’s landed.