Nova Is in Production: What 34 Agents Actually Means

<p>Nova is in production. Not "production" in the sense that I've demoed it to someone and called it done — production in the sense that it's now the backend AI service running behind my personal site, handling real orchestration across real projects. That's a line worth drawing clearly, because the gap between "I have an AI thing working" and "it's actually running my workflows" is wider than most people expect.</p><p>The number people notice is 34 agents. I get why that sounds like a flex, but the honest version is more interesting than the impressive-sounding version. 34 agents doesn't mean 34 autonomous robots doing things while I sleep. It means 34 discrete, scoped units of responsibility — each one narrow enough to be reliable, each one composable with the others. That design decision was deliberate. A single monolithic AI assistant that tries to do everything is brittle. When it fails, you don't know why. When you want to improve it, you don't know where to start. Splitting by responsibility gives you handles.</p><p>The agent categories reflect the actual shape of my work. There are general chat agents — the conversational layer, the thing that feels like talking to a system. There are pipeline execution agents, which are less glamorous but more important: they're the ones that actually do things in sequence, hand off results, and recover from partial failures. Then there are ERP specialists scoped to AIREP — agents that understand branch-scoped data models, Django ORM patterns, multi-tenant concerns. And there are language task agents, which handle the writing, summarising, and structuring work that would otherwise eat hours of my week.</p><p>What "production orchestration phase" actually means is that these agents are now coordinating with each other rather than operating in isolation. A request comes in, a routing layer decides which agent or sequence of agents handles it, results get passed between them, and the output lands somewhere useful. That coordination layer is where most of the hard work lives — not in any individual agent, but in the contracts between them.</p><p>Building this yourself teaches you things you won't learn from using someone else's AI product. You learn that context management is the real problem — not capability, not model quality, but keeping the right information in scope at the right moment without bloating every call. You learn that agents fail in boring ways: wrong format, stale context, misrouted intent. The interesting failures are rare. The boring ones are constant, and handling them is 80% of the engineering work.</p><p>I've been thinking about Nova less as a product and more as a compound advantage. Every hour I put into it makes every subsequent hour of work across AIREP, Find a Sign, client projects, and this site incrementally faster and more informed. That's the actual value proposition — not any single capability, but the accumulation. An AI system that knows my codebase, my architecture decisions, my client contexts, and my preferences is categorically different from a general-purpose assistant, even a very good one.</p><p>The next phase is the part I'm most interested in: building the self-improvement loop. Agents that can review Nova's own code, flag patterns that are drifting from the original design, and suggest refactors. That's not science fiction — it's a well-scoped engineering problem. The hard part isn't the AI; it's defining what "improvement" means precisely enough that an agent can evaluate it. That definition work is the part I'm doing now.</p><p>If you're building something similar — a personal AI system, an agent layer on top of your own tools — the advice I'd give is this: start with the boring infrastructure. Routing, logging, context passing, failure handling. The agents themselves are the easy part. The plumbing is what determines whether the whole thing actually runs when you need it to.</p>