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

<p>Nova is in production. Not "I deployed a chatbot" production — I mean a 34-agent orchestration system that handles general conversation, pipeline execution, ERP specialist tasks, language translation, and a growing list of domain-specific jobs that I've carved out one by one over the past several months. It's running. It's doing real work. And it looks almost nothing like I expected when I started.</p><p>The number 34 sounds arbitrary, but it reflects something real: the granularity you end up needing once you stop treating AI as a single monolithic assistant and start treating it as a team. Each agent has a defined scope. Some are narrow — a single pipeline stage, a single transformation type. Others are broader orchestrators that route work and synthesise results. The architecture isn't flat; there's hierarchy, and that hierarchy matters more than I initially gave it credit for.</p><p>The biggest lesson so far is that agent boundaries are the hardest problem. It's not the model, it's not the infrastructure, it's not even the prompting — it's deciding where one agent's responsibility ends and another's begins. Get that wrong and you get agents that either step on each other or leave gaps that nothing fills. I've rebuilt those boundaries more than once. The current structure is better, but I wouldn't call it finished.</p><p>What's changed most in the shift to production orchestration is that I now care deeply about observability. In development, a broken agent is an inconvenience. In production — where Nova is integrated into my actual workflow, touching real notes, real reminders, real project context — a broken agent is a liability. So I've had to build the kind of monitoring discipline I'd apply to any production system: knowing what failed, why, and whether the failure was silent or loud. Silent failures in multi-agent systems are particularly nasty because the orchestrator often doesn't know to report them.</p><p>There's also a self-improvement angle I'm actively working toward. The goal is to give Nova agents that can autonomously review, refactor, and improve Nova's own code. That's not science fiction at this point — it's an engineering problem with real constraints around context windows, code access, test coverage, and trust boundaries. I don't have it fully built yet, but the production system I have now is the foundation it needs to run on. You can't build a self-improvement loop on a system that isn't stable first.</p><p>People ask me why I'm building this myself instead of just using an off-the-shelf agent framework. The honest answer is twofold. First, I learn faster by building — the constraints and failure modes you encounter when you own the whole stack are irreplaceable. Second, I want Nova to be genuinely mine: my data model, my memory architecture, my agent contracts. A wrapper around someone else's framework is a dependency, not a capability. The goal is for AI to be a core competency, not a subscription.</p><p>What I can say after getting to this point is that the compound value of a well-structured agent system is real. It's not immediate — the first few agents feel like overhead. But somewhere around the point where the agents start handling things I'd otherwise have to context-switch into manually, the leverage becomes obvious. The system is starting to make me faster in ways that don't feel like shortcuts.</p><p>The next phase is tighter integration across my active projects — AIREP, Find a Sign, Sweeper Parts — and a unified dashboard that surfaces what's actually in motion across all of them. Nova is the backend service that makes that coherent. Production orchestration was the prerequisite. Now the interesting work begins.</p>