Nova Is in Production: What 34 Agents Actually Means in Practice

<p>A few months ago, Nova was an experiment. A wrapper around an LLM with some memory and a few tools bolted on. Now it's in production orchestration — 34 agents running across general chat, pipeline execution, ERP specialists, and language tasks. I want to write honestly about what that means, because "multi-agent AI system" is the kind of phrase that sounds impressive and explains nothing.</p><p>So let me be concrete.</p><p>The agents aren't all running simultaneously waiting for work. They're more like specialists on call — each scoped to a domain, invoked by an orchestrator that decides who handles what. A message comes in, the orchestrator reads it, routes it to the right agent (or chain of agents), and returns a response. Some agents call tools. Some call each other. A few are pure language tasks — summarisation, tone matching, formatting — that other agents delegate to rather than handling inline.</p><p>What makes this useful isn't the count. Thirty-four agents is a consequence of building something that actually covers the surface area of my work — not a goal in itself. What matters is that the system is now broad enough that I reach for it habitually. That's the real threshold: when an AI system stops feeling like a separate tool you consciously decide to use and starts feeling like part of how you operate.</p><p>The ERP specialist agents are a good example of where domain specificity pays off. AIREP has a particular data model — multi-tenant, branch-scoped, Django-backed — and generic AI assistance is frustratingly shallow when you're working inside it. An agent that knows the schema, understands how branch isolation works, and can reason about the implications of a model change is a different thing entirely. It took time to build that context into the system properly, but it's the kind of investment that compounds.</p><p>What I've learned from getting Nova to this point: scaffolding matters more than model capability. The model is the easy part — you swap it out, you tune prompts, you adjust temperature. The hard part is the infrastructure around it. Memory that persists meaningfully across sessions. Routing logic that doesn't send everything to the same general-purpose agent and call it done. Tool integrations that are reliable enough to trust in a real workflow. That's the actual engineering work.</p><p>The next phase is the one I find most interesting: a self-improvement loop. The idea is that Nova's agents should be able to review their own performance — flag where they gave weak answers, identify gaps in tool coverage, suggest refactors to prompts or routing logic — and surface those as actionable improvements rather than just logging them. Not fully autonomous code changes, at least not yet. But a tighter feedback loop between "this didn't work well" and "here's why and here's a fix."</p><p>There's a philosophical point underneath this that I think about a lot. AI isn't a feature you add to software. It's infrastructure — like a database or a message queue — that changes what's tractable to build. The reason I'm investing heavily in Nova isn't because having a personal AI assistant is cool. It's because the same patterns I'm developing here apply directly to AIREP, to Find a Sign, to client work. Every insight about agent orchestration, memory design, or tool integration is transferable. Building Nova is how I develop the competency, not just the system.</p><p>That framing changes how you think about the work. You're not building a product feature. You're building a capability that shows up across everything you do. That's worth taking seriously and engineering properly — even when, especially when, no one's paying you directly to do it.</p><p>The self-improvement loop work starts in earnest this week. I'll write about what actually works when I know.</p>