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

<p>Nova hit a milestone recently that I keep having to explain carefully, because it sounds more impressive than it is — and also more mundane than it actually is. The system now runs 34 agents across general chat, pipeline execution, ERP specialists, language tasks, and more. It's in what I'm calling a production orchestration phase, meaning it's no longer a prototype I poke at occasionally. It's running. It's doing real work.</p><p>But "34 agents in production" is the kind of phrase that can mean almost anything depending on who's saying it. So let me be specific about what it means in this case, and honest about where the hard parts are.</p><p>Each agent in Nova is purpose-scoped. There's no single general-purpose AI trying to do everything — that's a trap I deliberately avoided. Instead, agents are narrow: one handles ERP-related queries for AIREP, another manages reminders, another handles email context, another orchestrates pipelines between the others. The orchestration layer is what's in active development right now — deciding which agent handles what, passing context correctly between them, and doing that reliably across a growing surface area.</p><p>The reliability part is where it gets genuinely hard. When you have one model and one task, failure modes are obvious. When you have 34 agents with interdependencies, a bad context pass or a misrouted query can fail silently in ways that are annoying to trace. You start caring deeply about things like: does this agent get the right memory context? Does the orchestrator know when to escalate versus when to resolve locally? What happens when two agents give conflicting outputs?</p><p>These aren't AI research problems — they're software engineering problems with an AI flavour. And that framing matters to me. I'm not building Nova because I think large language models are magic. I'm building it because I think the compound effect of well-scoped, well-integrated AI agents is a real leverage point for how I work and what I can build. The intelligence is in the architecture, not just the models.</p><p>One of my current goals with Nova is building a self-improvement loop — agents that autonomously review, refactor, and improve Nova's own code. That's still ahead of where I am, but the production orchestration phase is the prerequisite. You can't have a system that improves itself if the base system isn't stable and observable first. So right now I'm focused on the boring fundamentals: reliable routing, clean memory retrieval, consistent agent behaviour across sessions.</p><p>What I've noticed building this is that the skill gap in AI systems isn't prompt engineering. It's systems design. Knowing how to scope an agent, how to pass state without bloating context, how to make the whole thing debuggable — that's where most of the real work lives. The models themselves are increasingly commoditised. The architecture around them is where differentiation happens.</p><p>This is also why I'm positioning Nova as a core part of my broader technical stack, not a side project. It already surfaces as the backend AI service on keirantrace.com. It's the foundation I want to bring into AIREP and Find a Sign as those products mature. The goal isn't AI for its own sake — it's AI as a genuine compound advantage: something that gets more useful the more context it accumulates and the more tightly it integrates with the tools I actually use day-to-day.</p><p>34 agents sounds like a lot. In practice it means I've had to think carefully about scope, ownership, and failure modes 34 times. That's the work. And it's the kind of work I think most people underestimate when they talk about "building with AI." The models are the easy part. The system is the hard part. That's true whether you're building an ERP, a marketplace, or a personal AI that's supposed to make you more effective at both.</p>