One process, two kinds of worker

The org chart you already know — planes, seats, blast radius — except a seat no longer cares whether its worker is a person or an agent.

The factory doesn't split "human workflows" from "agent workflows" — it definesseats, and either kind of worker can sit in one. A seat is a set of functional inputs, outputs and permissions, so it can be filled by an agent sub-task, by a main harness loop (bh role <seat>), or by a human doing the same verbs by hand. What keeps the mix safe:

• Humans hold the gates. Plan approval and kickoff approval are explicit human checkpoints; the default review gate is human; a reviewer bounce sends the bead back with written feedback rather than silently failing. bd humanexists to flag any decision for a person.
• Every agent signs its work. In agent identity mode each worktree is stamped with a distinct author and a dedicated SSH signing key, so agent commits are attributable and verifiable. In supervised mode the worktree inherits the human's keys — "under my keys, with direct supervision."
• Seat typing is enforced. An epic can only be started by a dispatcher (disp/), a leaf bead only claimed by a developer (dev/), asecurity:* gate only resolved by a warden. Humans (non-seat identities) are exempt — the machinery constrains agents, not people.
• Escalation over silent failure. A merge that can't auto-resolve bounces the bead with its branch restored; a broken shared branch escalates loudly for a forward fix. Work is never dropped.

Four planes, one orchestration spine

Seats are separated by blast radius: the seat that routes work holds no secrets, the seat that holds secrets makes no decisions, the seat that observes writes nothing. A small single-hive factory collapses the four control seats into just the supervisor — deliberately, so the split is a designed merge, not an accident.

Which harness a seat runs under

A seat is defined by what it takes in, what it puts out, and what it is allowed to touch — not by the agent CLI executing it. So the harness is configuration. Any seat launches as a main loop with bh role <seat>, which resolves the harness from--harness, then BH_HARNESS, then the hive's setting, then the global one:

bh role dispatcher                      # the configured harness
bh role dispatcher --harness opencode   # override for one launch
bh hive onboard --claude                # furnish a hive for Claude Code
bh hive onboard --opencode              # …or for OpenCode

Two harnesses are furnished today. A third, Codex, reads the managedAGENTS.md steering hint natively but is not launched or furnished bybh.

Worktree provisioning is harness-independent:bh worktree add --preview --json and bh worktree status --json give any external orchestrator the same porcelain the seats use.

Planes the factory is growing into

These are named so the direction is visible, not described — a guide that documents unbuilt work reads as finished when it isn't. Detail lands with the code.

• Release · cutting the version itself. The ordering half already ships; determination, changelog and tag are next
• Contribution · gated contributions to repos we don't own
• Build · pulling upstream progress into local build branches
• Delivery · reconciling a cut release into running systems
• Ideation · deriving candidate work from a repo's own vision documents