What Running 34 AI Agents in Production Actually Looks Like

<p>I've been building Nova — my personal multi-agent AI system — for a while now. It started as a way to automate the tedious coordination overhead that comes with running several projects simultaneously. It's now in what I'd call a production orchestration phase, which sounds impressive until you're the one debugging why an agent handed off a malformed context payload at 11pm.</p><p>The system currently runs 34 agents. They span general chat, pipeline execution, ERP specialists for AIREP, language tasks, and a handful of domain-specific workers. That number isn't a vanity metric — it reflects how granular you have to get once you stop thinking of AI as a single chatbot and start thinking of it as a workforce with specialised roles. A general-purpose agent that does everything is fine for demos. It's not fine when you need reliable, repeatable behaviour across different domains with different failure tolerances.</p><p>The honest reality of running a system like this is that orchestration is the hard part. The individual agents are, in isolation, fairly straightforward to build and prompt. The difficulty is in how they hand work to each other — what context they pass, what they assume the next agent already knows, and what happens when something in the middle of a pipeline fails. These aren't hypothetical concerns. They're the actual problems I'm solving right now.</p><p>One thing I've learnt is that agent boundaries matter enormously. The temptation early on is to make agents broad — give one agent a big job and let it figure out the subtasks. In practice, broad agents produce inconsistent outputs because the surface area of what they're doing is too large to prompt reliably. Narrow agents with well-defined inputs and outputs are far easier to test, debug, and improve. The tradeoff is that you end up with more of them, and then the orchestration layer becomes its own engineering problem.</p><p>Context management is the other thing nobody talks about enough. Every agent in a pipeline needs enough context to do its job, but not so much that it gets confused or starts hallucinating relevance between things that aren't related. Getting that balance right is less about prompting and more about architecture — deciding what information lives where, what gets passed explicitly, and what gets retrieved on demand. I've built Nova's memory layer to handle a lot of this, but it's an ongoing calibration.</p><p>The next thing I'm working toward is a self-improvement loop — agents that can autonomously review Nova's own code, flag issues, and propose refactors. This isn't science fiction; the primitives are all there. But it requires a level of trust in the system's outputs that you only earn after it's been running reliably for long enough that you stop second-guessing every result. I'm not there yet, and I'm not going to pretend otherwise.</p><p>What I can say is that having a production multi-agent system running against my own real workloads — AIREP, client projects, this site — is a different kind of development experience than anything I had before. The feedback loop is immediate and honest. When something doesn't work, it doesn't work on a task that actually matters, which is a far more effective forcing function than any test suite I've written.</p><p>The broader point I keep coming back to is that AI as a compound advantage isn't about using the best model or having the most agents. It's about building infrastructure that compounds — where each improvement to the system makes the next improvement easier. That's what Nova is becoming, slowly and with a lot of debugging along the way. The production phase isn't the finish line. It's where the real work starts.</p>