Nova Is in Production: What Running 34 AI Agents Actually Looks Like

<p>A few months ago Nova was a side project. An interesting one, but still a thing I was building rather than a thing I was depending on. That's changed. Nova is now in what I'd call the production orchestration phase — running across general chat, pipeline execution, ERP specialists, and language tasks. Thirty-four agents, all told.</p><p>I want to be honest about what that number means, because "34 agents" sounds like a headline stat and I don't want to write that kind of post. The count matters less than the shape of the system. What actually changed when Nova crossed from "experiment" to "production" wasn't the number of agents — it was that I started depending on it. I route real work through it. When it breaks, I notice immediately, because something I was relying on is gone.</p><p>That dependency is the most useful forcing function I've found for building software. You stop tolerating rough edges when the rough edges cost you time every day.</p><p>The agent structure breaks down roughly like this: there are generalist agents that handle conversation and task delegation, pipeline agents that execute multi-step jobs without me babysitting each step, specialist agents scoped to AIREP and ERP domain work, and language-focused agents for drafting and summarising. Each category has a different failure mode. The generalists fail by being too broad — they'll attempt a task they should've escalated. The pipeline agents fail by getting stuck silently. The specialists fail when domain context is stale. The language agents mostly just fail by being verbose, which is the least painful failure but still annoying.</p><p>Building the orchestration layer has taught me more about software architecture than most of the formal system design I've done. When you have 34 moving parts that each have opinions about what they should do, you stop thinking about code and start thinking about contracts. What does this agent promise to return? What does it need to receive? What happens when it can't fulfil the contract? Those questions apply just as well to microservices or Django views, but agents make them impossible to ignore because the failures are loud and conversational rather than silent and logged.</p><p>One of my current goals is building a self-improvement loop — agents that autonomously review, refactor, and improve Nova's own code. I haven't shipped that yet. I'm writing about the production phase, not the future phase. But having Nova in production is a prerequisite for that goal, and that's actually why I wanted to document this moment. You can't build a system that improves itself if the system isn't real yet. Now it is.</p><p>The other thing worth noting: Nova lives alongside several other active projects — AIREP, Find a Sign, Sweeper Parts, client sites. It's not a standalone experiment; it's the infrastructure layer that connects my work. That makes it both more valuable and more consequential to get right. A bug in a client website is a problem. A bug in the system I use to manage all my work is a problem multiplied.</p><p>If you're building something similar — a personal AI layer, an agent system, anything in this space — my honest advice is to get it into production dependency as fast as you can tolerate. Not because being in production makes you look serious, but because it's the only condition under which you'll make the right decisions. Every architectural choice I'm confident in now, I made after I started depending on the system. The choices I made before that are the ones I'm still cleaning up.</p><p>More on the self-improvement loop when there's something concrete to show. For now: Nova is real, it runs, and it matters to how I work. That's the milestone.</p>