The Controller & the Workers

FlowForge doesn’t treat AI as a single genie you keep re-prompting. It runs an orchestration model: one controller — ACE — that decides, a bench of specialist agents that execute, and isolated workers that carry a ticket from branch to reviewed pull request. This chapter explains who does what and where the founder stays in the loop.

The controller — ACE

The controller has a name: ACE, street name The Controller — the partner you talk to, and the personification of FlowForge’s Never Alone promise (Chapter 1). ACE’s job is to ship the founder’s intent fast and well, and it has two tools for that:

• Orchestrate — dispatch specialist agents when work is parallel, needs deep domain expertise, or is substantial enough to be worth an isolated branch and an independent review.
• Execute directly — make the change itself when that’s faster: small, reversible edits, and all diagnosis, reading, and investigation.

This is the ceremony dial. There is no rule that the controller must never touch code, and no rule that everything must become a multi-agent saga. The old “always orchestrate, never execute” framing was wrong — it turned five-minute fixes into productions. The real rule is judgment, scaled to risk and size.

The specialist bench

FlowForge ships a roster of specialist agents — architecture, backend, frontend, design, database, security, QA, documentation, terminal-UI, and more. Each holds deep, current domain expertise and is dispatched for the work it’s best at. Design work routes through a design authority that hands down a per-surface brief; terminal-UI work routes through a TUI architect that decides composition before a leaf agent writes the view code. The routing rule is simple: reach for the specialist when it multiplies you, and say why when you don’t.

Workers: one ticket, one isolated branch

A ticket implementation runs as a worker — not as an ad-hoc sub-task. A worker gets:

• its own timer (the billable record),
• its own feature branch in an isolated worktree (so parallel workers never collide on the same files),
• a ticket-verify gate at spawn (a closed ticket can’t start a worker), and
• a relay back to the controller.

Isolation matters: a worker that ran in the main checkout would pile its deliverables up untracked and lose them. Each worker owns its own tree, does its work, opens a draft pull request, and signals done with facts — never a self-declared verdict.

The review gate

A worker never grades its own homework. The gating verdict comes from an independent review — a fresh, separate vehicle that reviews the pull request against the blueprint’s acceptance bar. Two invariants protect the merge:

• No merge on red. A failing CI check blocks the merge, always.
• No merge without an independent GOLDEN. The reviewer’s approval is a required gate; the worker that wrote the code cannot post the verdict that clears it.

The controller relays what the review found, re-grading raw severity into product-domain terms for the founder — a reviewer’s “BLOCKER” is an input to judge, not a headline to parrot.

The founder stays in the loop on what matters

Merges, irreversible actions, scope changes, and customer-facing decisions are the founder’s. Routine steps are not. And by default a human does the final merge — FlowForge does not auto-merge unless a standing autonomy flag is explicitly turned on. The founder’s attention is spent where it changes the outcome, and nowhere else.

Why it matters

The orchestration model is how FlowForge scales without losing control. Specialists bring depth, workers bring isolation and a clean paper trail, the independent review brings trust, and the controller keeps the whole thing pointed at what the founder actually wants — fast when it can be, careful where it must be.