The Full Stack: Why Agents Will Finally Force ERP and CX to Talk to Each Other

The conversation is about the full stack. Not the technology stack, not the "modern data stack" that dominated conference keynotes for a few years, but the actual end-to-end architecture of a business: from the backend systems that run operations — finance, human capital management, supply chain, procurement — to the frontend systems that face the customer — sales, service, commerce, marketing, loyalty.

Every CIO knows what this picture looks like inside their own organization. They see it when they map their vendor landscape onto a whiteboard and realize they've assembled nine or twelve or fifteen platforms across both sides, connected by a spaghetti of custom integrations and middleware that took years to build and that nobody fully understands.

But here's why the conversation never happens at an industry level: no vendor can credibly have it.

Snowflake can talk about the data layer but has no applications. Salesforce can talk about CX but has no ERP. The hyperscalers can talk about infrastructure but don't touch business semantics. Every vendor in the market can solve a portion of one side — and so every vendor has a powerful incentive to define "the stack" as whatever fragment they happen to sell.

The full picture is visible only from the CIO's chair, usually during a painful architecture review or a failed digital transformation, and by then it's a problem to be managed rather than a conversation to be had.

Agents are about to force that conversation into the open, whether the vendors are ready for it or not.

The Frankenstack in the Mirror

Every CIO has their own version of this diagram, and none of them are proud of it. The marketecture slide they show the board has clean lines and integrated layers; the reality underneath is a Frankenstack assembled over decades through a combination of best-of-breed purchasing decisions, strategic vendor bets that didn't pan out, and acquisitions that brought their own systems along for the ride.

For three decades, enterprise technology has been organized around functional domains, each with its own data model, its own governance structure, its own vendor relationships, and — critically — its own definition of what constitutes a "customer." The finance team's understanding of a customer is a billing entity with payment terms and credit limits. Marketing's understanding of a customer is a behavioral profile with propensity scores and channel preferences. These aren't just different views of the same entity — they are, in many organizations, literally different records in different systems maintained by different teams who report to different executives and measure success against different KPIs.

ERP vendors built deep, transactional systems optimized for accuracy and compliance. CX vendors built broad, engagement-oriented systems optimized for reach and personalization. The data architectures reflected the priorities: ERP data is structured, validated, and authoritative; CX data is high-volume, probabilistic, and designed for speed. Anyone who has tried to reconcile a CDP profile with an ERP master data record understands the fundamental impedance mismatch — it's not just a plumbing problem, it's a philosophical one.

And for most of the last thirty years, this two-stack reality was tolerable. Not great, but tolerable. The backend and the frontend operated on different time horizons, served different stakeholders, and rarely needed to exchange information in real time. When they did — say, when a customer service agent needed to check on an order's shipping status — some middleware or a manual lookup bridged the gap well enough.

Agents are about to blow that up.

The Spring Campaign Problem

Here's a scenario that will be common within eighteen months, and that most enterprises are completely unprepared for.

So it keeps optimizing, keeps spending, keeps driving demand for a product that cannot be fulfilled.

By the time a human catches the disconnect — maybe at a Monday morning cross-functional standup, maybe in a Slack thread, maybe not until the customer complaints start rolling in — the brand has spent a quarter-million dollars generating demand it can't satisfy and created a customer experience disaster in the process.

This is not a hypothetical edge case. This is the inevitable consequence of deploying intelligent agents on top of a fragmented data foundation.

The Architecture Challenge

The reflexive response to this scenario is "just integrate the systems" — throw some APIs at it, build a data pipeline between the supply chain platform and the marketing platform, add an alert. And sure, point-to-point integrations can patch individual gaps. But the agentic future doesn't create one gap — it creates a combinatorial explosion of gaps, and most of the vendor landscape is structurally incapable of addressing it.

Think about what a truly autonomous agent needs to orchestrate even a moderately complex business process. A pricing agent needs margin data (finance), competitive positioning (marketing), inventory levels (supply chain), and customer segmentation (CRM) — simultaneously, in real time, with consistent semantics. A customer service agent handling a complaint about a late delivery needs order data (commerce), shipping status (supply chain), customer lifetime value (marketing), and credit policy (finance). Every cross-domain workflow that agents might automate represents another integration that doesn't exist yet, another semantic reconciliation that nobody has mapped, another governance question that nobody has answered.

And no single vendor in the market today can solve more than a sliver of this.

The data cloud vendors — Snowflake, Databricks — can unify the storage layer but have no opinion about business process. The CRM vendors can orchestrate customer-facing workflows but are blind to operations. Only the vendors with both ERP depth and CX breadth — with embedded customer data and a connected application suite — are positioned to deliver the full stack agents actually need.

The companies that try to stitch these fragments together on their own are going to end up with what I've been calling the "assembled" architecture — a Frankenstein of acquired and integrated systems bolted together with custom middleware, each component bringing its own data model and its own definition of truth. The integration tax alone — the cost of maintaining all those connectors, reconciling all those semantics, governing all those data flows — will consume a meaningful percentage of IT budgets before a single agent is deployed.

The Three-Layer Answer

What the agentic era actually demands is a fundamentally different architecture — not integration between stacks, but a single stack with three layers.

At the foundation, you need an Identity and Governance Layer that provides unified identity, access control, data governance, and compliance across the entire enterprise. This is where authority scoping lives — not just for human users, but for agents. Which agents can access which data? Who authorizes an agent to make a procurement decision versus a marketing decision? These questions become existential when agents operate autonomously across domain boundaries.

Above that sits the Intelligence Layer: a unified data fabric that spans the entire enterprise, with business semantics, knowledge graphs, analytics, and activation capabilities that work the same way whether you're looking at supply chain data or marketing data. This is where DMPs and CDPs ultimately dissolve — not because the use cases go away, but because the idea of a standalone "customer data platform" that only sees half the enterprise becomes an architectural anachronism. The data products that matter in an agentic world are the ones that span the full business context.

At the top sits the Agent Orchestration Layer — the tier where cross-domain intelligence, autonomous workflows, and continuous learning actually happen. This is what we've been calling the Agentic Management Platform, and its defining characteristic is that it sits above the domain applications, not within them. It can see across finance and marketing, across supply chain and commerce, across procurement and service — because it's operating on a unified data foundation, not trying to query through a maze of point-to-point integrations.

From Domain Logic to Lightweight Applications

Here's the part that should make every enterprise software executive uncomfortable: in this architecture, the domain applications themselves — the finance module, the marketing suite, the supply chain system — become thinner. Not less important, but less architecturally central. They become the interfaces through which specific business functions interact with the underlying intelligence layer, rather than the thick, monolithic systems that own their own data and defend their own boundaries.

This is a profound shift. For decades, the value of enterprise software has been in the depth and specificity of domain logic — the thousands of business rules embedded in an ERP system, the sophisticated audience modeling in a marketing platform. That domain expertise doesn't go away, but it moves. It migrates from being embedded in application logic to being expressed as data semantics and agent instructions that the orchestration layer can reason about and act on.

The enterprise that figures this out — that builds or adopts a truly unified data foundation spanning both sides of the house, with an orchestration layer that can deploy agents across domain boundaries — will have an almost unfair advantage. Their agents won't hit walls between the backend and the frontend. Their marketing agent will know what's in the warehouse. Their supply chain agent will know what's in the campaign. And when the spring campaign needs to pivot because of a supplier delay in Vietnam, the pivot will happen in minutes, not weeks.

The Full Stack Imperative

A DMP knew your audience. A CDP knew your customer. An AMP — an Agentic Management Platform — knows your business. The whole business, not just the half of it that faces the customer or the half that runs the operations.

That's the full stack. Not a technology stack — a business stack.

And the uncomfortable truth is that no vendor on the market today is going to hand it to you. The CIO who waits for a single vendor to credibly solve both sides of the house will be waiting a long time; the CIO who starts architecting toward a unified data foundation now — even imperfectly, even incrementally — will be the one whose agents actually work when they need them to.

This is the conversation the industry isn't having. It's time to start.