Why I'm Building One AI System Instead of Five

<p>I have a handful of active projects right now — AIREP, Find a Sign, Sweeper Parts, and Nova itself. They're different domains: ERP for trades businesses, a signage marketplace, a parts catalogue for municipal sweeper equipment. On paper they don't have much in common. But I keep resisting the urge to bolt a separate 'AI feature' onto each one individually, and I think it's worth explaining why.</p><p>The easy path is obvious: AIREP gets a chatbot for querying job data, Find a Sign gets a recommendation widget, Sweeper Parts gets a search assistant. Three separate integrations, three separate prompt libraries, three sets of API keys and logging and failure modes to maintain. That's the default shape most consultants end up with, because clients ask for 'AI in the product' and the fastest way to deliver is to wire something in locally.</p><p>I've deliberately not done that. Instead, Nova is the single backend AI service, and each product talks to it as a client. AIREP doesn't have its own AI logic — it calls into Nova's ERP specialist agents. Find a Sign doesn't have a bespoke recommendation model — it queries Nova. This isn't just architectural tidiness for its own sake, though it does happen to be tidier. It's about where the leverage actually compounds.</p><p>If every product has its own AI stack, every improvement is local. I get better at prompting for AIREP, but that knowledge doesn't automatically help Find a Sign. If instead there's one system — currently sitting at 34 agents across general chat, pipeline execution, ERP specialists, language tasks — then a better retrieval strategy, a more reliable agent handoff pattern, a fix to a hallucination problem, all of it propagates across every product that uses Nova. The system gets smarter once, and every client benefits every time.</p><p>There's a cost to this. Building a general system is slower up front than duct-taping a chatbot onto one product. It's tempting, especially under client deadlines, to just ship the local version. I've had to say no to that shortcut more than once this year, because I know the local version would work fine for six months and then become its own maintenance burden the moment I wanted to add the same capability somewhere else.</p><p>The other thing this forces is discipline about what actually counts as 'AI as a differentiator' versus what's just automation dressed up. It's easy to slap a model on a form field and call it AI-powered. What I actually want — and what I think clients eventually notice — is a system that does something a static ERP or marketplace can't: understand branch-scoped data across a multi-tenant AIREP install without me writing bespoke logic per client, or help a signage buyer find the right supplier without any of it being pay-to-rank manipulation. That only works if the underlying reasoning is genuinely capable, not a thin wrapper.</p><p>I'm currently in the orchestration phase with Nova — moving from 'a pile of useful agents' to something that runs coordinated work across projects without me manually stitching each request together. That's directly downstream of this same principle: one system, used everywhere, getting better as a whole rather than in isolated pockets.</p><p>It's slower to build this way. I'm fine with that. The compounding version is worth more in eighteen months than five faster, disconnected versions would be. And honestly, it's a more interesting problem to work on — the constraint of making one system serve genuinely different domains is where most of the actual engineering is.</p>