What Running 34 AI Agents in Production Actually Looks Like

<p>A few months ago, if you asked me what a personal AI system looked like in production, I would have described something much simpler: a chat interface wired to an API, maybe some prompt templates, a bit of context management. What I'm running now is meaningfully different, and I want to write about it honestly rather than let it slide into the kind of vague "AI-powered" language I find exhausting to read.</p><p>Nova is my personal AI system — it backs this website, handles parts of my workflow across multiple projects, and is now in what I'm calling a production orchestration phase. That means it's not just responding to direct queries. It's routing tasks between specialised agents, maintaining context across sessions, and operating as a persistent layer underneath my day-to-day work rather than a tool I consciously pick up and put down.</p><p>Right now there are 34 agents across a few broad categories: general chat and reasoning, pipeline execution, ERP specialists that understand AIREP's data model, and language tools. That number sounds large. In practice, most agents are narrow — they do one thing well and hand off cleanly. The complexity isn't in any individual agent; it's in the orchestration layer that decides which agent handles what, when to chain them, and when to just give a direct answer rather than spinning up a pipeline that's more overhead than it's worth.</p><p>That last point took longer to get right than I expected. Early on, I defaulted to routing almost everything through a pipeline because it felt more robust. It wasn't. It was slower, harder to debug, and introduced failure points that didn't exist when the task was simple. The lesson: orchestration should be invisible when the task is small. The system should be capable of complexity without defaulting to it.</p><p>The ERP specialists are probably the most practically useful piece right now. AIREP is a multi-tenant Django ERP with branch-scoped data — the domain model is specific enough that a general-purpose model makes mistakes that a tuned agent doesn't. Having agents that understand the difference between a branch-level record and a tenant-level record, or know what a particular document workflow looks like, saves real time when I'm building or debugging features. It's not magic — it's just domain context baked in at the right layer.</p><p>What I'm working toward is a self-improvement loop: agents that can review Nova's own code, flag inconsistencies, and propose refactors. That's not running yet in any meaningful sense. I mention it because it's the goal that shapes the current architecture decisions — I'm building toward a system that can participate in its own maintenance, not just respond to mine.</p><p>The honest version of where things are: the orchestration layer works, the agents are useful, and the system is genuinely saving me time across AIREP, Find a Sign, and client work. But it's also a system I built for myself, which means it fits my mental model well and would require real work to hand to someone else. That's a known tradeoff. For now, the value is in the compound effect — every project benefits from the same underlying capability, and that capability improves as I add to it.</p><p>If you're building something similar, the thing I'd emphasise is this: the architecture decisions matter more than the model choices. Which tasks get routed where, how context is managed across sessions, what the failure modes look like when an agent gets it wrong — those are engineering problems, not AI problems. Treat them that way and you'll move faster.</p><p>More on the specific pieces as they develop. The self-improvement loop, when it's actually running, will be worth writing about in detail.</p>