What 34 Agents in Production Actually Means

<p>Nova hit a milestone recently that I've been working toward for a while: it's now running in what I'd call a production orchestration phase. Thirty-four agents across general chat, pipeline execution, ERP specialists, language tasks, and more. That sounds like a big number, and honestly it is — but the number isn't the interesting part. The interesting part is what it takes to make that many agents actually useful rather than just impressive on paper.</p><p>The easy version of a multi-agent system is a handful of GPT wrappers with different system prompts. That's not what I built, and it's not what I was aiming for. Nova is structured around the idea that each agent has a defined scope, a defined interface, and a reason to exist that isn't just "we needed another agent." The ERP specialists exist because AIREP has domain-specific logic that general models handle poorly without grounding. The pipeline agents exist because some tasks are genuinely multi-step and benefit from decomposition rather than a single long prompt hoping for the best.</p><p>Getting to 34 agents in production meant solving a different class of problem than building the first one. The first agent is a proof of concept. The tenth is where you start feeling the coordination overhead. By the time you're at 34, you're thinking about routing logic, context propagation, failure modes, and how to stop agents from talking in circles when a task spans multiple domains. None of that is glamorous, but all of it is real engineering.</p><p>One thing I've had to be deliberate about is avoiding the trap of building agents for their own sake. It's genuinely tempting — once the scaffolding is there, spinning up a new agent is cheap. But a cheap agent that adds noise to the system is worse than no agent at all. Every agent in Nova has to earn its place by either handling a task class better than the general system, or by reducing load on agents that were doing too much. That constraint has kept the architecture honest.</p><p>The production orchestration phase also means I'm now thinking about Nova's own improvement loop seriously. One of my current goals is building agents that can autonomously review, refactor, and improve Nova's own code. That's not science fiction at this point — it's an engineering problem with real sub-problems: how do you give an agent enough context about a codebase to make meaningful suggestions? How do you validate those suggestions without just trusting the model? How do you keep a human in the loop for anything that touches production? These are solvable problems, and solving them is the next phase of the work.</p><p>What I keep coming back to is that AI isn't a feature you add to a product — it's a capability you build into how you work. Nova isn't a chatbot bolted onto my workflow. It's the backend service that increasingly handles the cognitive overhead of running multiple projects simultaneously: AIREP, Find a Sign, Sweeper Parts, client work, this blog. The leverage comes from depth of integration, not from the headline agent count.</p><p>If you're building something similar, the honest advice is this: start with the problem, not the agent count. Figure out where you're losing time or making errors that a well-scoped agent could absorb. Build that agent properly — with real context, real constraints, and a way to know when it's failing. Then repeat. Thirty-four agents sounds like a lot until you realise each one represents a specific bottleneck that got removed.</p><p>The orchestration work continues. The self-improvement loop is next. I'll write about both as they develop.</p>