Vago built itself
How I know my agent orchestrator works: it built itself, one frozen version at a time.
In the last post I said vago built itself, and that's how I know it works.
From the very beginning I wanted vago to build vago, some sort of dogfooding. If it can take its own goals and ship them, it can probably do the same for my other pet projects. It's also a harder test than building some random app, because it's changing its own code while it runs. If a ticket breaks the runner halfway through a goal, every ticket after it runs on a broken runner.
So each goal runs on a frozen version of vago. I can compile the repo into one binary at ~/.local/bin/vago, and that binary is what runs the goal. The goal works in its own worktree on a vago/<goal> branch, so the agents edit a copy of the source and the binary running them never sees it. When the goal is done I merge the pull request, reinstall, and the next goal runs on the new version. Nothing revolutionary to be honest.
The workflow is frozen too, since many times I tweaked the workflow as goals ran. vago run reads the workflow TOML, its prompts and its includes once at the start, and nothing re-reads them mid-goal. A ticket can rewrite the review prompt and the tickets after it still get the old one.
It also took keeping two sides of the repo apart. src/ and starter/ are the product, what ships to every project that runs vago init. The repo's own .vago/ is the installed product running on itself. Agents working on a goal change the product, and .vago/ only changes when I update it.
So the worst a goal can do is end as a pull request I don't merge, and the vago running everything is still the one from before. Running like that it did 15 goals, 88 tickets and 575 agent runs on itself.
Everything builds itself now, so it's not THAT important, it's just cool. And probably this will be obsolete in like 2 or 3 new agent generations, but it works now.