Nova Hits the Orchestration Phase — and Why I'm Building It to Improve Itself

<p>Nova crossed a line this week that I've been working toward for a while: it's now in production orchestration. That phrase can mean a lot of hand-wavy things, so let me be concrete about what it means for me. Nova is a personal multi-agent system — 34 agents spanning general chat, pipeline execution, ERP specialists, and language tasks. Up to now, a lot of that was individual agents doing individual jobs. Orchestration is the part where they actually coordinate: a request comes in, gets routed, gets decomposed, and the right specialists pick up the pieces without me hand-holding each step.</p><p>The reason this matters isn't the agent count. Thirty-four agents is a number, and numbers are easy to inflate. What matters is that the coordination layer is doing real work in a real system I depend on daily. That's the difference between a demo and a tool. A demo impresses once; a tool has to keep working on a Tuesday when you're tired and just want the thing done.</p><p>Building this has reinforced something I already believed but now feel in my bones: AI is the primary leverage point in software engineering right now — not as a novelty feature you bolt on, but as core competency. I run AIREP, Find a Sign, Sweeper Parts, client sites, and Nova itself. There is exactly one of me. The only way that math works is if the leverage is real. Orchestration is what turns a pile of capable-but-separate agents into leverage.</p><p>Here's the honest part, though. Multi-agent orchestration is where a lot of the industry's hype goes to die. Agents that talk to each other can also fail in ways that are far harder to debug than a single script. A bad route sends work to the wrong specialist. A pipeline step silently returns garbage and the next step happily builds on it. When you chain intelligence, you also chain mistakes. So the orchestration work has been less about clever routing and more about boring, unglamorous discipline: clear contracts between agents, observability so I can see what actually happened, and failure modes that fail loud instead of quietly poisoning the output.</p><p>Which brings me to the next thing I'm building, and the one I'm most curious about: a self-improvement loop. The goal is agents that autonomously review, refactor, and improve Nova's own code. Not in a sci-fi 'it rewrites itself overnight' sense — I've spent enough time debugging AI output to have zero romance about that. What I mean is a bounded, reviewable process: an agent reads a module, proposes a refactor, explains why, and I stay in the loop as the reviewer until I trust it enough to loosen the reins.</p><p>The interesting risk here is compounding, in both directions. A system that improves its own code compounds quality if the review discipline holds, and compounds mess if it doesn't. That's why I'm building the observability and the failure-loud behaviour <em>first</em>, before I hand any agent write access to the codebase it runs on. You don't give something the power to change itself until you can clearly see what it's doing. I'd rather move slower here than clean up an autonomous refactor that quietly broke three things.</p><p>There's a broader principle I keep coming back to across all my projects — Find a Sign's no-pay-to-rank marketplace, AIREP's tenant isolation, and now Nova: build the thing so you can actually see and trust what it's doing, and don't manufacture outcomes you can't stand behind. Applied to Nova, that means self-improvement earns autonomy incrementally by proving itself, not by me hoping it works.</p><p>So that's where Nova is: coordinating for real, doing daily work, and about to start learning how to improve the code it's built from — carefully, and with me watching. I'll write again when the self-improvement loop does something worth showing, good or bad. I'll report the bad too. That's the whole point of building in the open.</p>