Platform fragmentation used to cost an enterprise reporting effort. The same customer appeared in four systems, finance reconciled at quarter end, and analysts rebuilt the picture by hand. It was expensive and slow, and it worked, because a human filled the gaps between systems.
Agents cannot do that. An agent acts on what it reads, and what it reads is whatever the fragmented estate presents. Where a human analyst notices that two records describe the same customer, an agent treats them as two customers and acts twice.
McKinsey’s April 2026 research on scaling agentic AI quantifies the consequence. Nearly two-thirds of enterprises have experimented with agents, and fewer than 10% have scaled them to deliver tangible value. Eight in ten cite data limitations as the roadblock. McKinsey’s assessment is direct: companies have often muscled through fragmented and siloed data, and those issues are impossible to manage at scale.
What Agents Need That Dashboards Never Did
A dashboard needs data to arrive. An agent needs to understand what the data means before it acts on it.
That difference is the whole argument. A reporting layer can reconcile four customer records into one number and present it to someone who knows the business well enough to sanity-check the result. An agent given the same four records has no external reference. It will resolve the ambiguity itself, consistently, and at volume.
McKinsey describes the missing piece as a semantic layer: a machine-readable definition of what business entities are, how they relate, and what rules govern them, implemented through ontologies and knowledge graphs. Without that shared foundation, agents act on incomplete or conflicting interpretations of the same data, and error rates and operational risk rise as scale grows. McKinsey also draws the distinction between single-agent workflows, where fragmentation produces inconsistent decisions, and multi-agent workflows, where it produces lost coordination and propagated errors.
Why This Is a Context Problem, Not an Integration Problem
Most enterprises already have enterprise platform integration. Middleware moves records between systems on a schedule, APIs expose data on request, and an integration team maintains the map. What integration does not supply is meaning.
Two systems can be perfectly integrated and still disagree about what a customer is. One counts a legal entity, the other counts a billing relationship, and the field that reconciles them was repurposed in 2019 for a reason nobody documented. Integration moves that ambiguity around faster. It does not resolve it.
This is why ISG’s 2026 platforms research frames consolidation as something other than a cost exercise. ISG finds enterprises turning to platforms with standards-based connectivity, unified governance, and lifecycle management as they consolidate software stacks and formalize API- and event-driven architectures. Jeff Orr, ISG’s director of research for IT and technologies, puts it plainly: “Platform consolidation is no longer an efficiency play. It is now a structural necessity. Enterprises are replacing fragmented toolchains with platforms that combine AI-assisted execution with strong governance.”
ISG adds a condition worth noting. Organizations with mature integration practices and standards-based interoperability strategies are the ones best prepared to adopt unified, AI-enabled platforms, and ISG recommends applying AI with clear guardrails, including responsible use policies and human-in-the-loop oversight, so automation improves throughput and quality without compromising compliance or safety.
What to Consolidate When Replacement Is Not an Option
Very few enterprises can retire platforms at the pace agent programs are moving. Consolidation in practice means reducing ambiguity rather than reducing systems, and four things carry most of the weight.
- Entity definitions. Customer, account, product, claim, order. Defined once, in machine-readable form, with the mapping to each system’s local representation held centrally rather than in integration code.
- Systems of authority. For each entity and each attribute, which platform is authoritative. Not which platform holds the most records, which one an agent should believe when they disagree.
- Capability exposure. Agents need to invoke actions, as well as read records. A consolidated capability catalog describes what each platform can do, in a form an agent can query before acting.
- Access policy. Defined at the data layer rather than reimplemented per agent. McKinsey’s guidance is explicit that agents should follow the same standards as other systems, applied automatically as autonomy increases.
None of that requires retiring a platform. All of it reduces the ambiguity an agent has to resolve on its own.
How Ascendion Consolidates for Agent Readiness
Ascendion is an AI-native software engineering services company that built AAVA™, its agentic AI platform for enterprise software engineering, and runs it at enterprise scale inside client environments under the Engineering to the Power of AI™ method. AAVA is model agnostic and supports Model Context Protocol, Agent-to-Agent, and Agent Communication Protocol standards, which is what lets agents discover and invoke capability across systems rather than inside one.
The consolidation work itself sits across two service lines. Enterprise platform services own the platform estate and its lifecycle, and enterprise application services carry the connective work between systems. AI and data engineering services build the layer underneath: discovery, ingestion, observation, and validation, with governance, privacy, compliance, and security embedded across stages rather than added afterwards.
The fragmentation pattern is consistent across engagements. One client had five separate vendors independently managing different technology towers across its data operations, producing operational silos, inconsistent standards, and a growing backlog of unresolved incidents. Ascendion implemented a centralized governance model unifying management across all five towers and more than 25 critical applications, with automation replacing the manual intervention that had dominated routine work.
A global multi-brand information provider showed the same problem from the commercial side. Individual brands had adopted their own platforms over time, creating silos across sales, customer service, marketing, and finance. Reporting required extensive manual effort and reverse engineering, pricing was inconsistent across regions, and customer service was managed through Outlook. Ascendion consolidated onto Salesforce Sales Cloud, CPQ, and Service Cloud with marketing data integrated alongside, producing standardized pricing across regions and a single view of customers, revenue, and engagement.
Neither client had a data problem in the conventional sense. Both had plenty of data. What they lacked was one definition of the entities that data described, which is precisely the condition that leaves an agent unable to act reliably.
How to Sequence Consolidation
- Pick the entity that appears in the most agent use cases. Usually customer or account. Define it once, in machine-readable form, before defining anything else.
- Name the system of authority for each attribute. Document what an agent should believe when platforms disagree, because they will.
- Publish a capability catalog. Agents need to know what they can invoke, not only what they can read.
- Move access policy to the data layer. Rules defined once and inherited, rather than reimplemented in each agent and left to drift.
Consolidation has been sold as an efficiency program for two decades, which is why it keeps losing to more urgent work. What changed is the consequence. A human analyst who meets two records for the same customer reconciles them. An agent acts twice. Talk to Ascendion about enterprise platform services and enterprise platform modernization that makes agents workable.
What changes when agents act inside the system of record is covered in our article, Enterprise Platform Services Reimagined.