Most "AI for [industry]" pitches start with a rip-and-replace. New platform, new database, a migration project measured in quarters, and a change-management fight with the people who actually run the counter. For the sectors we work in — builders merchants, energy suppliers, SME operations — that pitch is dead on arrival. The systems are load-bearing. The ERP is the business. Nobody is ripping out a Kerridge or Epicor BisTrack install that thirty years of stock, pricing and trade accounts live inside because a startup showed up with a chatbot.
So we build the other way round. The agent sits on top of the system the business already runs, reads and writes through whatever interface that system exposes, and does the operational work — quoting, order-taking, billing checks, customer replies — without asking anyone to move house. This post is about why that architecture is the right default for vertical AI, and the three constraints that shape it.
The system of record doesn't move
The first design decision is the one everyone skips: the ERP stays the source of truth. The agent is not a new system of record; it's an actor that operates the existing one. That single choice cascades into everything else. It means no data migration, no dual-write reconciliation nightmare, and no "which number is right" support ticket at month end. It also means the hard part of the job is integration, not modelling — and that's the correct place for the hard part to be, because integration is a solvable engineering problem while re-teaching an industry to use new software is not.
Concretely, for a builders merchant, that means the agent reads live products, prices and stock straight out of the ERP, builds a priced quote against real availability, and writes a genuine order back — including at 9pm when the branch is shut and the customer is planning tomorrow's job. The merchant didn't change a thing about how they run. They just started capturing the orders they were losing after close.
Agents need boundaries, not autonomy
The second constraint is that operational work is unforgiving of confident nonsense. An agent that occasionally invents a price is worse than no agent. So the interesting engineering isn't the model — it's the rails around it: every action the agent can take is a defined, validated operation against the real system, not free-text that hopes to be right. Quote generation pulls from live pricing rules. Stock checks hit the real availability. An order write goes through the same validation a human order would. The language model decides intent — what the customer wants — and the deterministic layer decides whether that's a legal move in the business.
If you're building in this space, resist the urge to let the model touch the system of record directly. Give it a narrow, typed set of operations and make every one of them safe to call. Your future on-call self will thank you.
Vertical beats horizontal because the edges are the product
The third thing: the value is in the domain edges, not the general capability. A horizontal assistant can hold a conversation about anything and complete none of the work, because completing the work means knowing that this merchant prices timber by the metre, honours a trade discount tier, and can't sell below cost without a manager override. That knowledge isn't a prompt — it's the integration and the rules. It's unglamorous and it's exactly why a vertical agent that does one industry properly is worth more than a general one that does everyone's badly.
This is also why we're not worried about being a thin wrapper. The wrapper is the easy 10%. The 90% is the part that reads a specific ERP's stock model correctly and writes an order that the branch actually recognises the next morning.
What this looks like in practice
The pattern generalises well beyond merchants. Energy suppliers have regulatory and billing systems that are equally immovable; the agent handles switching and compliance tasks on top of them. SMEs have a CRM and a phone that never stops; the agent answers, checks availability and books, writing back into the tools they already have. Same architecture every time: don't replace the system, operate it. We ended up building a small family of these agents around that one principle — the details are on the OptiFlow Technologies site if you want to see how it plays out per sector — but the principle is the portable part, and it's the thing I'd push any team building vertical AI to adopt.
The takeaway for builders
If you're putting AI into an industry that runs on entrenched software:
- Treat the incumbent system as the system of record. Don't migrate; operate.
- Make integration the hard problem, because it's the solvable one.
- Give the model intent, give the deterministic layer authority. Never let the LLM write to the source of truth unchecked.
- Compete on domain edges, not general capability. The edges are the moat.
Rip-and-replace loses to sit-on-top in any market where the existing system is load-bearing — which is most of the markets that actually keep an economy running. Build for that reality and the adoption problem mostly solves itself, because you're not asking anyone to change what already works.
Chris Fagan is the founder of OptiFlow Technologies, which builds agentic AI for builders merchants, energy suppliers and UK SMEs.
Top comments (0)