← Back to blog

34 Agents and Counting: What Running Nova in Production Actually Looks Like

· 3 min read

Nova, my personal AI system, has crossed into full production orchestration — 34 agents handling everything from general chat to ERP workflows. Here's what that actually means day-to-day, and why the architecture decisions behind it matter more than the agent count.

<p>The number that keeps coming up when I describe Nova is 34. Thirty-four agents, running across general chat, pipeline execution, ERP specialists, language tasks, and more. People hear that and either think it sounds impressive or think it sounds like overkill for a personal system. I'm not sure either reaction is quite right.</p><p>Nova started as a practical problem: I run multiple projects simultaneously — AIREP, Find a Sign, Sweeper Parts, client websites, this blog — and the cognitive overhead of context-switching between them is real. I wanted something that could hold context, execute tasks, and act as a genuine second layer of operational capacity, not just a smarter autocomplete. The multi-agent architecture was a deliberate choice to match the shape of the actual work: different domains, different tools, different reasoning requirements.</p><p>What does "production orchestration phase" actually mean in practice? It means the system is no longer experimental. Agents aren't being tested in isolation anymore — they're being invoked as part of real workflows, with real outputs feeding into real decisions. A pipeline agent might pull together project status across AIREP and Find a Sign. An ERP specialist agent might reason about branch-scoped data structures in Django. A language task agent handles things like drafting client-facing content or summarising long threads. The orchestration layer sits above all of this and routes tasks to the right agent based on what's being asked.</p><p>The engineering side of this is where it gets interesting. The temptation with agent systems is to make them monolithic — one giant context, one model, handle everything. That falls apart quickly. What I've found is that keeping agents narrow and purposeful is what makes the system reliable. A general-purpose agent that tries to do everything becomes unpredictable. An agent with a specific scope, specific tools, and a clear exit condition is something you can actually trust to run unsupervised.</p><p>One of the current goals I'm working toward is a Nova self-improvement loop — agents that can autonomously review, refactor, and improve Nova's own code. That's not a gimmick. If the system can identify its own failure modes and propose fixes, that's compounding leverage. Every improvement cycle makes the next one cheaper. But it requires the architecture to be clean enough that an agent can reason about it without getting lost, which is itself a forcing function for good design.</p><p>There's a broader point here about AI as a business competency rather than a feature. I'm positioning AIREP, Nova, and Find a Sign around AI as a primary differentiator — not because it's trendy, but because the compounding advantage is real. A system that gets incrementally smarter, that holds institutional context, that can execute multi-step workflows without hand-holding — that's a different class of capability than bolting an LLM API call onto an existing product. The distinction matters, and I think most teams building "AI features" are still thinking in the wrong frame.</p><p>The honest version of where Nova is right now: it's genuinely useful, it's in production, and it's still rough in places. Some agents are more reliable than others. The orchestration routing makes mistakes. There are edge cases in the pipeline execution layer that I haven't fully resolved. I'm not going to pretend it's a finished product — it's a system I use every day and improve every week. That's the point. The goal isn't to ship a perfect AI system; it's to build something that compounds in value over time as I keep working on it.</p><p>If you're building something similar — a personal AI system, an agent-based workflow, anything where you're trying to make LLMs reliable over a sustained period — the thing I'd emphasise most is operational discipline. Logging, scoping, failure handling, clear agent contracts. The model capability is largely a solved problem at this point. The hard part is the plumbing around it. Get that right, and the number of agents stops being a party trick and starts being a genuine force multiplier.</p>

Comments

No comments yet — be the first!

Leave a comment

Comments are held for moderation before appearing.