34 Agents and Counting: What Running Nova in Production Actually Looks Like

<p>I've been building Nova — my personal AI multi-agent system — for a while now, and somewhere along the way it quietly crossed a threshold. It stopped being a side project I tinkered with and became something I genuinely rely on every day. As of right now it runs 34 agents across general chat, pipeline execution, ERP specialists, and language tasks. I'm calling this the production orchestration phase, and it's worth pausing to write down what that actually means.</p><p>First, the number. 34 agents sounds like a lot, and honestly it is. But they didn't appear all at once — each one was added to solve a specific, concrete problem. There's no padding here. When I found myself doing the same kind of task repeatedly — summarising a long document, drafting a structured response to a client query, running a check on AIREP data — I'd build an agent for it. The accumulation is a direct record of friction I've encountered and decided to eliminate.</p><p>The shift into "production" isn't a technical milestone so much as a behavioural one. I'm not running Nova to see if it works. I'm running it because not running it would slow me down. That's the real test. A system you trust enough to depend on is a fundamentally different thing from a system you're evaluating.</p><p>What I've learnt most in this phase is that orchestration is the hard problem. Writing an individual agent that does one thing well is relatively straightforward. Getting agents to hand off context cleanly, making sure the right agent gets invoked for the right task, and ensuring that failures surface clearly rather than silently — that's where the real engineering lives. A pipeline that misfires quietly is worse than one that fails loudly, because you end up trusting output you shouldn't.</p><p>The other thing that's become obvious is how much the value compounds. Nova isn't just faster than doing things manually — it changes what I'm willing to attempt. When I know I can offload the mechanical parts of a task, I'm more likely to take on problems that would otherwise feel too time-consuming. That compounding effect is what I mean when I say AI is leverage, not just tooling. A hammer makes you faster at hammering. Nova makes me willing to build things I'd have skipped.</p><p>Right now I'm working toward what I'd call a self-improvement loop — agents that can review Nova's own code, flag issues, and propose refactors. This isn't as exotic as it sounds. The codebase has the same problems any growing codebase has: inconsistencies, duplication, decisions that made sense six months ago and don't anymore. The difference is that I want the system itself to have opinions about its own health, not just wait for me to notice something's off. Whether that works as well in practice as it does in theory is something I'll find out.</p><p>One thing I want to be clear about: I'm not running 34 agents because I think more agents is better. I'm running 34 agents because that's how many distinct problems I've had that warranted one. The goal was never scale for its own sake — it was reducing the gap between having an idea and actually executing on it. Nova is infrastructure for that. The number is a side effect, not a target.</p><p>If you're building something similar, the most useful advice I can give is to start with a problem you have today, not a system you think you'll need tomorrow. The architecture I have now didn't come from a whiteboard session — it came from building one agent, using it, noticing what it couldn't do, and building the next one. That's still how it works. Production just means the loop is tighter and the stakes are higher.</p>