What Running 34 AI Agents in Production Actually Looks Like

<p>Nova is in production. Not "production" in the sense of a polished SaaS launch with a landing page and a pricing table — production in the sense that I rely on it daily, it runs real workloads, and when it breaks, actual things stop working. That's the bar I care about.</p><p>The system currently spans 34 agents across a few broad categories: general chat and reasoning, pipeline execution, ERP specialists that know AIREP's domain, and language tooling. Each agent has a defined scope. The orchestration layer decides which agent — or sequence of agents — handles a given request. That's the part I've been focused on lately: not building more agents, but making the routing and coordination between them reliable enough to trust.</p><p>The honest answer to "what does this look like in practice" is: messier than any architecture diagram suggests, and more useful than I expected. Those two things coexist. The messiness comes from the fact that multi-agent systems don't fail cleanly. A single model call either works or it doesn't. A pipeline of agents can half-work — producing output that looks plausible but is missing context from three steps back. Catching that requires either very good observability or enough domain knowledge to notice when something's off. Usually both.</p><p>The usefulness comes from compounding. Each agent is narrow enough to be reliable at its specific job. The orchestration layer handles the coordination logic, which means I'm not writing that logic into every individual agent. When I add a new capability — say, an agent that understands AIREP's branch-scoped data model — it plugs into the existing pipeline infrastructure rather than requiring a full rebuild. That's the architectural payoff of getting the separation of concerns right early.</p><p>What I'm building toward now is a self-improvement loop. The idea is that Nova's agents should be able to review their own code, flag patterns that aren't working, and surface refactor candidates — not autonomously deploy changes, but do the analysis work that currently sits entirely on me. This is less exotic than it sounds. It's essentially code review and static analysis, except the reviewer has full context of how the system actually behaves at runtime. The hard part isn't the concept; it's defining what "not working" means precisely enough for an agent to identify it without generating noise.</p><p>There's a broader point here about AI as leverage. I'm not using Nova because it's interesting technology — though it is. I'm using it because it compounds my capacity across every project I run: AIREP, Find a Sign, Sweeper Parts, client work. The same agent that helps me reason through an ERP schema decision can help me draft a specification, review a migration script, or surface a relevant note from six months ago. That's not a tool. That's infrastructure.</p><p>The thing I've had to resist is the temptation to keep building agents before the orchestration layer is solid. More agents running on shaky coordination just means more things that can go wrong in hard-to-diagnose ways. The current phase is about hardening the plumbing: reliable routing, clean handoffs between agents, and enough logging that I can reconstruct what happened when something goes sideways. Boring work. Necessary work.</p><p>If you're building something similar — even at a much smaller scale — my honest advice is to treat the orchestration layer as the product, not the individual agents. The agents are components. The value is in how they're connected and how failures are handled. Get that right first, then expand.</p><p>More updates as the self-improvement loop takes shape. That one's going to be worth writing about when it works.</p>