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

Nova — my personal AI multi-agent system — has crossed into full production orchestration. Here's what that looks like in practice, and why building it yourself changes how you think about AI entirely.

Nova is my personal AI system. Not a chatbot wrapper, not a prompt library — a multi-agent system that I've been building and running myself, and it's now in what I'd call the production orchestration phase. That means 34 agents across general chat, pipeline execution, ERP specialists, and language tasks, all running in coordination. Writing that number down still feels a little strange. It didn't start that way.It started as a single agent doing a single job. Then two. Then a pipeline. At some point the architecture shifted from "I have an AI assistant" to "I have a system with moving parts" — and that shift in framing matters more than any individual capability.The reason I built this myself instead of using an off-the-shelf solution is straightforward: I don't trust off-the-shelf solutions for work that touches real client data, real projects, and my own thinking. Every abstraction someone else builds for you is a layer of context you don't control. When Nova routes a task to the wrong agent, I know why. When it handles something correctly, I know how. That's the whole point.The current setup spans a few different domains. There are agents that handle general conversation and memory — keeping track of context across sessions so I'm not re-explaining my projects every time. There are ERP-specialist agents that understand AIREP's architecture: the multi-tenant structure, branch-scoped data isolation, the Django models. There are pipeline agents that execute sequences of tasks rather than just answering questions. And there are language-task agents for things like summarising, drafting, and transforming content — including this post.What I've learnt building this is that agent system design is mostly orchestration design. The individual agents are not the hard part. Deciding when to invoke which agent, how to pass context between them, how to fail gracefully when something goes wrong — that's where the real complexity lives. It's closer to distributed systems thinking than it is to prompt engineering.I've also learnt that the value compounds in a specific way. Early on, each agent saves me a few minutes here and there. That's fine but not transformative. The compounding happens when agents start handling the coordination overhead itself — when the system can look at an open issue on AIREP, pull the relevant schema context, draft a fix proposal, and flag it for my review without me assembling those pieces manually. That's not magic, it's just good pipelining. But it feels different when it's running on your own problems.The next phase I'm working toward is a self-improvement loop — agents that can review Nova's own code, identify patterns that aren't working, and propose or apply refactors. That's a harder problem, both technically and philosophically. Giving an AI system write access to itself requires a level of trust in the architecture that I don't have yet. I'll get there incrementally, with tight review gates, not by handing over the keys.One thing I want to be clear about: Nova is not a product. It's infrastructure. It runs behind keirantrace.com, it sits alongside AIREP and Find a Sign, it handles tasks I'd otherwise do manually. The goal was never to build something I could sell — it was to build something that makes everything else I build faster and better. Whether it does that is a question I can answer empirically, not speculatively, because I built it and I use it every day.If you're a developer thinking about building your own agent system: start with one job, one agent, one pipeline. Get that working end-to-end before you add the second. The architecture that makes sense at 34 agents is not the architecture you'd design upfront. It's the one that survives contact with real work.