34 Agents Later: What It Actually Means to Run a Personal AI System in Production

<p>Nova is in production. Not "I have a chatbot running" production — I mean a multi-agent orchestration system with 34 specialised agents handling general conversation, pipeline execution, ERP-domain queries, language tasks, and more. It's been a long build, and calling it done would be wrong, but calling it production is now accurate.</p><p>I want to write about what that actually means, because most of the discourse around personal AI assistants sits at one of two extremes: either it's a party trick ("I asked ChatGPT to write my emails") or it's vague futurism ("AI will change everything"). Neither captures what it feels like to have a real system running against your real work.</p><p>The short version: it feels like infrastructure. And that framing matters.</p><p>When I think about Nova, I don't think about it the way I think about a tool I pick up and put down. I think about it the way I think about my database — it's always there, it holds state, and when it's wrong or slow, everything downstream suffers. That shift in mental model changes how you build it. You stop optimising for impressive demos and start optimising for reliability, correctness, and the cost of failure.</p><p>The 34-agent architecture didn't happen by design from day one. It grew from a simpler system as I kept hitting the same wall: a general-purpose agent is fine until you need it to do something specific well. ERP queries have a particular shape. Language tasks — translation, summarisation, extraction — have a different shape. Pipeline execution has different reliability requirements than a conversational response. Splitting by domain and task type was the obvious answer, and it's held up.</p><p>What I didn't anticipate was how much of the engineering effort would be about the seams between agents — routing, context handoff, knowing when to escalate versus when to answer. That's the genuinely hard part. Any individual agent is tractable. Making them work together without losing thread is where the real complexity lives.</p><p>The current orchestration phase is about exactly that. I'm focused on making sure the right agent gets the right context at the right time, without the user (which is mostly me) having to think about which agent they're talking to. The goal is a system that feels like one coherent intelligence, not a directory of specialists you have to manually navigate.</p><p>One thing I've been deliberate about: Nova is not a product right now. It's my system, running against my projects — AIREP, Find a Sign, Sweeper Parts, client work. The agents have context about those projects because I've built that context in. That specificity is the value. A general assistant that knows nothing about your actual work is a lot less useful than a system that knows your database schema, your open issues, and what you were thinking last Tuesday.</p><p>There's a goal I've written down explicitly: build a Nova self-improvement loop — agents that can autonomously review, refactor, and improve Nova's own code. That's not science fiction, it's an engineering problem. It requires good test coverage, sandboxed execution, and a clear definition of "better." I don't have all of that yet. But having 34 agents in production is the prerequisite. You can't automate improvement of a system that doesn't exist yet.</p><p>The broader point I keep coming back to is this: AI is not a feature you add to software. It's a capability layer that, if you build it seriously, compounds. Every agent I add makes the system more useful. Every piece of project context I wire in makes the agents more accurate. The return on investment isn't linear — it accelerates as the system matures. That's why I think of it as a core business competency rather than a productivity tool.</p><p>If you're a developer thinking about building something similar: start smaller than you think you need to, be ruthless about what actually needs to be an agent versus a function, and treat context management as a first-class engineering concern. The LLM is the easy part. The hard part is everything around it.</p><p>More updates as the orchestration layer matures. There's a lot still to build.</p>