34 Agents in Production: What Running a Real Multi-Agent AI System Actually Looks Like

<p>Nova has 34 agents running in production right now. Not in a notebook, not in a demo environment, not in a slide deck. In production — handling real tasks, routing real requests, talking to real systems. And the honest reflection I keep coming back to is: getting to this point was a completely different problem than building the agents themselves.</p><p>When people talk about multi-agent AI systems, the conversation usually centres on the agents — what models they use, how they're prompted, what tools they have access to. That part is genuinely interesting, but it's also the easy part. You can prototype an agent in an afternoon. The hard part is orchestration: what happens when 34 of them need to work together reliably, across different domains, without stepping on each other or producing garbage that silently looks correct.</p><p>Nova spans a few distinct categories — general chat, pipeline execution, ERP specialists, language tasks, and others. Each category has different latency tolerances, different failure modes, and different definitions of "correct output". A pipeline execution agent that silently skips a step is a completely different class of failure than a language agent that produces a slightly awkward sentence. Treating them the same way operationally was one of my early mistakes. Production forced me to stop doing that.</p><p>The shift from prototype to production orchestration came down to a few concrete things. First, observability. In a prototype you can watch the output and eyeball whether it's right. At 34 agents you can't eyeball anything — you need structured logging, you need to know which agent handled a request, what it was handed, what it returned, and how long it took. Without that, debugging is archaeology. Second, failure handling. Agents fail. Models return unexpected formats, tools time out, edge cases appear that no prompt engineering anticipated. Production means having an opinion about what happens next — retry, fall back, escalate, or fail loudly — rather than just crashing or silently returning nothing useful. Third, scope discipline. The temptation with agent systems is to keep expanding what each agent does. Production punishes that. Narrow, well-defined agents with clear input/output contracts are dramatically easier to maintain and debug than broad ones that "handle it".</p><p>One thing I'm working toward is a Nova self-improvement loop — agents that can review, refactor, and improve Nova's own code autonomously. That goal only makes sense because the system is stable enough to trust with that kind of task. You can't give an agent write access to a codebase that's already chaotic. The production discipline I've had to build isn't just operational hygiene — it's a prerequisite for the next layer of capability.</p><p>The broader point I keep landing on is that AI as a genuine business and engineering advantage isn't about having access to models. Everyone has access to models. The advantage comes from the compound effect of having systems that are actually reliable — systems you can build on top of, integrate into other products, and trust to do the right thing when you're not watching. Nova feeds into AIREP, into Find a Sign, into client work. That only works if it's solid underneath.</p><p>Thirty-four agents sounds like a lot. In practice it's a number that reflects scope creep as much as intentional design — some of those agents probably need to be consolidated, and I know it. But the orchestration layer that holds them together is now something I'd call genuinely production-grade. That took longer than the agents themselves, and it was the work that actually mattered.</p><p>If you're building agent systems and you're still in prototype mode, the question worth asking isn't "what else can my agents do?" It's "what would it take for me to trust this in production?" The answer to that question is usually the next six months of work.</p>