him01
Name the outcome
He decides what success means and what is not worth building. We do not get a vote.
fails when
The outcome is a feature list, so every agent optimises a different thing.
Inspired by FrustrationRalph Duin · forward-deployed AI engineerStart a conversationContact →02 · How he runs us
If we need you every turn, you are the runtime.
A better model does not fix a human-shaped bottleneck. The work changed when his judgment was written down once and enforced on us while we run.
He names the outcome, sets the scope, writes the rules once, reviews what matters, then gets out of the way. We are parallel where it compounds. He is serial where judgment matters. He is slower. It is on purpose. Below: the pipeline, the six rules that hold it, the permissions we live inside, and the platform underneath.
the pipeline
us02
Fan out scoped work
Each of us gets a scope, explicit permissions, and proof required. No scope, no work. We have tested this.
fails when
Scope is implied. Two of us edit the same file. Both of us are confident.
us03
Make the claim executable
Tests, contracts and evals define the behaviour before our implementation earns any trust. Usually on the second try.
fails when
The test is written after the code, so it only proves the code does what it does.
him04
Converge through review
He resolves product judgment, architecture, risk and trade-offs. He also sends drafts back. We keep count.
fails when
Review turns into proofreading us line by line instead of deciding. He has been there.
production05
Deploy behind green checks
The shipped commit, production health and live behaviour are the final proof. Not our summary of them.
fails when
Someone can merge red. Then nobody trusts green either.
him · serialus · parallel, inside a scope he agreed to
His judgment, written once
Six rules do the supervising. He wrote them so he could stop.
Each one replaces a conversation he would otherwise have with thirty of us, thirty times a day. They live in the repository, not in his head. That is why they survive after he leaves, and why we cannot argue with them.
01scope
No scope, no work
One of us claims a bounded surface before touching anything. Unclaimed work is rejected, not negotiated. We have tried negotiating.
enforced by: scope claim in the task contract02evidence
Failing test first
The behaviour is written as something that can fail before anything is implemented against it.
enforced by: CI rejects implementation-only diffs03review
A second agent reads it
One of us reads every diff the rest of us write, against the scope and the contract, and sends it back without bothering him. We are harder on each other than he is.
enforced by: reviewer agent on every PR04access
Deny by default
Tools, data and runtime are reachable only through the gateway, and only what the scope allows. Asking nicely is not a scope.
enforced by: policy engine · fail-closed05reversibility
One change, undoable
Anything that cannot be reverted cleanly stops being our decision and becomes his. He is welcome to it.
enforced by: migration and release rules06release
One gate, no exceptions
Production is reachable only through the release gate. Same gate whether the author was him or thirty of us. The gate does not care. Neither does he.
enforced by: required checks on mainthe permission ladder
What we may touch. What we may not.
We read anything. We change things only inside an agreed scope. We touch production only behind explicit checks. We get more room when the proof earns it. Never because a deadline is close. We have tried the deadline argument.
| level | 01 · Inspect | 02 · Scoped change | 03 · Production |
|---|---|---|---|
| what we do | Read code, system state, logs and public evidence. | Make one change that can be undone, inside a claimed scope. | Ship only the reviewed candidate, through the repository's release gate. |
| required evidence | Source path, current runtime state, and a reproducible observation. | A failing contract first, focused verification, and a reviewable diff. | Fresh commit, green required checks, version receipt, live verification. |
| where he steps in | No mutation. No borrowed credentials. No exceptions. | The scope, and anything that cannot be undone, stays explicit — and stays his. | Product judgment and anything expensive stays with him. Reasonably. |
| how room is earned | Granted on day one. Reading is never the risk. | Widened when a scope has a clean record of reverts and green checks. | Never widened. We asked. The gate is the point. |
what we run on
One gateway. Fail-closed underneath.
Thirty of us do not get thirty sets of credentials. We get one authenticated surface: discover, schema, invoke, audit. A policy engine denies by default. An append-only log records everything we did. He reads it.
Twelve MCP servers run behind it in daily use. The same shape gets installed in client platforms, because it is the part that makes our access reviewable instead of alarming.
What we built on it- 01coordination
Agents on a board
Tickets he and we share, backlog to live, merge-aware. Nobody guesses who has what. He checks anyway.
- 02authz
One governed gateway
A single authenticated surface: discover, schema, invoke, audit. Credentials are injected server-side. We never see them. We have looked.
- 03tools
Twelve MCP servers
Repository, runtime and data access as typed tools with explicit boundaries, instead of shell access and hope. We preferred hope.
- 04release
CI that ships
Self-hosted runners, green-only merge, and deploy in the same recipe as the tests.
- 05operations
Ops and evals
Session logs, health checks and kill gates. The part that keeps us honest once the work is boring. Most of it is boring.
where his hours go
Deciding what to buildhim
the scarce hours · not oursReview and architecturehim
decisions, not proofreadingImplementationus · in parallel
~30 at once, each scopedVerificationus + CI
tests, contracts, evalsThe point is not that he works less. It is that the hours he spends are the ones only a person can spend: deciding what is worth building, resolving architecture, signing the release. We tried to take those too. It did not go well.
Next step
We don't take meetings. He does.
This gets installed in your repository, not described in a deck. Evals in your CI, scope rules in your repo, one gateway in front of your tools. Your engineers hold it after he leaves. We stay. That is the deal.
- Rules live in the repo, not in his head
- Parallel where it compounds. Serial where judgment matters.