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

<p>Nova is now in what I'm calling the production orchestration phase. That label means something specific to me: the system isn't a prototype anymore. It's running, it's doing real work across real projects, and it's the backend AI service visible through my portfolio site. Thirty-four agents. General chat, pipeline execution, ERP specialists, language tasks. That's not a demo — that's infrastructure.</p><p>I want to be honest about what "production" means at this scale, because there's a lot of inflated language around AI systems right now. For me it means: agents are being invoked as part of actual workflows, not just tested in isolation. It means the system has enough moving parts that failures are interesting rather than trivial. And it means the decisions I made six months ago about architecture are now load-bearing — for better or worse.</p><p>The thing that surprised me most about getting to this point isn't the technical complexity. It's the coordination problem. When you have one agent doing a task, you have a tool. When you have thirty-four agents with overlapping capabilities, different specialisations, and shared context, you have something closer to a team. And teams have the same problems teams always have: who owns what, how does information flow, and what happens when two agents are both technically capable of handling a request but optimised for different things?</p><p>I've been thinking about this less as an AI problem and more as an architecture problem. The patterns that work in distributed systems — clear ownership, explicit interfaces, observable state — turn out to matter just as much here. An agent that produces output no other agent can reliably interpret is a dead end, regardless of how good that output is in isolation. So a lot of recent work has been about making the system legible to itself: structured outputs, consistent context passing, pipeline stages that fail loudly rather than silently degrading.</p><p>The next problem I'm working toward is the self-improvement loop. The goal is agents that can autonomously review, refactor, and improve Nova's own code. That sounds ambitious — and it is — but it's also a natural extension of what the system already does. If Nova can write code for client projects, it can write code for itself. The hard part isn't the generation; it's the evaluation. How does a system decide whether a change is actually better? You need test coverage, you need benchmarks, and you need a feedback mechanism that isn't just "did it run without crashing."</p><p>I don't have that fully solved yet. But I have a clearer picture of the shape of the problem than I did three months ago, which is usually how progress works.</p><p>What I keep coming back to is this: AI isn't a feature I'm adding to my projects. It's the primary leverage point. That's a different framing than "I use AI tools to go faster," which is true but undersells it. The compounding effect is what matters. Every agent I build makes the next one cheaper to build. Every pipeline I instrument gives me data to improve the next pipeline. Nova isn't just helping me build AIREP and Find a Sign — it's getting better at helping me build things as a side effect of doing it.</p><p>That's the bet I'm making. Not that AI will replace the work, but that someone who builds their own AI infrastructure — and actually understands it from the ground up — will be able to move at a fundamentally different pace than someone using off-the-shelf tools. We're early enough that it's still possible to build that kind of advantage. Late enough that you have to start now.</p><p>Production is just the beginning of that.</p>