What Running 34 AI Agents in Production Actually Looks Like

<p>There's a version of this post where I call Nova a breakthrough and talk about how AI is changing everything. I'm not going to write that post. Instead I want to talk about what it actually looks like to have a multi-agent AI system in production — because the reality is more interesting, and more useful, than the hype version.</p><p>Nova is my personal AI system. It started as a way to stop losing context across projects — a smarter scratchpad that could remember decisions, surface relevant notes, and handle repetitive thinking tasks. It's grown into something with 34 agents across general chat, pipeline execution, ERP specialists, language tasks, and now what I'm calling a production orchestration phase. That last part is the one worth unpacking.</p><p>Orchestration sounds impressive. What it means in practice is that agents can now hand off work to each other in a structured way — a request comes in, a routing layer decides which agent or chain of agents handles it, and the output flows back. The Blog Writer agent that produced this post is part of that system. So is the agent that searches memory before writing, and the one that decides whether something is worth archiving for later. None of this is magic. It's plumbing. Good plumbing, but plumbing.</p><p>The thing I keep coming back to is how much of building an agent system is just software engineering. People treat AI agents like they're a separate discipline — and there are genuinely new problems, especially around reliability, prompt design, and managing context windows — but most of the hard work is the same stuff: clear interfaces between components, sensible data models, knowing when to fail loudly instead of silently degrading. The agents that work best are the ones with the narrowest scope. The ones that cause problems are the ones I tried to make too general too early.</p><p>34 agents sounds like a lot. Some of them are thin wrappers — a specialist that knows AIREP's data model, a few that handle different language tasks. The number matters less than the architecture holding them together. Right now the next meaningful goal is building a self-improvement loop: agents that can review Nova's own code, identify weak spots, and propose refactors. That's not science fiction at this point, but it's also not trivial. The challenge isn't getting an LLM to read code — it's giving it enough context about intent, constraints, and history to make suggestions that are actually useful rather than just technically valid.</p><p>The reason I'm building this on my own infrastructure rather than using an off-the-shelf agent framework is the same reason I build most things from scratch when the domain matters: I want to understand every layer. When something breaks in production — and things break — I need to be able to trace it. Black-box orchestration tools are fine for prototyping, but for a system I'm going to rely on daily across AIREP, Find a Sign, client work, and my own thinking, I need to own the failure modes.</p><p>The honest summary of where Nova is right now: it works, it's genuinely useful, it's in production in the sense that I depend on it every day, and it's still rough in places. The orchestration layer is functional but not elegant. The memory system is good enough to surface relevant context most of the time. The self-improvement loop is a goal, not a reality yet.</p><p>I think that's actually the right place to be at this stage. Useful before perfect. In production before fully polished. The alternative — waiting until it's elegant before depending on it — is how projects stay in development forever. Nova is a tool I use to build better software faster. The fact that it's also a project I'm actively developing at the same time is occasionally confusing, but mostly it's the best feedback loop I've ever had.</p>