← Back to blog

Running 34 Agents: What Nova's Production Phase Actually Looks Like

· 3 min read

Nova, my personal AI system, has crossed into production orchestration — 34 agents handling everything from general chat to ERP workflows. Here's what that actually means to build and run.

<p>A few months ago Nova was a prototype. A single agent, a handful of tools, a lot of manual wiring. Today it's running 34 agents across four broad categories: general chat, pipeline execution, ERP specialists, and language tasks. That number sounds impressive until you realise the hard part isn't getting to 34 — it's making 34 things work together without turning into a mess you can't reason about.</p><p>I want to be honest about what "production orchestration phase" actually means, because it's easy to dress up a project milestone in language that obscures more than it reveals. For Nova, it means the system is now the primary backend for my own day-to-day work. Agents are being invoked in real workflows, not just test harnesses. When something breaks, it breaks in a context that matters. That's a different kind of pressure than development, and it forces a different kind of discipline.</p><p>The agent categories reflect how the work actually splits. General chat agents handle open-ended queries and conversation — the interface layer. Pipeline agents are where the real orchestration happens: they coordinate multi-step tasks, hand off between specialists, and manage state across a job that might touch several systems. ERP specialists are purpose-built for AIREP workflows — they understand branch-scoped data, multi-tenant isolation, and the domain-specific logic of an ERP context. Language task agents handle the text-heavy work: summarisation, drafting, extraction.</p><p>What I've learned building this is that agent count is almost the least interesting metric. The interesting questions are about boundaries: what does each agent know, what can it touch, and what happens when it fails? Getting that wrong means you end up with agents that either do too little — overly narrow, constantly needing human intervention — or too much, where a single bad call cascades into something hard to recover from. Most of the architectural work in the past few months has been drawing those lines carefully and then stress-testing them.</p><p>The ERP specialists have been the most technically demanding. AIREP uses branch-scoped data isolation, which means an agent operating in a client context has to be constrained to that branch — it can't bleed across tenant boundaries. Enforcing that at the agent level, not just the database level, required building explicit scope-awareness into how each specialist is initialised and how it constructs queries. It's the kind of constraint that doesn't show up in generic AI tutorials but matters enormously in a real product.</p><p>Pipeline execution has been the most rewarding to get right. When you have a task that genuinely requires five steps — each with different tools and different failure modes — and you can hand it off to a coordinator agent that routes, monitors, and recovers without you babysitting it, that's when the compound value of the system starts to feel real. It's not magic. It's just careful design that finally works well enough to trust.</p><p>One thing I'm still working on is observability. When a pipeline runs across multiple agents, understanding what happened — and why something went wrong — requires more than just logs. You need to be able to trace a decision back through the chain of agents that made it. I have the basics in place, but it's not where I want it yet. That's the next phase of work.</p><p>The longer-term goal is a self-improvement loop: agents that can review Nova's own code, flag weaknesses, and propose refactors. That's not running yet. But getting to 34 agents in production is the foundation it needs to sit on. You can't build a system that improves itself if the system isn't stable enough to trust in the first place.</p><p>If you're building something similar — a personal AI layer over your own work — my honest advice is to resist the urge to scale agent count early. Start with one agent that does something genuinely useful. Add the second one only when the first one isn't enough. The architecture that survives is the one that grows from real constraints, not from enthusiasm about what's theoretically possible.</p>

Comments

No comments yet — be the first!

Leave a comment

Comments are held for moderation before appearing.