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.
What actually goes wrong today
Stated plainly, because the approach below only makes sense as an answer to something specific.
- 01
Documentation drifts because it is written at a different time from the code. Any workflow where the docs are a separate pass will decay at the same rate as the last one did.
- 02
Asking one agent to "document this repository" produces a confident summary of what the repository probably contains, including functions that were renamed two releases ago.
- 03
Handing a documentation task to a fully staffed pipeline is overkill: you do not need a debate about whether a function takes three arguments.
- 04
Publishing generated prose unreviewed is worse than publishing nothing, because wrong documentation is trusted documentation.
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
Research agents read the real files through the confined read tools, so every claim in the output traces back to something on disk rather than to a plausible prior.
- 02
A parallel stage runs the subsystems side by side under DEV3D_MAX_CONCURRENCY, each employee getting its own knowledge snapshot, with results merged in role order so ordering is deterministic rather than race-dependent.
- 03
A review-loop closes it: reviewers critique the drafts and the chair synthesises a verdict, which is the stage that catches a documented API that does not exist.
- 04
Markdown files are written into the workspace, so what leaves the run is reviewable text plus the list of files that were read to produce it.
- 05
Most of the work is summarisation and extraction, so the bulk of the turns route to a cheap tier band; only the synthesis and the review pay for a stronger model.
What you actually end up with
Artifacts, not assurances. Every one of these is something you can open, diff, review or throw away.
Reference documentation that is regenerable, because the process is a pipeline rather than a person remembering how they did it last time.
Every page arrives with the files it was derived from, so a reviewer can check rather than trust.
The cost per refresh is predictable and small, which is what makes refreshing it routine instead of annual.
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.
Recognises a documentation brief and sizes it, which is what keeps the run from being staffed like an architecture review.
Reads the real files under DEV3D_MAX_CONCURRENCY; results merge in role order, so the merged draft is deterministic.
Summarisation and extraction, mostly: the bulk of the turns, and the bulk of them on a cheap tier band.
The stage that catches a documented function that does not exist, which is the failure mode generated docs are famous for.
Markdown lands in the workspace, so what leaves the run is reviewable text plus the list of files it was derived from.
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
Dependency 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 itBackfilling tests on untested code
Tests that fail when the behaviour breaks, not when it is refactored
Find the behaviour boundaries in code that has never been exercised, write tests against them, and have the run prove that each test actually detects a change.
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.