# Where T25 comes from > The origin of the project, what dogfooding taught us, and the principles we refused to negotiate on the way from a local orchestrator to a software factory. - By: Djan Magno - Published: 2026-09-26 - Updated: 2026-09-26 - URL: https://t25.io/en/blog/where-t25-comes-from/ - Launches ยท t25 factory, project history, ai coding agents, software engineering, human gates, early evaluators > **TL;DR:** > - T25 started in August 2026 as a plain local orchestrator: one isolated git worktree per task and a state machine no agent gets to skip. > - Dogfooding with real agents (44 tasks, up to `TASK-0044`) showed us exactly where the design broke, and became the fix queue: recomputed verdicts, slice-level rework, diff limits. > - Today the factory has a durable Postgres control plane, a worker with lease and heartbeat, audit and process evals. The merge stays human by choice, not by technical limitation. > - The next chapter is an invite-only early evaluators program: run it on your machine, with the CLIs you already pay for. ## The starting point The repository began on 22 August 2026 with a commit that already states the whole idea: enable git worktrees for isolated task execution. It wasn't a product yet. It was a conviction that a coding agent running alone in your main checkout doesn't scale, not in trust, not in volume. The idea that predates that commit is simple: every company can have its own software factory. T25 started from the decision to build one. What the records do show is the problem the project set out to attack: teams already using coding agents without governance. Review happens ad hoc in a terminal, scope is whatever the model decided to touch, isolation doesn't exist, and the merge is a decision nobody actually owns. Each of those became a piece of the design. ## What dogfooding taught us We didn't write T25 to write T25. From the start, the project's own repository was the production line: every feature slice goes through the same state machine as any task, spec, plan, gate, worktree, QA, review, pull request. By September 2026 the dogfood had 44 completed tasks, with a real merged PR (`TASK-0008`), a pilot (`TASK-0009`), regression rounds, brownfield and greenfield work, and a merge proof (`TASK-0036`). The most important task was none of those. It was `TASK-0044`, which broke in an instructive way: one QA failure outside the task's scope made the pipeline re-run the entire plan. With four slices, a single QA failure cost eight development runs to fix nothing. That incident became slice-level rework: structured findings with category, criteria and files; rework now targets only the slices that were hit, with a durable cursor that survives pause and resume. In the controlled comparison, the same failure dropped from eight runs to four, zero rework when the failure was out of scope. The number matters less than the habit that stuck: every real dogfood bug closes a deterministic gap, not a longer prompt. The same period produced the lesson that became its own post: the verdict an agent reviewer writes is an input signal, not a decision. The model's `APPROVE` stays on record; policy decides, recomputed from the findings. Worth the read: [The model's APPROVE is not the merge](https://t25.io/en/blog/the-models-approve-is-not-the-merge/). ## From local orchestrator to factory The first version was a local process with state on disk. It worked, until you wanted to restart the worker mid-task, or answer where a transition came from, or recover a queue after a crash. In September 2026, three architecture decisions formalized the evolution: 1. **Postgres control plane.** Tasks, runs, leases and events moved into a durable database with an audit trail, instead of JSON in a state folder. A process restart stopped being an event. 2. **Worker protocol.** A remote worker signs leases with its own credential, sends heartbeats and acknowledges completion. The queue stopped being local by accident and became a contract. 3. **Hash-addressed artifact storage.** Specs, plans and reports became content-addressed, so we can revisit exactly what the pipeline read when it decided. In parallel, the project gained process evals, deterministic gates that replay adversarial scenarios (empty project, broken command, stale checkout, ambiguous goal) and separate infrastructure failure from product failure, plus progress supervision, which pauses a task when the same error repeats or the same criterion stays unproven, instead of letting the agent burn budget in a loop. In September came the rename: the public surface became T25. The name is a reference to the T-25 Universal, an aircraft used for military flight training by the Brazilian Air Force. The name stayed as a reference to the starting point of learning to fly with procedure before earning autonomy: a checklist before every flight, someone beside you, autonomy granted little by little. That is the stance we want from a coding agent. The package and internal identifiers keep the old name for compatibility, and the sentence that summarizes the product survived every version: a task goes in, a pull request comes out, and the merge stays yours. ## The principles we don't negotiate After a month of dogfooding, the principles stopped being intent and became regression tests: - **Isolation per task.** No agent runs in the main checkout. Every order gets its own worktree and branch, with path validation and cleanup that never deletes uncommitted work. Details in [One task, one worktree](https://t25.io/en/blog/one-task-one-worktree-isolating-ai-coding-agents/). - **The model doesn't grade its own work.** Structured output goes in; a verdict comes out of a deterministic function. Output that doesn't parse fails closed. - **Human gates proportional to risk.** A person always approves the spec; plan approval depends on risk; the merge is always human. Policy decides what reaches you. - **Cost and credentials stay with the user.** T25 runs locally and calls the agent CLIs you already subscribe to. There is no new API key to leak. - **Every decision leaves a trail.** Sequential events, hash-addressed artifacts and append-only audit answer who, when and what without anyone's memory. ## What's next T25 is in early access, with private distribution: a package installed from a checksum-verified tarball, a `t25 doctor --evaluation` that validates the environment before the first order, and an invite-only early evaluators program, free for the 30 days of evaluation, running on your machine. T25 does not collect your code, prompts, logs or credentials; the agent CLIs you use keep sending data to their providers, under your account. The next proof is no longer internal: an external self-hosted evaluation cohort, measured by first pull request, second run and an interview, never by installation alone. If you want to study the design before requesting an invite, the [documentation](https://t25.io/docs/) covers the state machine, configuration and the worker contract. ## FAQ ### Is T25 open source? No. The code is not public. Evaluators receive a private package under the Evaluation Terms, which prohibit redistribution, reverse engineering and commercial use without a contract. ### Why does the merge stay human? Because the merge is the highest-blast-radius decision in the pipeline, and because whoever answers for main needs to be able to actually answer for it. The factory works so that what reaches that button has already passed an approved spec, QA, review with a recomputed verdict and diff limits. The button, though, is yours. ### What does T25 stand for? It is a reference to the T-25 Universal, an aircraft used for military flight training by the Brazilian Air Force. Like a training aircraft, T25 works with procedure, supervision and autonomy granted little by little. ### How do I join the early evaluators program? By invite: a personal download link arrives by e-mail, the installer verifies the package checksum and `t25 doctor --evaluation` validates your environment. Sign-ups open soon on the invite page.