What the agentic CX platform wave is actually building

On June 10, 2026, Adobe made CX Enterprise Coworker generally available. Three months earlier, UJET had announced Agentic Experience Orchestration. NICE launched a product that builds ready-to-deploy agents from real interaction data. Salesforce, Zendesk, and Intercom each shipped significant agentic expansions in the same window.

That's a lot of enterprise software companies independently deciding, in the same six months, that CX needs an agentic layer.

The convergence matters. When three major platforms in the same space independently build the same four infrastructure components, they're not making the same creative bet. They're all arriving at the same engineering conclusion: a CX agent needs exactly these things to work, and it won't work well without any of them.

If you're building your own CX agents rather than buying from Adobe or UJET or NICE, this convergence is useful. It's the industry telling you, at significant expense and after years of experimentation, what has to exist in your stack.

What each platform actually built

Understanding the convergence means looking past the marketing language at the actual components.

Adobe CX Enterprise Coworker connects to Adobe's existing Customer Data Platform, journey analytics, and content generation tools. The GA announcement positioned it around "outcome realization," moving enterprises from AI experiments to measurable business results. The product gives agents access to a unified customer data layer and lets them take actions across Adobe's ecosystem.

UJET's Agentic Experience Orchestration takes a different architectural approach. AXO introduces what UJET calls a persistent AI layer, an orchestration framework that sits between customers and the enterprise systems behind them. Rather than giving agents direct access to each backend system, AXO routes contacts intelligently based on real-time context and abstracts system complexity away from the agent. The product is explicitly designed to let agents act across multiple systems without needing to understand how each one works.

NICE's approach is the most data-driven. Their system starts with actual interaction transcripts from your current contact center, identifies resolution patterns from your best human agents, and uses those patterns to define agentic behavior. The bet is that you don't need to design agent behavior from theory. You derive it from evidence of what already works in your specific operation.

All three platforms led with containment rate as their headline metric, all three emphasized actions over conversations, and all three had to build the same four infrastructure components to get there.

The four layers they all assembled

A unified data layer

The first thing every platform built was a way to give agents a coherent view of the customer. Not a name and a most-recent-order summary. The full picture: purchase history, previous support contacts, billing status, loyalty tier, open tickets, active return requests, shipping exceptions.

Adobe's unified data layer builds on their existing CDP. UJET's AXO constructs it through native system integrations. NICE mines it from historical transcripts. Different approaches, same component.

The data layer isn't glamorous. It's the plumbing. But it's also the thing that determines whether your agent can resolve issues or just answer questions. An agent that can only see the customer's email address and most recent order is a smarter FAQ bot. An agent that can see the customer's full context is a resolver.

For teams building their own CX agents, this means your first engineering decision is tool design, not prompt design. What data does the agent need to handle your most common resolution paths? Which systems hold that data? What's the interface (MCP server, OpenAPI schema, direct function call)? How does the agent authenticate against each system?

A practical starting point is to look at your existing support data. What do your human agents look up first when they open a ticket? What's the second thing? What information do they need before they can take action? Build those lookups as your first tools. Everything else can wait.

The capability ceiling for any CX agent is set by its data access, not its reasoning ability. A more powerful model with limited data access will always lose to a weaker model with full data access, because the weaker model can actually take action.

Chanl's tool management interface lets you define, test, and version this layer without rebuilding agent configuration each time a data source changes, which matters when your unified data layer spans five backend systems that each update on different cadences.

A persistent context layer

The unified data layer tells your agent about the customer's account. The persistent context layer tells it what happened in previous conversations.

These are different things. Account data lives in structured systems. Conversation context lives in transcripts, notes, and memory, and it evaporates when the session ends unless you explicitly preserve it.

UJET's AXO calls its implementation a "persistent AI layer" explicitly, because continuity across sessions is central to the value proposition. Adobe handles it through journey analytics that span channels and sessions. NICE extracts it from historical transcript mining.

The failure mode without persistence is visible to customers even when the agent is technically performing well. A customer who reported a shipment delay last week, was told to wait three more days, waited, and is now calling back to check: that customer should not have to re-explain the situation. The agent should know. When it doesn't, the customer experience degrades even if the agent scores well on conversation-level quality.

For DIY builders, persistent context usually means a few specific things in practice. After each resolved (or attempted) contact, you need to capture a structured summary: the issue type, what the agent did, what the outcome was, whether anything is still open. You need to store that summary somewhere retrievable. At the start of each new contact from the same customer, you surface the relevant summary as context.

The hard part isn't the storage; that's a simple database query. The hard part is deciding what's worth capturing. A full transcript is too noisy; a 50-word summary loses too much. The right abstraction is somewhere in between: the kind of handoff note a human agent would write before transferring a call. Issue, action, status, follow-up.

Agent memory systems are designed for exactly this: not long-term knowledge base retrieval, but episodic memory across customer contacts. The agent knows what it talked about with this customer before and what was resolved.

A tool orchestration layer

The third component every platform built is the ability to take action, not just provide information. Issue a refund. Update an address. Open a ticket. Schedule a callback. Cancel a subscription. Process an exchange.

This is the gap that separates conversational AI from agentic AI. A conversational system tells customers what to do. An agentic CX system does it.

Tool orchestration sounds simpler than it is. The reliability requirements at scale are different from what you'd assume. At 10,000 contacts a day, a 2 percent tool failure rate is 200 failed resolutions. Each one creates a customer who was told their problem was handled, discovers it wasn't, and calls back frustrated.

The platforms solved this with a few recurring patterns. Idempotent tool design (calling the same action twice produces the same result) prevents double-refunds and duplicate ticket creation when retry logic runs. Exponential backoff prevents cascading failures when a backend system is slow. Explicit confirmation steps for high-consequence, non-reversible actions give customers a chance to verify before the agent commits. Human escalation triggers fire when tool calls fail repeatedly rather than letting the agent continue pretending it can resolve something it can't.

Adobe's platform explicitly includes confirmation steps as a product feature for irreversible actions. UJET's AXO abstracts system integration into a unified orchestration layer so agents don't need to handle individual system failures.

For DIY builders, the design principle is to make your tools fail loudly in structured ways. Each tool should return a result that includes success or failure state, a message the agent can relay to the customer, and any data the agent needs to continue the resolution. The agent needs to know the difference between "the refund was issued, here's the confirmation number" and "the refund failed and will be automatically retried within the hour" and "the refund failed and a human needs to review." Those are three different situations that require three different agent responses, and a tool that just returns true or false forces the agent to guess which one it is.

See how MCP servers and OpenAPI tools handle failure gracefully for specific patterns around idempotency and structured error responses.

An outcome measurement layer

The fourth component, and the one most teams underinvest in when building from scratch, is measurement at the resolution level rather than the conversation level.

Conversation-level measurement asks: was the agent polite, on-topic, and accurate? These are useful quality checks. They don't tell you whether the customer's problem was solved.

Outcome-level measurement asks: did the issue get resolved? Did the customer call back within 48 hours with the same problem? Did the refund actually post? Did the customer's order ship after the address was updated? Was the subscription retained?

The enterprise platforms made outcome measurement central to their value proposition, not a reporting afterthought. NICE's system measures agent performance against the resolution patterns of high-performing human agents. UJET's AXO leads with containment rate as its primary ROI metric. Adobe's GA announcement explicitly positioned the product around "value realization," meaning demonstrable business results rather than AI capability.

There's a reason for the emphasis. The AI field spent several years optimizing conversation quality, and teams kept discovering that high-quality conversations with unresolved issues produced poor customer satisfaction. Containment rate, first-contact resolution, and callback rate within 48 hours turned out to be better predictors of customer satisfaction than conversation quality scores. The platforms responded by centering their measurement frameworks on outcomes.

For DIY builders, this means building two measurement layers in parallel. The conversation quality layer (automated scorecards that grade each interaction on accuracy, tone, and constraint compliance) catches problems in how the agent behaves during the conversation. The outcome layer tracks what happened after. Did the order status change in your OMS? Did the refund post in your payment system? Did the customer contact again within 48 hours?

The two layers need to be connected, because the interesting failures live in the divergence between them. A conversation that scored 9 out of 10 for quality but produced a callback within 24 hours is a different kind of failure than a conversation that scored 6 out of 10 for tone but fully resolved the issue. Neither scorecard alone gives you the full picture. Chanl's analytics layer is built to surface exactly this divergence, pairing per-conversation scoring with post-conversation outcome tracking.

What DIY builders have that platform customers don't

The enterprise platforms made real tradeoffs when they built their systems. They optimized for breadth and deployment speed, which means they gave up control at every layer.

Model choice. Platform customers use whatever model the platform selected and tested. You pick your own. When a new model performs better for your specific use case (more accurate on technical product questions, lower latency for voice, more reliable at structured output), you route to it immediately. You don't wait for a platform update.

Data control. Your customers' conversation data flows through the platform's infrastructure if you're using a vendor. You control where that data lives, how it's retained, what's used for training, and what compliance attestations you can make. For regulated industries like healthcare, financial services, and legal, that control isn't optional.

Unit economics. Enterprise platform pricing is typically per-conversation or per-seat, at margins that include the platform's infrastructure, support, and overhead. At volume, those per-conversation costs compound significantly. API costs scale more favorably, and you control the model routing decisions that drive them.

Workflow specificity. Platform orchestration is general-purpose, designed to work for a wide range of enterprise CX workflows. Your workflow isn't a wide range. It's exactly yours. DIY orchestration can encode the specific escalation triggers, decision trees, and resolution paths that your operation requires, not what the platform designers thought most enterprises would need.

The platforms aren't targeting teams building custom CX agents. They're targeting large contact centers that want to deploy quickly and don't have the engineering capacity to build the four layers themselves. If you're reading this, you're almost certainly in a different situation.

Where to start when you're building the four layers yourself

The sequence matters. Teams that start with the data layer spend months refining tool definitions without knowing which refinements affect outcomes. Teams that start with the context layer invest in memory infrastructure without knowing what's worth remembering. Teams that start with tool orchestration build more reliability engineering than their actual failure rates require.

Start with outcome measurement. Not because it's easiest (it isn't), but because it's the layer that makes the other three legible.

Set up your outcome tracking first. Define what a resolved contact looks like in your operation (no callback within 48 hours? confirmation ID present? order status updated?). Start measuring that rate from day one. Then look at the contacts that aren't being resolved and ask: did the agent have the data it needed? Did it remember context from a previous contact? Did a tool call fail? Each failure points back to one of the other three layers.

The outcome layer gives you signal. Without it, you're guessing where to invest. With it, you know exactly which infrastructure problem to fix next.

This sequencing principle shows up in how the enterprise platforms talk about their own products. They all lead with outcomes, not architecture. The data layer and the context layer and the tool orchestration layer are presented as prerequisites for the outcome, not as features in their own right. They're right about the framing. Build toward the outcome. Let the outcome tell you what infrastructure you're missing.

For teams just starting, our piece on managed agents and the three runtime models for CX covers how to choose the right deployment architecture before you commit to a build-vs-buy decision. The infrastructure layers described here apply regardless of which runtime model you choose, but the sequence of priorities shifts based on how much of the stack you're building yourself.

Learn Agentic AI

Weekly. Patterns for shipping agents that work. MCP, scorecards, regression tests, prompts, model comparisons.

Subscribe

500+ builders subscribed