I file an issue. It ships a pull request.
A GitHub issue goes in. A reviewed, gated, CI-green pull request comes out, opened by an agent with its own identity, on a server in my house. My part is the bit that is left: open the pull request, read the diff, decide whether it ships. Everything after that merge is automatic. It built a working app in a weekend that way. It also spent fifteen dollars once producing absolutely nothing, and the interesting part of this page is why.
98 runs between 11 and 29 July 2026. 72 shipped a pull request. 10 died as silent no-ops, 4 ran out of turns, and 12 early runs predate the verification guard, so they cannot honestly be counted either way. That is 84% of everything the guard could actually check. All of it read straight out of the job ledger, recorded by the runner's own telemetry rather than self-reported by the agent. The $270 is notional model spend: the real cost is one monthly Claude subscription that the factory shares with everything else I use it for. Not free, just already paid for. Snapshot as of 29 July 2026.
I lead product marketing for Upsun Dispatch. You cannot market a thing you have not felt, so I went and built my own version of the problem it solves, at home, and got it wrong in public for nineteen days.
That is the honest reason this exists. The other reason is that it was genuinely fun. This is a nights-and-weekends project, not a product, not a side business, and not something I am going to help you set up. It has exactly one user.
What it does. A labeled GitHub issue triggers a self-hosted runner. A manager agent scopes the work, reads the code itself, delegates to a small crew, runs the gates, and opens a pull request as its own GitHub identity. CI runs on the PR. Then it stops and waits for me to review it. Once I merge, the deploy runs itself.
What broke. Everything on this page that works was preceded by something that did not. A manager that waited fifteen turns for a phone call that could never arrive. A dashboard frozen for seventeen hours behind a green status light. A guard I built to catch lies that then lied in the other direction. Those failures are the part that transferred to the day job, so they get most of the room below.
The definition of "it worked" does not live in the model's mouth. It lives in a script that asks GitHub what actually shipped.
The rule the whole thing rests onAlmost none of this is mine. The two best decisions in the whole build were both decisions to write less code: drop the heavy agent runtime the original plan assumed, and use an existing open-source Telegram bridge instead of hand-rolling a polling loop. Both came from stopping to ask whether I actually needed the thing I was about to build, and the answer was no twice. The interesting work was never writing components. It was wiring existing ones together and then finding out where the wiring lies to you.
This page was built by the factory. The plan became GitHub issues, the issues became pull requests, and I reviewed and merged them.
Eight stages. Exactly one of them is a human, and it is deliberately the last one that can change anything.
Strictly speaking I do not need it. Any Claude session with GitHub access can file and tag an issue, and sometimes that is exactly what I do. But my ideas do not arrive at a desk. They arrive on a walk, on the loo, or in the shower, which a waterproof phone turns into a legitimate place of work. The bot is the difference between an idea that becomes a pull request and one that evaporates on the way back to the office.
None of the agent's instructions live in the product repository. The manager's brief, the rules, the crew definitions and a per-repo build sheet all live in a private control repo and are rendered onto the runner by a config-sync tool. Edit main, wait a few minutes, and every repo's agent has updated itself. What each product repo actually contains is a six-line stub.
The agent was the easy bit. It wrote its first real feature in under a minute. Everything after that was deciding what happens when it is wrong.
Every run exits through exactly one of five verdicts, and which one it gets is decided by a single question the agent does not get a vote on: is there a pushed branch.
The run was clean and the pull request is open.
It shipped, but burned its turn budget getting there. Still a PR, still honest about what it cost. The yellow is deliberate.
Hit a real wall, refused to guess, tagged me with the diff and the options.
A loud failure. Label flipped, comment posted, notification sent.
Claimed success and produced nothing. The dangerous one.
Every reliability fix here has been the same move. Stop trusting what the thing says about itself, and go look at what it actually produced. That is not an AI lesson. It is engineering, arriving in a new costume.
The first version had no windows. It worked, and I had no idea what it was doing, which is functionally the same as it not working.
The live status comes from the runner itself, not from polling an API. The runner already knows when a job starts and what it is doing, so a start hook and the manager's own narration write that to a local database, which is copied out over the management path. The isolation stays intact. Nothing had to open a hole to make the machine observable.
It paid for itself on the first run. The feature built to watch the factory work is exactly what caught it not working: the stream showed a manager delegating and scouting, and the ledger showed it quietly producing nothing.
Six moments that changed the design, in the order they happened.
Provisioned the runner and wired auth so the agent draws on a subscription rather than a metered API key. The first job failed immediately on a missing config line. The retry produced a clean branch in thirty-six seconds.
The first failure is never the scary one.The runner executes agent-authored code on the same machine as a live production site and the family network. I locked its outbound access down from inside the container rather than at the host, because the host-level fix could have taken down the very thing it was protecting.
Pick the mitigation that cannot break what you are guarding.The site described one of my own projects wrong. Instead of opening an editor I filed it as a job. The agent found the stale entry, made the edit, opened a pull request, and I merged it. Live in minutes.
This is the entire thesis, tested on something that actually mattered.A run that claims success while shipping nothing is the worst bug a can-I-trust-this system can have, because it is invisible and it writes its own false record. Fixed in three layers, the load-bearing one being a script that asks GitHub whether a branch exists and fails the run when it does not.
Ground truth is the artifact, not the report.Pointed it at a greenfield project with its own spec and backlog. 54 runs and $174 later it had shipped the scaffold, the tooling, both CI gates, a Dockerfile, the auth schema, the feature routes and a deploy agent, each as its own reviewed pull request. My entire contribution was reading diffs and deciding which ones shipped. Nine of those 54 runs were silent no-ops, which is how I found the worst bug in the system.
The agent is the easy part now. The factory is the hard part.Onboarded the factory’s own repository, behind a CI check that fails any agent pull request touching the workflows, the brain or the guards. It shipped a dashboard feature and never went near the fence.
A factory that builds itself is a claim that the safety model is real rather than decorative.Each one is the same bug wearing a different hat: something trusted a proxy for the truth instead of the truth.
Fifteen turns of an agent politely standing by for a notification that could never arrive. It did this ten times before I understood why.
The manager delegated to a subagent, which by default runs in the background and hands back a handle rather than a result. In an interactive session, something eventually delivers that notification. In a headless one-shot job, nothing ever does. So the run ended having made zero edits, and reported success. My first two theories were both about work getting lost on the way back, and both were wrong. The transcript said exactly what had happened, in the agent’s own words, five times over.
Delegate synchronously and block for the result. Strip the wait-for-notification tools out of the agent’s toolset entirely, so it cannot structurally reach for one. And stop delegating the scouting step, which was both the least valuable thing to hand off and where the stall almost always landed.
The feature shipped, passed review, and was invisible on every page that mattered.
A CSS rule elsewhere in the codebase hid the container the new component landed in. The markup was right there in the HTML and display:none on render. The reviewing agent ticked the box, because it had read the diff. Meanwhile the CI screenshots existed, were green, and plainly showed nothing there.
The reviewer now marks any visual criterion visually unverified instead of passing it, because an honest “I could not see this” beats a confident “looks good”. The mechanical half is turning visual acceptance criteria into real visibility assertions, so the check goes red when a claimed element ships invisible.
Every layer correct, the stack never exercised end to end.
The deploy path had shipped as a series of individually reviewed, individually correct pull requests. Because the first deploy was documented as a manual step, no tracer bullet had ever gone through the whole thing, so the seams between the pieces had never touched. The first real attempt found four at once: secrets that never reached the container, a health check sitting behind auth and returning a redirect the gate read as success, migrations that could not possibly run, and a permissions model that contradicted itself.
Run the real thing once, by hand, and let it tell you where the seams are. Then move the migration into the container so it is self-sufficient at boot, and make the health gate honest so it fails when the app is not actually ready.
| Run | Cost | What it bought |
|---|---|---|
| Cheapest shipped change | $0.39 · 12 turns | 70 seconds from label to open pull request. This is the one that makes filing a job feel free, which is its own kind of trap. |
| Most expensive failure | $7.71 · 51 turns | Ran out of turns and shipped nothing. Then I retried the same issue and it did it again for $7.63, so one ticket cost $15.34 and produced no code at all. |
| Shipped and failed | $6.83 · 51 turns | Opened a clean, mergeable PR and then burned its remaining budget trying to prove to itself that the gate would pass. The only run ever marked success-degraded. |
| Ten silent no-ops | $11.84 combined | Nine of them on two consecutive days. Cheap, quiet, and reporting success, which is exactly why they were the most dangerous thing this system has ever done. |
| The heaviest day | $104.98 · 31 runs | 19 July, the second day of building an app from scratch. More than a third of the entire bill, in one sitting. |
| Average run | $2.81 · 31.3 turns | Across all 98. Notional: the real line item is one monthly subscription, not 98 invoices. |
Twenty-six of those ninety-eight runs never shipped anything. That number is here on purpose, and it is the one I would have been most tempted to round. A system that claims a hundred percent is a system that has not yet been caught lying, and I know that because mine did, ten times, cheaply, while reporting success.
The factory was the excuse. The point was learning what agentic delivery feels like from the inside, in a place where the stakes were a personal website rather than someone's production estate.
Three things came out of it that I could not have got from a demo or a briefing document. That the hard problem is not code generation, it is knowing whether the thing in front of you actually happened. That the most expensive failures are scoping failures, filed by a human, before any model runs. And that trust in a system like this is built almost entirely out of what it does when it is wrong, not what it does when it is right. All three now show up in how I talk about Upsun Dispatch, which is the job this was really for.
Two answers, and which one you get depends entirely on why you are asking.
Build a small one. Point it at something you own and do not much care about, and let it fail in front of you. You will learn more in a fortnight than from any amount of reading, and most of what you learn will be about plumbing rather than about models.
That was the whole point for me, and I would do it again tomorrow.
Genuinely, no. Look at the stack list near the top of this page, then count the things that have to keep working: runners, tokens, a control repo, a sync daemon, per-repo secrets, an isolation policy, a ledger, a dashboard, two CI gates, a guard script and a bot. Every one of them has failed at least once.
I maintain all of that for an audience of one, in the evenings, and it still lied to me ten times. Multiply it by a team of fifty and it stops being a fun project and becomes somebody's full-time job, done badly, forever.
That is the honest case for buying rather than building, and it is a large part of why I am comfortable marketing Upsun Dispatch. I have now personally assembled the worse version. It was a wonderful way to spend nineteen evenings and it is not something I would hand to fifty engineers and ask them to depend on.
I am not selling this, and as the section above says, I would talk most people out of building one. It exists because I wanted to understand agentic delivery from the inside, on my own time, and now I do.
If you want to talk about what actually breaks in this stuff, or about the product work it feeds, I am easy to find.