AI Tool Consolidation vs. Best-of-Breed Stack Decisions in Operations

The Futurum Group's Enterprise Software Decision Maker Survey Report, covering 830 global IT decision-makers, found the best-of-breed procurement philosophy falling to 20.7%, while the "mostly platform" model surged from 60.0% to 65.9%. That is a genuine structural shift in how companies buy software, not a passing preference. But the question driving most operations leaders toward one side or the other asks the wrong thing first: how many vendors should run this department? The number of vendors is not what determines whether a process works. Whether the process is worth running at all is what determines it, and that question gets skipped almost every time.

The SOC world shows why vendor count and process coherence are separate variables. A security team can consolidate down to three vendors and still run three silos, if none of those systems share an investigation timeline. The same team can run fifteen best-of-breed tools and investigate every incident coherently, if the data from all fifteen resolves into one case. Consolidation did not create that coherence, and fragmentation did not destroy it. Something else did: whether the process connecting those tools was designed to produce one usable account of what happened.

Operations leaders in construction, logistics, manufacturing, and retail are inheriting a debate built for IT procurement and marketing stacks, where the downside of a broken process is slower content production or a longer breach dwell time. In asset-heavy operations the downside looks different: a missed energization date, a stranded capital project, a shipment that never gets rerouted in time. The stakes are not comparable, and neither is the right first question. Whether the process the tool runs is structurally sound to begin with matters more than which tool wins a benchmark.

How the integration tax became the proxy argument for a deeper problem

The case for consolidation rests on a real cost. Each additional tool in a stack requires its own API connections, its own data pipelines, its own training, its own monitoring. Asset-heavy industries, running on tight margins and tighter schedules, cannot afford to burn capacity this way.

Consolidating the login screen does not consolidate the evidence behind it. A single platform sitting on top of processes that were never coherent to start with does not produce coherence. The integration tax is a real cost of fragmentation, but it is a symptom of a deeper condition, not the condition itself. Treating the symptom by buying a platform does not cure what is producing it.

The record on enterprise AI adoption backs this up. The well-documented gap between successful pilots and systems that actually reach production in manufacturing and logistics is an execution problem: the process the AI system runs against was never ready for production in the first place, whatever software sits on top of it.

Best-of-breed stacks carry their own legitimate argument, and it deserves to be stated rather than dismissed. A layered stack, built from a horizontal context layer, one or two reasoning tools, copilots native to whatever suite a company already runs, and domain-specific agents for the handful of workflows that justify the investment, can outperform a single-vendor platform when each layer is chosen for fit with how the company actually operates. The right question is never platform versus point solution in the abstract, but whether a given piece of the stack fits the process it needs to serve.

A fair objection follows naturally from the data-infrastructure argument for consolidation: doesn't a machine learning model need a unified data model to work well, which means unification has to come first? Data architecture and process design have to happen in sequence, not in parallel. Fixing the pipes before checking whether the plan the pipes feed is sound gets the order backward.

What AI agents expose about process quality

AI agents do not make an efficient process more efficient and leave an inefficient one alone. They amplify whatever structure is already there, for better or worse. A broken process running under an agent breaks faster, at higher volume, and with far less human visibility into what went wrong than the same broken process run by hand.

The reason comes down to compensation. A human worker can notice a missing handoff or an ambiguous decision point and patch around it with judgment built from years on the job. An agent traversing the same data systems autonomously has no such reserve. It needs the process to already specify what happens next, and if that specification does not exist, the agent either stalls or proceeds on a guess it presents as a conclusion.

Field operations raise the stakes further because the permission structure around an agent has to track the actual risk of the decision it is making. Graduated autonomy, in other words, has to mirror graduated risk. That kind of design discipline barely exists in marketing or IT deployments, where a wrong output gets caught and corrected with minimal consequence.

Construction supplies the clearest cautionary case. An agent optimizing a schedule that cannot see grid availability automates a process that was already broken and hands back a confident answer at the exact point where reality diverges from the plan.

Security operations show the same pattern from a different angle. AI SOC agents are at the peak of inflated expectations industry-wide, yet penetration of their own target market still runs at just one to five percent. That gap is a process-readiness shortfall: many vendors bundle an agentic layer on top of data that was never consolidated into one coherent case file, and call the result a platform.

Logistics offers the contrasting case, the standard rather than the warning. The condition of the process it was asked to run, not the sophistication of the agent, is what separates that result from the energization failure.

When AI agents run on broken processes at field scale, they fail at higher volume and with less visibility for anyone to catch the failure in time. That is the argument for conducting a full process audit and redesign before deployment rather than trying to patch an existing workflow afterward: agents expose process debt immediately and visibly, in a way quieter manual workarounds never did.

Why the process audit must come before the stack decision, not after it

Find the process that causes the most pain, audit where it genuinely breaks, decide honestly whether it deserves to keep running in its current form, and only then choose the tooling. Operations leaders who start with tooling have inverted a sequence that does not forgive inversion.

Automating a broken process makes it worse, faster, and is the mechanism behind most AI pilot failures across manufacturing and logistics, where the schedule a company declares and the work actually happening in the field diverge because nobody audited the schedule's underlying assumptions for whether they could be achieved.

Planning tools such as P6 capture intent, not achievability. A stack decision made before those inputs surface is a decision made against a process that exists only on paper.

The process was auditable before anyone picked a tool to run it.

The right audit question is where the process actually breaks when it breaks, and whether that break is visible in data the company already holds, not how many vendors a department has. Public records and field evidence about a project's actual progress reveal more about operational risk than any declared schedule ever will.

Retail supplies a second case where process clarity came first and tool choice followed. Morrisons runs 400 to 600 AI cameras per store watching for empty shelves and automatically triggering replenishment tasks. It works because the failure mode, an empty shelf, is unambiguous, the signal from the camera is direct, and the resulting action is bounded to a specific task. The process was defined before anyone chose a camera vendor.

Doesn't a team need to start somewhere, and doesn't a platform give it a foundation to audit from? A platform chosen before the audit locks in architectural assumptions that may not match where the process actually fails. The audit is what reveals which data genuinely needs to be unified, and that finding should drive the platform choice, not the other way around. Terminal Use, an AI-first operations rebuilder working across construction, logistics, manufacturing, and retail, starts every engagement with exactly this kind of audit, asking whether the workflow is worth running at all before any stack decision gets made. The sequencing follows from the same logic laid out above: tool consolidation and best-of-breed architecture only matter once the process they are meant to support is sound.

What "AI-first process design" means in practice for asset-heavy operations

Designing a process around AI from the start means beginning with what the process has to produce, a verifiable output, a bounded decision, an action that can be traced after the fact, and building the agent's workflow backward from that output. Starting from a tool's feature list and working forward gets the direction of design backward.

The difference between bolting AI onto an existing workflow and rebuilding the process around AI is whether the agent can operate on its own or needs a human correcting it at every step. That single fact decides whether the economics of running an agent in that role work out.

In construction, the right starting point is one specific, painful process, commissioning readiness, procurement matching, energization sequencing, not a platform strategy chosen in the abstract. The process definition is what sets the agent's permission scope, its escalation paths, and the data it needs to move through.

There is a useful diagnostic buried in timeline alone: if a redesigned process cannot go live in weeks, the process was defined too broadly or not defined carefully enough. Firms that rebuild a workflow end to end around AI agents from the outset, Terminal Use among them, report outcomes that look nothing like the results of layering agents onto operations that were already fragmented.

How to choose between consolidation and best-of-breed once the process is defined

With the process defined and audited, the original question narrows considerably. Whether this specific process needs a single unified data model to function, or needs a depth of specialized capability that no general platform currently offers, is what actually matters now, not vendor count.

Consolidation makes sense when a process spans several functions and an agent needs to move across all of that data on its own, without a person mediating every handoff. It makes sense when governance or audit rules require one system of record and no exceptions.

Best-of-breed makes sense when the workflow is narrow, deep, and verifiable against hard records, procurement matching in construction being the clearest example. It makes sense when the process can state what context each agent needs, and interoperability standards can deliver that context without forcing everything onto one platform.

A layered stack, a horizontal context layer, a reasoning tool or two, copilots native to the suite a company already runs, and domain-specific agents reserved for the highest-value workflows, is a legitimate architecture whenever the process design has already specified what each layer needs to do. It is not a compromise position; it is a deliberate one, when the fit criteria are clear going in.

Vendor lock-in risk runs in both directions, and pretending otherwise does the operations leader no favors. A unified platform creates dependency on one vendor's architecture and sunk costs in whatever fine-tuning went into it. A best-of-breed stack creates its own debt in the form of integration work and leverage for specialist vendors at renewal time. The process design should say in advance which of those two risks the operation can actually absorb, rather than discovering the answer during a contract negotiation.

Procurement and legal questions get skipped more often than they should. AI-generated outputs sitting inside a unified platform raise questions of intellectual property and data governance that differ by vendor and rarely get resolved before signing. In asset-heavy industries, where those outputs feed regulatory filings, contract claims, or safety decisions, data portability and output ownership need answers before deployment, not after a dispute.

The clearest sign that a stack decision is happening too early: nobody on the team can name the specific failure mode the new architecture is meant to fix, or name which process will be the first one live under it. When that is the state of the conversation, what looks like operational planning is a platform strategy wearing its clothes.

Where to start: the first process to redesign

The right first process to rebuild is the one causing visible, specific pain today, one with a concrete owner, a traceable failure mode, and data that already exists somewhere in the company even if nobody has connected it yet. Commissioning readiness, procurement matching, and energization sequencing all qualify in construction for the same reason Morrisons' shelf-monitoring system qualifies in retail: the failure mode is unambiguous, the signal is direct, and the action that follows is bounded enough for an agent to execute without guessing.

Bring a single process that hurts, show how it runs today and where exactly it breaks, and let that examination decide what gets rebuilt first and what tooling, consolidated or best-of-breed, actually fits the result.