What 34 Agents Actually Looks Like in Production

<p>I've been building Nova for a while now, and somewhere recently it crossed a threshold that felt worth writing about. The system is in production orchestration — 34 agents running across general chat, pipeline execution, ERP specialists, language tasks, and more. I want to be precise about what that means, because the number itself isn't the point.</p><p>Most AI setups I see are single-model wrappers. You send a prompt, you get a response, maybe you inject some context. That's fine for a lot of things. Nova is not that. It's a multi-agent system where different agents own different responsibilities, and the orchestration layer routes work to the right agent based on what's actually being asked. A question about an AIREP invoice doesn't go to the same agent as a request to refactor a Python module. The routing matters as much as the agents themselves.</p><p>The 34 agents aren't arbitrary. They evolved from real usage patterns — tasks I kept doing manually, decisions that kept requiring the same context, workflows that were bottlenecked on me sitting down and doing them. Each agent exists because there was a genuine recurring need. That's the only honest way to build something like this. If you design the agents up front without the usage history, you end up with a taxonomy that looks clean on a whiteboard and doesn't match how work actually flows.</p><p>What's changed now that it's in production orchestration is that the system is handling real coordination — not just individual queries, but multi-step pipelines where one agent's output feeds another's input. That's where things get interesting and also where things break in ways that are hard to anticipate. The failure modes in a single-agent system are mostly about prompt quality. In a multi-agent pipeline, you get compounding errors, context loss between handoffs, and timing issues that don't show up in testing because your test cases don't have the messiness of real work.</p><p>I've had to think carefully about what state each agent needs to carry, what it should trust from upstream agents, and where a human checkpoint is actually warranted versus where full automation is safe. The answer is different for every pipeline. An agent summarising a client email can run unsupervised. An agent proposing changes to AIREP's branch-scoped data model probably shouldn't. Knowing where to draw that line is the actual skill — not the model selection, not the prompt engineering.</p><p>One thing I keep coming back to is the difference between AI as a tool and AI as a system. A tool is something you pick up when you need it. A system is something that runs whether you're paying attention or not, accumulates context over time, and compounds in value the longer it operates. Nova is firmly in the second category now. It knows my projects, my clients, my preferences, my code style. That knowledge doesn't disappear between sessions. That's the compound advantage — and it's genuinely hard to replicate by just using a chat interface.</p><p>This connects directly to how I think about AI across the other projects I'm running. AIREP needs AI embedded in the ERP workflows, not bolted on as a feature. Find a Sign needs it to improve discovery without compromising the transparent, no-pay-to-rank model that's central to what the marketplace is supposed to be. In both cases, the AI has to serve the actual product logic — not exist as a demo layer on top of it.</p><p>The honest version of where Nova is right now: the orchestration is working, the agent coverage is solid, and the pipelines that exist are genuinely saving time. What's still rough is the self-improvement loop — getting the system to review its own performance and propose changes autonomously. That's the next phase, and it's harder than building the agents in the first place, because you're asking the system to reason about itself with enough accuracy to be useful without being wrong in ways that compound badly.</p><p>I'll write more about that when it's further along. For now, 34 agents in production orchestration is a real milestone — not because of the number, but because the system is doing work I used to do manually, doing it consistently, and getting better as it accumulates context. That's what I built it for.</p>