34 Agents in Production: What Running a Personal AI System Actually Looks Like

<p>A few months ago Nova was a side project. A useful one, but still something I was building in the margins around client work. This week it crossed a line I'd been working toward: production orchestration. Meaning it's not just running — it's running multiple agents concurrently, routing work between them, and doing real things across real systems. That felt worth writing down, not to celebrate, but to be honest about what it actually is.</p><p>Right now Nova has 34 agents. That number sounds impressive until you break it down: general chat agents, pipeline execution agents, ERP specialists, language translation agents, and a few others that handle specific tasks I kept writing manual code for. Each agent has a defined scope. Some are thin wrappers around a model with a tightly scoped system prompt. Others have tool access — memory search, web lookups, structured output pipelines. The architecture is deliberate: narrow agents that do one thing well rather than broad agents that try to do everything and hallucinate the gaps.</p><p>The production orchestration phase means there's now a layer above the individual agents — something that decides which agent handles which task, maintains context across a session, and manages the queue when multiple things are happening at once. Getting that layer right took longer than building any individual agent. Routing sounds trivial until you're debugging why a query about an invoice landed in the general chat agent instead of the AIREP ERP specialist, or why a pipeline stalled because two agents were waiting on the same upstream result.</p><p>What I've learned building this is that the hard part of a multi-agent system isn't the AI. The models are reliable enough if you constrain them properly. The hard part is the same as any distributed system: state management, failure handling, and observability. When a single agent gives a bad answer, you debug a prompt. When an orchestrated pipeline gives a bad answer, you have to trace which agent in the chain made the first bad assumption and propagated it downstream. That's a different class of problem, and it demands the same rigour as debugging any complex backend system.</p><p>One goal I've been deliberate about is building Nova toward a self-improvement loop — agents that can review, refactor, and improve Nova's own code. That's not live yet, but the architecture is being built with it in mind. Every agent is versioned. Prompts are stored and retrievable. The orchestration layer logs decisions. All of that is groundwork for a system that can eventually look at its own performance, identify weak points, and propose changes. Whether that actually works at the scale of a solo developer's system remains to be proven, but I'd rather design for it now than retrofit later.</p><p>The reason I'm investing this heavily in Nova isn't novelty. It's leverage. I run multiple active projects simultaneously — AIREP, Find a Sign, Sweeper Parts, client sites, this blog — and the cognitive overhead of context-switching between them is real. An AI system that genuinely understands the state of each project, can draft and review code, answer domain-specific questions, and handle the low-signal administrative work isn't a nice-to-have. It's the difference between being able to operate at this scope and not.</p><p>I'm also aware that 34 agents in a personal system sounds like over-engineering. Maybe it is. But my view is that AI is the primary leverage point in software right now, and building that leverage into your own workflow compounds over time. The developers who treat AI as an external tool they consult occasionally will be outpaced by the ones who've made it load-bearing infrastructure. I'd rather be the second type.</p><p>The orchestration work continues. There are still rough edges in the routing logic, agents that need better tooling, and pipelines that are more manual than they should be. But production is production — it's being used, it's doing real work, and the feedback loop is tight. That's the right place to be.</p>