Consolidating Duplicate AI Capabilities

Q: What does it mean to consolidate duplicate AI capabilities?

Consolidating duplicate AI capabilities means turning several near-identical implementations of the same capability — five retrieval stacks, three vector databases, a dozen hand-rolled wrappers around the model API — into one shared enterprise service that all the teams consume, and then decommissioning the copies. The detection half is easy: any competent architecture review finds the duplication. The consolidation half is hard, and it is organisational rather than technical. You choose the strongest existing implementation as the reference service, give every other team a real migration path off its copy, move traffic incrementally rather than in a big-bang cutover, run the surviving service as a product with an owner and an SLA, and turn off each deprecated copy once its traffic is genuinely zero. Done well, the estate genuinely shrinks: one owned, reliable service replaces five maintenance burdens, and the marginal cost of the capability for the next team drops to an integration. Done badly, it produces the worst outcome of all — a single service everyone depends on and nobody maintains, which concentrates the risk that was previously spread across five owned copies. The distinction between those two outcomes is almost entirely about the unglamorous parts: running the survivor as a product, and actually decommissioning what it replaced.

Q: Why is consolidating duplication harder than detecting it?

Because detection is a technical problem and consolidation is an organisational one. Finding that four teams built four retrieval stacks takes an afternoon of architecture review; convincing those four teams to give up the versions they built and depend on someone else's service is a different kind of problem entirely. The duplication is rarely the result of carelessness — each team built its own capability because, at the time, that was the fastest way to ship — so asking them to abandon it is asking them to trade a thing they control for a dependency they do not, and "the architecture team says so" is not a reason that survives a delivery deadline. Consolidation driven by authority alone produces malicious compliance: the team adopts the shared service on paper and quietly keeps running its own, which leaves you with more systems, not fewer. The move works only when the shared service is a genuinely better deal for the consuming team — more reliable, better documented, cheaper to adopt than the cost of maintaining a private copy — so that teams migrate because it is in their interest rather than because they were told to. That is why consolidation is fundamentally about making the shared service better to consume than to rebuild, and about providing a real migration path, not about issuing a mandate. The governance function can make consolidation a priority, but it cannot make a bad shared service worth adopting.

Q: Which AI capabilities are worth consolidating and which are not?

Consolidate the capabilities that are horizontal, stable, and expensive to duplicate; leave the rest diverse. Horizontal means most of the estate needs it rather than a single team — a model gateway or vector storage is universal, a bespoke fraud-scoring chain is not. Stable means the approach is settled enough that standardising it will not freeze useful innovation — vector storage and evaluation are stable, a novel agent pattern under active research is not. Expensive to duplicate means each copy carries real maintenance, security, or licensing cost — a capability where every copy costs tens of thousands a year in licences and on-call is bleeding money several times over. When all three properties hold, consolidation pays and the classic candidates are the AI gateway and model access, vector storage, the evaluation harness, and guardrails or PII handling. When they do not hold, consolidation is actively harmful: forcing a fast-moving, domain-specific, or experimental capability into a single shared service freezes it at today's understanding, removes the diversity teams genuinely need, and turns the platform into a brake rather than an accelerator. The discipline is to consolidate the horizontal-stable-expensive capabilities and to govern the decision to keep others diverse, rather than treating standardisation as a virtue in itself. Standardising the wrong thing is as damaging as leaving duplication unaddressed.

Q: How do you migrate teams off their own copies without a mandate?

By making the shared service the better deal and running the migration as an incremental strangler-fig rather than a decree. First choose the reference implementation on evidence, not politics: the copy with the best reliability, the cleanest interface, and the most headroom becomes the shared service, and the team that built it often seeds the owning team. Picking by org-chart seniority instead of technical merit produces a shared service worse than the copies it replaces, and everyone can tell. Then stand that reference up as an actual product — with an owner, an SLA, and documentation — before asking anyone to migrate, because a shared service that is not yet a product is not ready to consolidate onto. Then migrate each consuming team incrementally: they place a facade in front of the capability, shift a slice of traffic to the shared service, validate that behaviour matches, and shift more, so no team faces a risky all-at-once rewrite and any problem is caught at low volume. Finally, decommission each deprecated copy only when its traffic is genuinely zero, and make turning it off a tracked deliverable with an owner rather than a someday-cleanup. This is the strangler-fig pattern applied to platform consolidation, and it works because at every step the consuming team is choosing the shared service on its merits rather than being ordered onto it.

Q: Why must a consolidated capability be run as a product?

Because when you consolidate five teams' copies into one service, you also consolidate five teams' risk into one place, and only the product discipline prevents that concentrated risk from becoming a shared liability. A consolidated service with an owner, an SLA, documentation, and a roadmap is a genuine platform capability; the same service with none of those is the single worst outcome of consolidation — a point of failure that everyone's production depends on and nobody maintains, which fails at 2am with no one on call because "everyone owns it" means no one does. Running it as a product means the boring, essential things: a named owning team accountable for it, a published SLA and support model, documentation good enough that a new team can self-serve, a roadmap that responds to consumer needs, and usage treated as the success metric. It also means accepting that the service is never finished — it evolves with the estate, and the day teams start quietly rebuilding their own again is the day the product is telling you it stopped being the easiest path. The product framing is exactly what separates a real internal platform from an accidental one; consolidation that merges implementations without establishing ownership has not built a platform capability, it has built a shared liability, and it would often have been safer to leave the five owned copies in place.

Q: What is the strangler-fig approach to consolidation?

The strangler-fig approach migrates teams onto a shared service incrementally, growing the new service's share of traffic while shrinking the old copy's, until the old copy handles nothing and can be removed — named after the fig that grows around a host tree until it can stand on its own. Applied to capability consolidation, each consuming team places a facade in front of the capability so callers do not need to know which implementation serves a request; behind that facade the team shifts a slice of traffic from its private copy to the shared service, validates that the shared service produces equivalent results (parity), and then shifts a larger slice, repeating until all traffic flows to the shared service. Only then is the private copy decommissioned. The value of this approach is risk reduction: no team faces a big-bang cutover where a single failure takes down its production, problems surface at low traffic volumes where they are cheap to diagnose and reverse, and each team migrates on a schedule that fits its own delivery rather than on a synchronised enterprise deadline that is guaranteed to slip. The alternative — migrating everyone at once — maximises risk and stalls at the first failure, which is why consolidation programmes that attempt it tend to freeze halfway with some teams migrated, some not, and the duplication now worse because a shared service sits alongside all the copies it failed to replace.

Q: What is the biggest anti-pattern in capability consolidation?

The unowned consolidated service — merging five copies of a capability into one shared service that has no owner, no SLA, no documentation, and no roadmap. This is worse than the duplication you started with, because consolidation concentrates risk: five mediocre-but-owned copies each fail in isolation and each has a team that knows how to fix them, whereas one unowned shared service that everyone depends on fails globally, at the worst time, with nobody accountable for recovery. "Everyone owns it" reliably means no one does. The fix is to establish the product discipline — a named owning team, an SLA, documentation, a roadmap — before the consolidation, not after, and to treat standing the reference up as a product as a precondition for asking anyone to migrate onto it. The closely related anti-patterns are consolidation by mandate (which gets malicious compliance without a better-to-consume service and a migration path), picking the reference implementation by politics rather than technical merit (which produces a shared service worse than what it replaced), big-bang cutover (which maximises risk and stalls), never decommissioning the old copies (which means you added a system instead of removing one), and consolidating a capability that should stay diverse (which freezes useful innovation). All of them share a root cause: treating consolidation as a technical merge rather than as the organisational work of building and running a product that teams choose to depend on.

Q: How do you know if a consolidation succeeded?

A consolidation succeeded when the estate genuinely has fewer systems than it started with, the surviving service is run as a product that teams choose to consume, and the deprecated copies are actually turned off. Each of those is a distinct check, and skipping any one of them turns an apparent success into a hidden failure. Fewer systems: if the shared service now sits alongside the copies it was meant to replace because none of them were decommissioned, the consolidation added a system rather than removing one, and the maintenance burden went up, not down. Run as a product: if the survivor has no owner, SLA, or roadmap, you have created a shared single point of failure, and the fact that it currently works is luck, not success. Teams choose to consume it: if teams adopted it on paper under mandate but quietly kept or rebuilt their own, the duplication persists underneath a compliance veneer, and the tell is teams starting to build their own again — which is the platform signalling it stopped being the easiest path. The durable success metric is therefore usage freely chosen plus a shrinking count of live implementations plus a healthy owning team, not the one-time event of a migration being declared complete. Consolidation is not a project that finishes at cutover; it is the ongoing state of a well-run platform capability that remains the path of least resistance.