What Running 34 AI Agents in Production Actually Looks Like

<p>There's a version of this post I could write that sounds impressive: "I built a 34-agent AI system that orchestrates my entire business." That sentence is technically true. It's also almost useless as information. So let me try to say something more honest about what Nova actually is, where it's at, and why I think this kind of system matters.</p><p>Nova is my personal AI infrastructure. It started as a way to stop re-explaining context to language models every time I opened a new chat window. It's grown into something I'd describe as a multi-agent orchestration layer — a system that routes tasks to specialised agents depending on what's needed. As of now, it spans 34 agents across general conversation, pipeline execution, ERP-specific work, and language tasks. It's in production, meaning I actually use it daily, not just in demos.</p><p>What does "production" mean for a personal AI system? It means the system has to work when I'm tired, when I haven't documented something properly, when the task is half-formed. It means failure modes matter. An agent that confidently gives wrong answers is worse than no agent at all. So a big part of getting Nova to this phase wasn't adding capabilities — it was adding discipline. Agents that stay in their lane. Routing logic that doesn't guess when it should ask. Memory that surfaces relevant context without hallucinating connections that don't exist.</p><p>The 34-agent number sounds like a lot. In practice, most agents are narrow. A narrow agent that does one thing reliably is worth more than a general agent that does ten things inconsistently. The ERP specialists, for example, are scoped tightly to AIREP's domain — branch-scoped data models, Django ORM patterns, PostgreSQL query structure. They don't need to know about signage marketplaces. That separation is intentional and it matters.</p><p>The current phase — orchestration — is about making the agents work together without me having to manually direct traffic. A pipeline agent coordinates a sequence of tasks. A memory layer gives agents shared context. The goal is that I describe what I want at a high level and the system figures out which agents to invoke, in what order, with what inputs. That's not fully solved yet. Orchestration is genuinely hard, and most of the difficulty is in the edge cases: what happens when an agent returns an unexpected result, when a pipeline stalls halfway, when the task doesn't map cleanly to any agent's domain.</p><p>One goal I'm working toward is a self-improvement loop — agents that can review Nova's own code, identify weak spots, and propose or apply refactors. That's not running yet, but the architecture is oriented toward it. The reason I think this is achievable (not just a fun idea) is that Nova already has enough context about its own structure that a well-scoped agent could reason about it. The hard part is trust: how do you let an agent modify production code without introducing subtle regressions? That's an unsolved problem I'm taking seriously rather than hand-waving.</p><p>What I keep coming back to is the framing. I don't think of Nova as a tool I use. I think of it as infrastructure I maintain and improve — closer to how I think about a database schema or a deployment pipeline than how I think about a SaaS subscription. That framing changes what I build. Tools get evaluated on convenience. Infrastructure gets evaluated on reliability, composability, and long-term cost of ownership.</p><p>The honest status: Nova works, it's useful, it's in active development, and it has real rough edges. The orchestration layer is functional but not elegant. Some agents are better than others. The memory system is good enough that I trust it, which is a higher bar than it sounds. The self-improvement loop is a goal, not a feature.</p><p>I'm writing about this not to position Nova as a product — it's not — but because I think the pattern is worth documenting. Building your own AI infrastructure, even at a personal scale, forces a level of rigour that using off-the-shelf tools doesn't. You have to decide what reliability means. You have to own the failure modes. That's uncomfortable, and it's also exactly where the compounding advantage comes from.</p>