What Running 34 AI Agents in Production Actually Looks Like

<p>Nova has been running in production for a while now, but the last phase shift felt different. It's not just a chatbot with memory anymore — it's a coordinated system of 34 specialised agents handling general conversation, pipeline execution, ERP domain queries, language tasks, and more. Calling it "an AI assistant" at this point is like calling PostgreSQL "a spreadsheet."</p><p>The honest version of how we got here: it started small. One agent, one purpose. Then a second for a different concern. Then the question becomes — do you keep bolting things onto a single agent, or do you decompose? I chose decomposition early, and I think that was the right call. Each agent has a narrow responsibility and a defined interface. The orchestration layer decides who gets the job. That separation keeps individual agents testable, replaceable, and easy to reason about when something goes wrong.</p><p>And things do go wrong. That's the part nobody talks about in AI agent content. In production, you deal with routing failures, context bleed between pipeline steps, agents that confidently return the wrong thing, and latency that compounds across a multi-step chain. None of that shows up in a demo. You only find it when real tasks are running through the system at real times of day.</p><p>The pipeline execution layer has been the most interesting to build. A pipeline in Nova is a structured sequence of agent calls — each step can consume the output of the last, branch conditionally, or fan out to parallel agents. Getting that right meant thinking carefully about data contracts between steps. If step three expects a structured object and step two returns something slightly off-schema, the whole thing degrades silently. I've put a lot of work into making failures loud and traceable rather than quiet and mysterious.</p><p>The ERP specialist agents are a good example of why specialisation pays off. AIREP — my Django-based ERP system — has a specific data model, specific business logic, and specific vocabulary. A general-purpose agent can answer questions about it, but it'll hallucinate field names, misunderstand branch-scoped data isolation, and get confused by multi-tenant edge cases. An agent that's been given the actual schema, the actual constraints, and domain context performs meaningfully better. The gap isn't subtle.</p><p>The next goal I'm working toward is a self-improvement loop — agents that can review, refactor, and improve Nova's own code. That's not as sci-fi as it sounds. It's mostly an engineering problem: give an agent the right tools (code access, test runners, diff review), a well-scoped task, and a feedback mechanism. The hard part isn't the AI capability — it's defining what "better" means in a way the agent can evaluate. That's a human judgment problem first, an AI execution problem second.</p><p>What I've learnt running this system is that multi-agent architecture rewards the same instincts as good software engineering in general: clear interfaces, single responsibilities, explicit failure modes, and observable behaviour. The AI layer is genuinely powerful, but it doesn't excuse you from the fundamentals. If your system design is fuzzy, your agents will be fuzzy. The model isn't going to save bad architecture.</p><p>The other thing worth saying: Nova is a personal system, but it's also a proof of concept for how I want to build AI into client-facing products like AIREP and Find a Sign. The patterns that work here — agent specialisation, pipeline orchestration, domain-grounded context — are the same patterns I'd apply at scale. Building it for myself first means I understand the failure modes before I'm building them for someone else's business. That's the point. AI as a compound advantage only works if you actually understand what you're compounding.</p>