White paper · Part II · October 2026 · 12 min read
Governing an AI Workforce
Decision rights, evidence and earned autonomy: how the Control Tower Method grows from a way to plan and measure AI-built software into one governed operating loop that runs the product and the growth of a company, and starts itself every night.
Executive summary
- Part I set the method: split a product into control areas, score each from L0 (not done) to L5 (autonomous), and give agents authority only where the evidence supports it. Part II is about running a company on it: who decides what, what evidence each decision needs, and what happens when the loop starts itself.
- One loop, two lanes. The same operating system runs the product lane (build, test, release) and the growth lane (plan, produce, approve, publish, measure). Both share one control tower, one evidence trail and one owner.
- The work starts without me. Each night agents read production signals, failing tests and campaign results, and propose fully scoped work. Agents build, test, document and produce.
- I keep a handful of decisions: what gets built, what gets merged, what reaches customers, and what gets promoted with money. Each arrives with the evidence I need to decide in minutes.
- The first full engineering cycle moved 19 changes into production code in one day, with zero failing tests reaching me. A rehearsal that combined changes before merging caught five conflicts the per-change checks had missed.
- Autonomy is earned, never assumed. L5 within 6–9 months comes from track record and pre-approved classes of change, not from removing the gates.
A team that only acts when someone remembers to ask is a tool. A team that senses, proposes, builds and reports on its own, under rules it can't break, is a workforce.
01What changes from Part I
Part I described a loop that I started: I set the strategy, agents built, CI verified and I approved. That made building fast. It didn't make the company self-running. Part II closes that gap, and widens the loop beyond code.
| Question | Part I: the method | Part II: the operating loop |
|---|---|---|
| Scope | Building the product | Building the product and growing it, on the same gates and evidence |
| Who starts the work? | I do, from the roadmap | Nightly agents propose scoped work from real signals; I approve the scope |
| Human decisions | Two: direction and approval | Explicit gates (scope, merge, release, spend), each with required evidence |
| Verification | CI on each change; ~1,150 tests | ~2,500 tests, plus a rehearsal of whole batches before they merge |
| Release | A tagged deploy | A release packet before publishing, a live check after, and alerts if the two disagree |
| Growth | Outside the method | A weekly content pack, outcome scorecards and pre-agreed spend rules |
| Operations | Planned | Tiered alerts for broken merges and failed user journeys, runbooks, kill switches |
| Cost | Not addressed | Fixed-plan scheduling, the cheapest capable model per job, CI skipped where it can't matter |
02Decision rights
The most important design choice isn't technical. It's deciding which decisions stay human and what evidence makes each one fast. Everything else is delegated.
| Decision | Who decides | What agents do | Evidence required |
|---|---|---|---|
| What to build | Owner | Propose, with "done looks like" and tests | A work item tied to the roadmap and the written strategy |
| Whether a change is safe | Owner | Build, test, document | Review packet; all checks green on a production-shaped database |
| When customers get it | Owner | Prepare the release packet; verify live | Every change and database change since the last release; post-release live check |
| What we say in public | Owner, one week at a time | Plan 6–8 weeks ahead, produce each week's posts, schedule what's approved | The finished weekly pack, each post tied to the plan and the goal it serves |
| Where money goes | Owner, every time | Propose a boost when a post beats its baseline | The post's outcome score against the baseline, the budget left, and the stop rule |
| Sensitive areas: payments, sign-in, customer data, AI models | Owner, always | Flag for approval | Explicit approval in the packet, even when routine changes are pre-approved later |
03One loop, two lanes
A control area can sit in the product (billing, sign-in), in the engineering system (testing, releases) or in growth (content, paid acquisition). The ladder doesn't care which. So the same loop that builds the product also grows it: the same sensing, the same packets, the same gates, the same evidence trail.
Product lane
Build, verify, release
- Signals become scoped work items overnight
- Agents build and test; CI gates every change
- Batches are rehearsed before they merge
- The owner releases with a packet; a live check follows
Growth lane
Plan, produce, measure
- A rolling 6–8 week content plan, re-planned every month
- Agents produce each week's posts from the owner's own material
- The owner approves one week at a time; agents schedule only what's approved
- Every post is measured at 24 hours, 48 hours and 7 days, and traced to sign-ups
The growth lane's rhythm
| When | What the agents do | What the owner does |
|---|---|---|
| Every morning | Read yesterday's results and sign-ups, fill each post's checkpoints, flag anything far above or below its baseline | Nothing, unless a boost is proposed |
| 48 hours after a post | Score it on outcomes (saves, shares, profile visits per thousand views) and propose a boost if it is the week's winner | Approve or skip the boost with one tap |
| Wednesday | Finish next week's pack: images, video, captions, tracked links | Review |
| Thursday | Schedule every approved post | Approve, change or drop each post |
| Monday | Scorecard against targets, best and worst post and why, a forecast for the month, proposed changes to the next four weeks | Accept or reject the proposals |
| Every four weeks | Re-plan the next four to six weeks from what the data showed | Accept the general plan |
Outcomes, not activity
An audit of past campaigns showed they had been optimized for clicks, not sign-ups. The fix was the same as in engineering: measure the outcome, and gate decisions on it. Every post carries a tracked link, every sign-up records where it came from, and the weekly score is accounts created and taste quizzes completed, not likes. Rules decided in advance (boost only what already outperforms, stop any ad after two weeks, never let one ad take most of a month's budget) turn judgment into gates, exactly as CI does for code.
04The controls that make it trustworthy
Part I introduced review packets and decision records. Part II adds the controls a business needs before it lets a loop run overnight.
| Control | What it does | Why it matters to the business |
|---|---|---|
| Batch rehearsal | Before a set of changes merges, they are combined and tested together. | It caught five conflicts that every individual check had passed. |
| Enforced boundaries | Agents are technically blocked from merging, from changing the main branch and from publishing. Production data is readable only inside read-only transactions. | The gates are enforced, not just promised, and no agent can change customer data. |
| Signals to work | Failing tests, errors, alerts, AI-call logs and campaign results become scoped proposals overnight, placed in the existing roadmap order. | Problems turn into plans without a status meeting. |
| Bug policy | Defects found by tests are fixed when the fix is non-breaking. Breaking ones are isolated, scoped and surfaced. | Quality improves continuously without surprise behaviour changes. |
| Spend rules | Paid promotion only for posts that already beat their baseline, a fixed monthly budget, a two-week stop and a cap on any single ad. | Marketing money follows evidence, and no campaign can run away with the budget. |
| Attribution first | Tracked links on every post and the source of every sign-up recorded, on the web and in both mobile apps. | Growth is judged on customers gained, not attention bought. |
| Tiered alerting | A phone push when a merge breaks the main branch or users hit failures, email for degradation, a weekly digest. | Leadership hears about problems before customers do. |
| Containment | Kill switches switch a feature off without a deploy, and every alert has a runbook. | Incidents are contained in minutes, not releases. |
| Delivery metrics | Deploy frequency, lead time, change-failure rate and time to restore, counted in business days. | Throughput and stability are measured, and weekends aren't held against the team. |
| Cost governance | Scheduled agents run on a fixed plan with overage disabled. Each job uses the cheapest model that can do it. Documentation-only changes skip the test run. | Autonomy without a surprise bill. |
| Strategy next to the work | The strategic brief and a dated decisions log live in the repository, so agents read them before proposing. | Agents plan from intent, not from whatever they find. |
05Maturity: where each area is heading
Scored on the Part I ladder, the engineering system moved from mostly L1 (by hand) to L2–L3 (checked on every change) in its first cycle. The deliberate position is "L4 with human gates": automated wherever a machine is reliable, with a person wherever judgment or accountability matters. The growth lane climbs the same ladder.
| Area | Now | Month 2 | Month 4 | Month 6 | Target |
|---|---|---|---|---|---|
| Product lane | |||||
| Build & test | L3 | L3 | L4 | L4 | L5 |
| Release & rollback | L2 | L3 | L3 | L4 | L4 |
| Operations & alerting | L2 | L3 | L4 | L4 | L5 |
| AI quality | L2 | L3 | L3 | L4 | L4 |
| Growth lane | |||||
| Content production | L2 | L3 | L4 | L4 | L5 |
| Measurement & attribution | L2 | L3 | L4 | L4 | L5 |
| Paid promotion | L2 | L3 | L3 | L4 | L4 |
Paid promotion stops at L4 on purpose: spending money stays a human decision, made in one tap with the evidence in hand.
06Results from the first cycle
- A roadmap that behaves like an operating system: 12 themes, about 100 work items in one format, and a 10-week plan sized to real capacity, all read by the control tower from GitHub.
- 19 changes integrated in a day. Rehearsed together, merged in dependency order, ending with a green main branch: about 2,500 tests and the browser journeys passing.
- The checks paid for themselves at once. New suites found authorization and data-integrity defects, which were fixed before release, including a pagination edge case that could hide a customer's items.
- Mobile layout is now a gate. Recording the product for the growth lane surfaced layout problems on narrow phones; each became a fix with a browser test at three phone widths that blocks any regression.
- Owner decisions are recorded once and reused everywhere. A day of product decisions became a dated log the agents now plan from, and the growth lane runs from the same kind of log.
07What L5 looks like
In both lanes, L5 looks the same: the system detects, acts inside a pre-approved rule, verifies, and leaves the owner one decision.
Product lane
Detect
A production check sees recommendations stop personalizing for some users.
Triage
An agent gathers logs and the last change, and matches a known pattern.
Act
The fix is pre-approved, so the agent flips the kill switch to the previous model.
Verify
The same checks confirm recovery, and the evidence is logged.
Decide
I read the digest. My only decision is when to fix the root cause.
Growth lane
Detect
The scorecard flags a post converting well above its baseline.
Propose
An agent proposes a boost inside the month's pre-approved budget rule.
Decide
I approve with one tap.
Stop
The ad stops by rule. Cost per sign-up is logged and feeds the next plan.
08The next horizon
The loop is built to scale beyond one owner. These are the next controls on the roadmap, each designed to widen what agents may do on their own while keeping the evidence trail intact.
- A separate agent identity with platform-enforced approvals. A dedicated identity makes "only the owner approves" a rule of the platform itself.
- Staging and automatic rollback. A copy of production to release into first, and an automatic roll back when the live check fails.
- AI quality gates. Golden datasets scoring every model and prompt change on accuracy, cost and p95/p99 latency before it ships.
- Service-level objectives. Explicit targets for the journeys that matter (scan, chat, checkout), with error budgets that decide when feature work slows down.
- Install attribution on every platform. Crediting app installs on iPhone and Android to the post or ad that drove them, so growth decisions use the full funnel.
- Predictive planning. Once enough posts are logged, a model predicts each planned post's reach and conversion, the weekly plan is ranked on it, and its accuracy is tracked every week.
- Pre-approved classes of change. A written policy for which changes may merge on green after a probation period. This is the real path to L5.
- One audit trail of approvals. Who approved what, when, and on what evidence, across code, releases, content and spend, ready for investors, partners and compliance.
- Control drills. Rehearsed rollbacks and kill-switch tests each quarter, so the controls are known to work.
09What this means for any leader adopting AI agents
Part I argued for building the factory first. Part II is what it looks like to run a company on it: a product that improves every night, a growth engine that learns every week, and one accountable owner.