What Running 34 AI Agents in Production Actually Looks Like

<p>Nova started as an experiment. I wanted a personal AI system that was genuinely useful across my work — not a chatbot wrapper, not a glorified autocomplete, but something that could actually participate in the work I do every day across multiple projects. That was the idea. The reality of getting there has been a lot more instructive than I expected.</p><p>As of now, Nova runs 34 agents. They span general chat, pipeline execution, ERP specialists, language tasks, and more. I call the current phase "production orchestration" — which is a precise way of saying that the individual agents mostly work, and the hard problem has shifted to making them work <em>together</em>, reliably, across real workloads rather than test cases I wrote myself.</p><p>That shift is significant. Building a single agent that does one thing well is a solvable problem. You define the inputs, the outputs, the tools it can call, and you iterate until it's reliable enough to trust. Building a system where agents hand off to each other, where the output of one becomes the context for another, where failures need to propagate cleanly rather than silently corrupt downstream results — that's a different class of problem. Orchestration is where most of the complexity lives.</p><p>A few things I've learnt in getting to this point. First: context management is everything. Agents don't share memory by default, and the naive approach of passing full conversation history around doesn't scale. You end up with bloated prompts, degraded performance, and subtle errors that are genuinely hard to trace. The solution I've landed on is structured, scoped memory — agents get exactly the context they need for their role, no more. Nova has its own memory system for this, and getting that right has been more important than almost any other design decision.</p><p>Second: the boundary between "agent" and "pipeline step" is blurrier than it sounds in theory. Some things that look like agents are really just deterministic functions with an LLM call bolted on. That's fine — sometimes that's exactly what you want. But it means you need to be honest about what you're actually building at each layer, or you end up with unnecessary complexity dressed up as intelligence.</p><p>Third: production means different things depending on who you ask. For me, production means Nova is running in real workflows — helping with AIREP development, client work, writing, research — and the cost of a failure is actual lost time, not just a failed test. That's a useful forcing function. Things that were "good enough" in development turn out to have sharp edges when they're handling real tasks with real stakes.</p><p>The next goal I'm working toward is a self-improvement loop: agents that can autonomously review, refactor, and improve Nova's own codebase. This sounds ambitious, and it is, but the logic is straightforward. If AI is genuinely useful for software development — and in my experience it clearly is — then a system that can apply that capability to itself compounds over time in a way that manually-maintained systems can't. The bottleneck right now is trust: I need robust enough evaluation that I can let an agent propose a code change without having to review every line myself. That's a hard problem, and I don't have it fully solved yet.</p><p>What I do have is a system that's already useful enough to change how I work. Nova handles things I used to context-switch into manually — summarising, drafting, looking things up across projects, flagging things I'd asked it to track. The 34-agent number isn't a vanity metric; it reflects the actual surface area of tasks I've found worth automating. Some agents I use every day. Some exist for specific situations and sit idle most of the time. That's fine. The point isn't utilisation — it's coverage.</p><p>If you're building something similar, the honest advice is: start with one agent that does one thing you actually need, get it to production, and learn from that before you scale. The orchestration problems don't show up until you have real workloads. Everything before that is theory.</p>