Nova Is in Production: What Running 34 Agents Actually Looks Like

<p>Nova started as a personal experiment. The idea was simple enough: instead of reaching for a different AI tool every time I needed something done, build one coherent system that knows my projects, my preferences, and my context — and route tasks through it intelligently. That was the pitch I made to myself. The reality of getting there has been considerably messier, and considerably more interesting.</p><p>As of now, Nova is in what I'm calling the production orchestration phase. There are 34 agents running across the system — covering general chat, pipeline execution, ERP specialists, language tasks, and more. That number sounds large, and honestly it felt large when I tallied it up. But each agent exists because a generic prompt wasn't good enough. A general-purpose assistant doesn't know that AIREP uses branch-scoped multi-tenancy, or that Find a Sign's entire value proposition is built on not paying to rank suppliers. Specialised agents do. The granularity is the point.</p><p>What does production orchestration actually mean in practice? It means Nova isn't just answering questions — it's receiving tasks, deciding which agent or pipeline handles them, executing across multiple steps, and returning structured output. The orchestration layer is what separates a collection of useful prompts from a system. Without it, you have a toolbox. With it, you have something closer to a junior team member who knows where everything lives.</p><p>Building this has forced me to think hard about agent boundaries. The temptation early on was to make agents broad — one agent for "code stuff", one for "writing stuff". That falls apart fast. Broad agents produce broad answers. The discipline of scoping an agent tightly — giving it a specific domain, a specific set of inputs it's expected to handle, and a clear output contract — is the same discipline that makes good software design in general. It's not an AI problem, it's a design problem wearing an AI costume.</p><p>The other thing I've learnt is that memory architecture matters more than model choice. I've put significant effort into how Nova stores and retrieves context — notes, reminders, conversations, project state. A smarter model with bad memory is less useful than a mid-tier model that actually remembers what you told it three days ago. The retrieval layer is where most of the real leverage is. That's not an intuitive conclusion when you start out, because the model is the visible, exciting part. But the memory is what makes the system feel like it knows you.</p><p>There's a goal I've been working toward that I think of as the self-improvement loop — agents that can review, refactor, and improve Nova's own code autonomously. That's not live yet. But the production orchestration phase is the prerequisite. You can't have a system that improves itself if the system isn't stable and observable enough to reason about. Getting to 34 agents in production is the foundation, not the destination.</p><p>I'm also aware that "personal AI system" sounds like a vanity project. I don't think it is, but I understand why it reads that way. The honest case for it is this: every project I run — AIREP, Find a Sign, Sweeper Parts, client work — benefits from a system that already has context about all of them. The alternative is context-switching overhead, re-explaining the same architectural decisions to a stateless tool, and losing the compound value of accumulated knowledge. Nova is my attempt to solve that. It's infrastructure, not a toy.</p><p>The next post on this will probably be about the self-improvement loop once there's something real to show. For now, the milestone worth marking is that the orchestration layer works, the agents are scoped properly, and the system is running in production against real tasks. That's further than I expected to be at this point, and I'm not going to pretend otherwise.</p>