What It Actually Looks Like to Run a Multi-Agent AI System in Production

<p>There's a version of "I built an AI agent system" that means you wired up a single LLM call behind a function and called it an agent. I've been guilty of that framing at various points. What I'm running now with Nova is different, and the difference is worth being specific about.</p><p>Nova currently has 34 agents. They span general conversation, pipeline execution, ERP-domain specialists for AIREP, language tasks, and a growing set of coordination roles. That number isn't a vanity metric — it reflects the reality that a useful AI system for a working developer isn't one smart chatbot, it's a set of specialised tools that can be composed, routed between, and orchestrated depending on what you're actually trying to do.</p><p>The shift to what I'm calling the "production orchestration phase" means the system is no longer something I'm building in isolation and occasionally testing. It's running as real infrastructure that I rely on across projects — AIREP, Find a Sign, Sweeper Parts, client work, this blog. When it breaks or behaves badly, there are real costs. That accountability changes how you think about the design.</p><p>One thing I've noticed is that the hard problems in a multi-agent system aren't the ones that sound hard. Routing — deciding which agent handles a given input — sounds like the tricky bit. In practice, with clear agent scopes and a decent orchestration layer, routing becomes manageable. The genuinely difficult problems are subtler: context persistence across sessions, preventing agents from confidently doing the wrong thing, and knowing when a pipeline should stop and ask rather than proceed. These are behavioural problems as much as engineering ones.</p><p>The goal I'm working toward now is a self-improvement loop — agents that can review Nova's own code, flag problems, suggest refactors, and feed that back into the system. This is not science fiction territory; the pieces exist. What it requires is careful scoping. An agent that can rewrite code autonomously is useful only if you trust its judgment in the specific domain it's operating in, and only if the feedback loop includes a human checkpoint before anything lands in production. "Autonomous" and "unsupervised" are not the same thing, and conflating them is how you end up with a system that confidently degrades itself.</p><p>My broader view on AI in software development hasn't changed much: it's leverage, not magic. The developers and builders who treat it as a compound advantage — something that makes every hour of work more productive, every system more capable — will pull ahead of those who either ignore it or over-index on the hype. Neither extreme is useful. What's useful is building real things with it, running them under real conditions, and being honest about what works and what doesn't.</p><p>Nova is the clearest expression of that philosophy in my own stack. It's not a product yet — it's infrastructure I built for myself, shaped by the actual friction of running multiple projects simultaneously as a solo operator. The decisions baked into it (memory architecture, agent specialisation, the orchestration model) came from hitting real limits, not from designing in the abstract.</p><p>What's next is making the system smarter about its own state — not just what it knows, but what it's doing across projects, where things are stuck, and what needs attention. The multi-project orchestration dashboard I'm working toward is part of that: a unified view of work-in-progress across AIREP, Find a Sign, and client projects, surfaced through Nova rather than through a dozen separate tools.</p><p>That's the honest picture of where things are. Not a finished product, not a demo — a working system getting more capable in a controlled way, one piece at a time.</p>