34 Agents Later: What I've Learned About Building a Multi-Agent System That Doesn't Fall Over

<p>Nova started as a single assistant. Now it's 34 agents — general chat, pipeline execution, ERP specialists, language tools, and whatever else I've bolted on as a need showed up. Somewhere in that growth I crossed a line from "I have a chatbot with some scripts" to "I have a system I need to actively orchestrate." That transition taught me more than any of the individual agents did.</p><p>The first thing that broke was my assumption that more agents equals more capability, linearly. It doesn't. Every new agent is a new surface for ambiguity — which agent should handle a given request, what happens when two agents disagree, who owns a piece of state. Add agents without adding coordination and you get a system that's technically more capable and practically less reliable. That's not a hypothetical, it's just what happened when I stopped treating each new agent as an isolated addition and started noticing the cross-talk.</p><p>The fix wasn't more intelligence, it was more structure. Clear boundaries on what each agent is responsible for, explicit handoff points instead of implicit ones, and — this is the boring but important part — logging and visibility into what actually happened during a multi-agent run. When something goes wrong in a 34-agent system, "it didn't work" is useless. You need to know which agent picked up the task, what it decided, and where it handed off. Without that, debugging is archaeology.</p><p>This is also where the idea of a self-improvement loop for Nova started making real sense to me, rather than just being an interesting idea. If Nova is going to keep growing in agent count, I don't want to be the only reviewer checking whether new agents are well-scoped or whether an old one has drifted into doing something it shouldn't. I want agents that can review Nova's own code and flag inconsistency — not to replace my judgment, but to catch the stuff that's tedious for a human to keep watching for as the system scales. That's a harder problem than it sounds, because you need enough trust in the reviewing agent to act on its findings, and enough skepticism to not blindly ship what it suggests. I'm not there yet. But the architecture decisions I'm making now — clear agent boundaries, explicit state, visible reasoning — are exactly the prerequisites for that loop to eventually work.</p><p>There's a broader lesson here that applies past Nova. In AIREP, the multi-tenant branch-scoped architecture works for the same reason: isolation and clarity of ownership beat cleverness. A system that's easy to reason about, even if less elegant, will outlast one that's technically impressive but opaque. I keep re-learning this in different codebases and it keeps being true.</p><p>The orchestration dashboard I've been planning — the unified view of work-in-progress across AIREP, Find a Sign, Nova, and everything else — is really the same problem at a different layer. Right now I hold that state in my head, which doesn't scale any better for me than implicit coordination scales for Nova's agents. If I want AI to be a genuine multi-project leverage point rather than just a set of point solutions, I need the same kind of visibility into my own work that I'm trying to build into Nova's agent coordination. Same principle, different scope.</p><p>None of this is glamorous. Nobody writes a blog post excited about logging and boundary definitions. But it's the actual work of making a multi-agent system trustworthy enough to build on, rather than a demo that's impressive until you push on it. 34 agents in, that's the lesson that's sticking: capability without structure is just risk you haven't found yet.</p>