34 Agents in Production: What That Actually Means

<p>At some point in the last few weeks, Nova crossed a threshold I hadn't explicitly planned for. It went from a collection of experiments into something I'd call a production system. Not production in the "deployed to a server" sense — it's been running on infrastructure for a while. Production in the sense that I actually depend on it. It's in the loop for real work, every day.</p><p>Right now Nova has 34 agents. That number sounds either impressive or arbitrary depending on your perspective, and honestly, both reactions are fair. The number isn't the point. What matters is the spread: general chat, pipeline execution, ERP specialists, language tasks. Different agents for different contexts, all routing through a central orchestration layer that decides what gets handed to whom.</p><p>The orchestration phase is where things get interesting — and genuinely hard. Building a single capable agent is relatively straightforward. The research is mature, the tooling is decent, and the failure modes are obvious. Orchestration is a different problem. You're coordinating intent across multiple specialised components, managing state across a conversation or pipeline that might span several agents, and trying to do it in a way that doesn't feel like you're playing telephone with your own software.</p><p>The failure modes are subtler too. A single agent either answers well or it doesn't. In an orchestration system, you can have every individual agent performing correctly and still end up with a broken outcome because the routing logic made a bad call, or because the context passed between agents lost something important in translation. Debugging that is its own skill.</p><p>What I've come to think is that building multi-agent systems is less like software architecture and more like organisational design. You're defining roles, responsibilities, and handoff protocols. You're deciding what each component needs to know versus what it can safely ignore. The mistakes that hurt most aren't the ones where an agent gives a wrong answer — they're the ones where the system confidently does the wrong thing because no single agent had enough context to catch the error.</p><p>The other thing worth saying honestly: this isn't a product yet. Nova is a personal system. It runs my workflows, integrates with my projects — AIREP, Find a Sign, Sweeper Parts, this site — and it's built around my specific context. That's actually a feature, not a limitation. A system that knows your codebase, your clients, your current goals, and your past decisions is a fundamentally different thing from a general-purpose assistant. The personalisation is where the leverage comes from.</p><p>That's the broader bet I'm making. Not that AI is a useful tool to have in the toolkit — that's already table stakes for anyone paying attention — but that deep AI integration, built deliberately around your actual work, compounds over time. Every agent I add, every workflow I automate, every piece of context Nova retains about how I think and what I'm building, makes the next thing faster. The system gets more useful the more I use it, because it's learning the shape of my work, not just answering generic questions.</p><p>One of my current goals is to build a self-improvement loop into Nova — agents that can review, refactor, and improve Nova's own code. That's still ahead. But it feels less like a research project and more like a logical next step now that the orchestration layer is stable enough to trust. You can't have a system improve itself if it can't reliably execute tasks in the first place.</p><p>I don't have a clean conclusion here. The system works, it's genuinely useful, and it's more complex than I expected it to be when I started. The production orchestration phase isn't a finish line — it's the point where the interesting problems actually begin.</p>