Nova Hits the Orchestration Phase: 34 Agents and the Coordination Problem

<p>Nova — my personal AI multi-agent system — just crossed into what I've been calling the production orchestration phase. There are now 34 agents running across general chat, pipeline execution, ERP specialists, and language translation. That number sounds impressive until you realise the agent count was never the hard part. The hard part is coordination.</p><p>Spinning up another agent is cheap. Give it a prompt, a tool set, a job description, and you've got something that does a narrow task well. The first dozen felt like progress because each one solved a real problem. But somewhere past a certain point, the bottleneck stops being capability and starts being who decides what runs, in what order, and with what context. That's the orchestration problem, and it's where I've spent most of my recent time.</p><p>The naive version is a big router that reads a request and dispatches to whichever agent looks relevant. It works for simple cases and falls apart the moment a task needs two or three agents to cooperate — an ERP specialist that needs translation, say, or a pipeline step whose output feeds the next. You end up with agents that each do their job correctly while the overall result is wrong, because nobody owned the handoff. State leaks. Context gets dropped between steps. One agent assumes another already did something it didn't.</p><p>What's clarified for me is that orchestration is mostly a context-management problem wearing a routing costume. Each agent is only as good as what you hand it, and in a multi-agent system the thing handing it context is another agent. So the real engineering is in the seams: what gets passed forward, what gets summarised, what gets thrown away, and how a downstream agent knows what already happened upstream. Get the seams right and modest agents produce strong results. Get them wrong and your best agents produce confident nonsense.</p><p>This maps onto something I already believe about software generally: the interesting complexity lives at the boundaries, not inside the components. It's the same lesson as multi-tenant data design in AIREP, where the branch-scoped isolation between clients matters more than any single feature. The components are usually fine. The integration is where systems live or die.</p><p>The reason I'm building this for real, and not as a toy, is that I treat AI as the primary leverage point in how I work — not a tool I reach for occasionally, but core infrastructure. Nova is the AI backend behind keirantrace.com, it has ERP specialists that understand AIREP's domain, and the next milestone is a self-improvement loop: agents that review, refactor, and improve Nova's own code. That only makes sense if the orchestration layer is solid first. You don't let a system rewrite itself when you can't yet trust how its parts hand work to each other.</p><p>A few concrete things I've changed in this phase. I stopped treating agents as equals and gave certain ones explicit ownership of a workflow end-to-end, so there's always one accountable coordinator rather than a committee. I made context-passing deliberate instead of dumping everything forward — more agents fail from too much irrelevant context than too little. And I started logging the handoffs themselves, not just the agent outputs, because when something goes wrong the bug is almost always in the seam, not the agent.</p><p>I'm being honest about the state of it: orchestration is in production, but it's the early, watchful kind of production where I'm still reading the logs closely. There's no point pretending 34 agents means it's done. It means the coordination surface is now big enough to be the real work.</p><p>The next step is the self-improvement loop, and that's the part I'm genuinely interested in — the point where Nova starts helping build Nova. But that's a post for when it actually works, not before. I'd rather write about things that run than things I'm hoping will.</p>