The story
Ten demo-ready apps, zero verified
One night I pointed Forge at an empty directory and asked it to build ten different apps around the same idea — tools that show people who really owns the local businesses around them. By morning it had built all ten. Every one of them ran. Every one of them was genuinely demo-ready: real curated datasets, confidence scoring, maps, methodology notes.
And Forge's own verdict on its work? Zero out of ten verified.
That number turned out to be the most useful thing the run produced. Every failure was Forge's own — a verification rule that demanded exact bookkeeping from a mode that creates hundreds of files, orphaned browser processes outliving their attempts, a worker that gave up on a whole batch because one repository was misconfigured. The apps were fine. The organization was broken. And because every state change was journaled and every claim was checked against git reality, I could read exactly where, and fix it in an afternoon.
That's the whole thesis of the project, really: the model was never the bottleneck. The organization around it was.
Agents are strong ICs and terrible companies
A modern coding agent is a genuinely good individual contributor. Give it a scoped task and a worktree and it will often do the job. But everything that makes a team of good ICs into a functioning engineering org — planning, code review, QA, merge discipline, budgets, retros, institutional memory — doesn't come in the box. Most agent setups are fire-and-forget: a big prompt goes in, a big diff comes out, and a human absorbs all of the coordination cost that a real organization would carry.
Here's how I think about what an organization actually is: a suite of imperfect people, tools, and workflows that produces an output more valuable than its inputs — and that changes, optimizes, and does better tomorrow than it did today. Nobody on a great team is perfect; the team is great because the structure catches what individuals miss and compounds what they learn. Forge is that definition with the nouns swapped: a suite of imperfect agents, tools, and workflows for creating software. The imperfection isn't a caveat — it's the design assumption everything else follows from.
Forge is my attempt to build the organization. It's a single Go binary and a SQLite
file. The daemon schedules work, serves a web UI, runs a serial merge queue per
repository, and supervises budgets; a worker executes attempts in isolated git
worktrees. Every role you'd hire for is a mode an agent runs in: plan
decomposes, run and implement build,
review and verify hold verdicts, retro writes
down what we learned, supervise decides whether the work actually met the
goal. The structure — not any single agent — is the product.
Trust is a supply chain
The first hard rule came out of that overnight run: self-report is not a state. An agent saying "done, tests pass" moves nothing. Claims are checked against what git actually recorded (L0). Declared checks are re-run by the platform, not the agent (L1). For real features, a separate verify agent with no stake in the outcome rebuilds the thing, runs it, and clicks through it (L2). Humans gate what matters most (L3). The merge queue re-checks everything again after rebase, because code that was green on its own branch has opinions about other people's code.
The second rule: everything is evidence. Every prompt is frozen byte-for-byte with a hash before an attempt starts. Every state change appends a journal row. Every spawned task records what caused it and which ask it ultimately serves. When something goes wrong at 3am — and it does — the question is never "what happened?", it's "which journal rows do I read?"
The content is git, the triggers are SQL
Halfway through, the prompts themselves became the interesting artifact. Forge now keeps everything an agent reads — role directives, personas, shared fragments, utility scripts — in a plain git repository, composed at the moment work is created and audited by hash. Schedules and operational limits stay in SQLite; words live in git, where they can be diffed, reverted, and merged from an upstream base library like any other code.
That split unlocked two things I didn't fully anticipate. First, the library is itself a repository Forge can be pointed at — so the system can run maintenance on its own prompts through the same plan/build/verify/merge pipeline it uses for everything else. Second, tools stopped being a registry I maintain. Agents jot quick scripts into a scratch cache; a script that keeps getting reached for — enough runs, by enough different attempts — triggers a curation task that dedupes it against the library, optimizes it, writes proper metadata, and promotes it to a permanent, callable tool. Utilities earn tenure the way good internal tools always have: by being used.
Recursion needs a return path
The most recent piece was the one the whole thing was missing. Forge could already decompose: a plan-mode agent turns an ask into a DAG of tasks with write-sets and dependency edges, and they execute in parallel. But decomposition without feedback is just scattering. The plan finished the moment the plan document existed; nobody was accountable for what came back.
So every batch now ends in a continuation: a supervisor agent that wakes when the last task settles, reads what actually happened — states, summaries, costs — inspects the repository, and either declares the goal met with honest 1–5 scores, or emits corrective tasks that fan out as the next round. Tasks can themselves be plans, bounded in depth; rounds are bounded in count; and the scores land in the same analytics table as cost and turns, so "was the effort proportional to the size?" is a query, not a vibe.
My favorite bug never shipped, because the design review caught it: a task blocked on a failed sibling would have wedged open forever, silently starving the supervisor — the repair mechanism — precisely when something had failed and repair was needed. The fix is a settlement cascade that cancels the wedged work so the supervisor can run. Distributed-systems lessons apply even when the whole distributed system is one binary talking to itself.
Measure it or it's theater
The standard I hold this to: we have to recursively learn, or it's an expensive abstraction layer. A system like this can feel impressive while quietly just burning tokens. So Forge benchmarks itself: a standing spec — "rebuild the ownership-transparency app from an empty repository" — runs through the full recursive loop, and every run lands as one row of history: overall score, dollar cost, wall time, task count, the biggest remaining weakness. If quality-at-fixed-budget doesn't trend up as the library and the knowledge base accrete, the learning loop isn't real, and the chart will say so.
What it is and isn't
Forge is a personal research system — a one-person software factory that runs while I sleep. It runs on my machine, against my repositories, for one user; it is pre-stability by design, which has been a gift — no install base means every architectural mistake can be fixed by deleting it. Much of it was built by the agents it orchestrates, which stopped feeling strange around the time the system started proposing improvements to its own prompt for proposing improvements.
What I'd defend anywhere: verification as a first-class state machine rather than a hope; frozen prompts and total provenance; content in git and state in SQL; bounded autonomy with real budgets; and a benchmark that keeps the whole thing honest. Those aren't AI ideas. They're just what organizations that ship have always done — written down carefully enough that software can do them.
If you want the mechanics, the docs cover the architecture, the library, and the learning loop. If you want to talk about it, I'm Ronin11 on GitHub.