A feature in a service nobody on the team owns
Add the endpoint without first reading the whole service
Land a feature in a codebase you have not worked in — where the real risk is not writing the code, it is putting it in the wrong layer and inventing an abstraction that does not match the house style.
What actually goes wrong today
Stated plainly, because the approach below only makes sense as an answer to something specific.
- 01
The change is small and the surrounding context is not. Reading a service end to end to add one capability is days of work that produces nothing shippable.
- 02
A single agent handed the feature will produce something plausible and unidiomatic: a new service class in a repository that has none, a helper where the project keeps utilities in one file, a migration where the project has never used them.
- 03
The decision that actually matters — does this belong in the existing module or a new one — is exactly the decision a single voice skips, because it never has to defend the choice.
- 04
Nobody notices the seam was wrong until review, which is the most expensive moment to find it.
How the hierarchy and the router do it
Concretely, stage by stage: which mode the stage uses, who owns it, and why the router prices it the way it does.
- 01
Intake on the cheapest capable model, because classifying "add an endpoint" does not need a frontier call.
- 02
Parallel research: one specialist maps the call path, another finds the conventions actually used in the repository (naming, error shape, how tests are written) by reading files rather than guessing them.
- 03
A debate between the roles that would own the change on either side of the seam. The chair records the ruling, so the shape of the change is a decision with a reason, not an accident of which file the agent opened first.
- 04
The CTO writes the file-level plan with the falsifier stated: what would show that placing the feature here was wrong.
- 05
Developer agents write the files, then QA tries to break it — the new path exercised, the error case probed, the surrounding contract checked for a change nobody intended.
- 06
Routine turns stay on lower tiers; only the plan, the implementation and the review escalate. The tier band is declared per role, so the cheap posture cannot quietly downgrade the architecture decision.
What you actually end up with
Artifacts, not assurances. Every one of these is something you can open, diff, review or throw away.
The feature, plus a written record of where it was placed and why, which is what the next person to touch the service actually needs.
Conventions are followed because they were read from the repository in the research stage, not inferred from a training distribution.
Review gets a plan and a diff to argue with, instead of a finished change with no visible reasoning.
Which part of the company is involved
Six of the thirteen roles, four of the eight departments. The rest of the office stays idle, and that is what keeps the run affordable.
Classifying "add an endpoint" does not need a frontier call, and the router does not make one.
One maps the call path, another finds the conventions actually in use — naming, error shape, how tests are written.
The seam decision is the whole point: which module owns the change, argued rather than assumed.
Names the files and states the falsifier — what would show that placing the feature here was wrong.
Implements against the conventions that were read rather than against a training-distribution average.
Exercises the new path, probes the error case, and checks the surrounding contract for an unintended change.
Modes used
Intake runs single, research runs parallel, contested decisions run as a debate, and anything that produces files ends in a review-loop.
Where the money goes
Reading and summarising sit on cheap bands. The plan, the implementation turns and the review escalate, because those are the turns where being wrong is the expensive mistake.
What is recorded
Per-turn cost, the route decision and the models the router rejected, the files touched, and the debate ruling including the position that lost.
Two other jobs in the same shape
Technical documentation that is generated from the repository
Write docs against files that exist, on the turn they are read
Produce and refresh reference documentation — module maps, API surfaces, decision records — from the source itself, with the generated pages landing as markdown in a workspace you review before it merges.
Read itDependency and security upgrade sweeps
Ordered batches with a reviewer, not one hopeful auto-fix
Work through a dependency backlog in ordered, reviewable batches: what depends on what, what has to move together, what the upgrade breaks, and what the run could not prove.
Read itRun this in mock mode first
Node 24, one install, no API keys. The pipeline, the stages, the file writes and the review loop all run against scripted employees, so you can watch the shape of the work before it costs anything.
Nothing in the orchestrator authenticates, so bind it to localhost. The tools are confined to the run workspace, but that workspace is a normal directory on the machine and the orchestrator is not inside an operating-system sandbox — give it a checkout you would be willing to lose.