Thirty-Four Agents and a Question of Control

<p>Nova hit a milestone recently that I haven't talked about publicly: it's running in what I'd call a production orchestration phase. That phrase sounds impressive, and in some ways it is, but it also papers over a genuinely uncomfortable question — when you have 34 agents operating across different domains, who's actually in charge?</p><p>Let me back up. Nova is my personal AI system. I built it to handle things I was doing manually and badly: managing context across multiple projects, surfacing relevant information when I need it, running pipelines, helping with ERP work, translating between technical and plain-English. The 34 agents span general conversation, pipeline execution, ERP specialists, and language tasks. Each one has a narrow job. That narrowness is intentional — it's the only way I've found to get reliable, auditable behaviour out of LLM-based systems.</p><p>But narrow agents create a coordination problem. When a task cuts across domains — say, a client query that touches AIREP data, requires a decision about branch-scoped access, and needs a written response — which agent owns it? How does context flow between them without getting lost or mangled? How do you debug a failure when it might have happened at step two of a six-step pipeline?</p><p>These aren't hypothetical problems. They're the actual work of the orchestration phase. And the honest answer is: I'm still solving them. Production doesn't mean finished. It means the system is running on real inputs, producing real outputs, and the failures now have real consequences instead of just being interesting test cases.</p><p>The thing that's shifted my thinking most is the difference between an agent that <em>works</em> and an agent that <em>behaves predictably under pressure</em>. In testing, almost everything works. In production, you find out what happens when the input is slightly malformed, when the context window is near its limit, when two agents disagree about the state of something. Those edge cases are where the design actually gets tested.</p><p>One of my current goals is to build a self-improvement loop — agents that autonomously review, refactor, and improve Nova's own code. I want to be clear-eyed about what that means. It doesn't mean Nova rewrites itself unsupervised. It means agents that can flag brittle patterns, suggest better implementations, and surface candidates for my review. The human stays in the loop on anything structural. The automation handles the scanning and the first draft of the fix. That's a meaningful distinction, and I think a lot of people building agent systems blur it in ways that create problems later.</p><p>The self-improvement loop is also where Nova starts to eat its own cooking. If the agents are good enough to help me build software for clients, they should be good enough to help me improve the system they run on. That's the test I'm most interested in — not benchmark scores, not demo videos, but whether the system makes itself measurably better over time in ways I can verify.</p><p>Thirty-four agents sounds like a lot. In practice, it reflects the actual surface area of the work I do. ERP systems have different concerns than a signage marketplace. Language tasks need different context than pipeline execution. I'd rather have more focused agents than fewer bloated ones. The coordination cost is real, but the alternative — a single catch-all agent that tries to do everything — produces outputs that are harder to trust and harder to fix when they're wrong.</p><p>What I've learned through this process is that building a multi-agent system forces you to be explicit about things you'd normally leave implicit. What does this agent know? What can it change? What does it hand off, and to whom? Those are good questions to have to answer. They make the system more legible, and they make me a better architect — not just for Nova, but for the client systems I build on top of similar principles.</p><p>The orchestration phase isn't glamorous. It's a lot of logging, a lot of edge case handling, and a lot of asking 'why did it do that?' But it's where the real work is. And right now, it's where I am.</p>