AI and Customer Experience - Buy or Rent?
IDC describes AI agents arriving in three waves, from a tool one person uses to AI woven through how the business runs. Most customer experience teams are renting the layer they run on. Whether to keep renting a third party’s stack that holds your data, or own the data and run the model directly on it, is the choice this piece is about.
IDC, the “tech intelligence layer for AI”, describes AI agents arriving in three waves. The first is assistive: AI that one person uses to do the work they already do, faster. Most businesses sit here today. With Claude this is the Chat surface, a person drafting an email reply, summarising a thread or working through a policy with the model in the loop at every step.
The second wave is action agents: AI that carries out multi-step work across the systems the team uses, rather than only helping a person do it. With Claude that is Cowork, an agent that takes a whole task, works for minutes or hours, and hands back a result to check.
The third wave is AI woven through the operation as the way the business runs, not a tool sitting on the side. With Claude that is Code, where the model works directly on the business’s own data and systems.
Assistive AI
AI that individuals use to do the work they already do, faster.
Action agents
AI that carries out multi-step work across the systems, rather than only helping a person do it.
AI through the operation
AI woven through the operation as the way the business runs, not a tool bolted onto the side.
Most customer experience teams using AI in wave 2 today are renting it. By this, I don’t mean the large language model (LLM) - the agent that does the reasoning or takes the action, I mean the application within which it runs.
It is connected to the software they already subscribe to. The AI reaches into the helpdesk or the customer-relationship management system (CRM) through that system’s connector, or through its API directly, and reads what is already there: the tickets, the reviews, the survey scores, the chat logs. It can act back into the same system, within the permissions the person already holds, and a person still approves anything that matters. This works, and it is the right place to start. But it is also not the end state, and the near-term move only makes sense once you can see where it goes. Knowing which wave you are in, and which one you are moving to, is the frame for everything else.
Today, the AI typically reaches the data through the CRM, and that system is the store of record. Everything the AI knows about your customers it knows because that vendor’s software is holding it and letting it through.
The future state removes that system as the store of record. In its place you put a database the business owns, built on a knowledge graph: the typed record of what your business actually is, the people and companies and tickets and the defined relationships between them. You give the AI the communication channels directly. The information then lives in a structure built around your business rather than around a vendor’s product, and the model works on it directly. This is the point at which the CRM, as a place where information merely sits, is no longer needed.
That is wave three. AI’s role shifts from making the work faster to taking a more autonomous part in managing customer experience, until it is part of the business itself. Taken to its conclusion, that renders much of today’s CRM software obsolete. When this might happen is impossible to forecast but I would guess at around five years.
Meanwhile, a new kind of product has appeared alongside the frontier models: an agentic layer that sits as a thin skin on top of one of them and packages it into a service you can buy. These products work very well today. I have built many of them (for builders, tradesmen and estate agents). However, I would be the first to admit the potential fragility of their position for two reasons.
The first is functional capacity. The model underneath keeps absorbing the work these products do. Each new release of the model does more of what the layer on top was there to add, so each release cannibalises the product built on it, and the wrapper’s advantage erodes release by release.
The second is sovereignty and control. To use one of these products you hand it your data to hold and your processes to run. You give up control of the thing that carries your value, and you hold it on terms the vendor sets. To a large extent, you are just swapping that state from the 3rd party CRM to the third party AI wrapper.
The durable position reverses both. You keep your data in a structure you own - a knowledge graph - and you use the frontier model directly on it. You gain the model’s growing capacity for free with every release, and you never give away control. Owning your graph and running Claude directly on it is itself building on the model, and that is the intended position. Renting a third party’s agentic stack that holds your data is the fragile choice. Owning your data while using the model directly is the resilient one.
The control argument goes further than where the data sits. When you hand your operation to a third-party product and you suggest an improvement, that improvement becomes their feature, and they sell it to your competitors. The insight you generated leaves your business. Owning the system keeps the value where it was created.
A mere few years ago, this opportunity was not even worthy of consideration but now, rebuilding the software is tractable. A CRM is about eight well-understood parts: a data model, a datastore, an activity timeline, channel integrations, segmentation and querying, workflow rules, reporting, and an interface. Each one can now have a native equivalent built from a language model and a knowledge graph. The data model becomes an ontology and a graph the business defines. Segmentation becomes questions asked in plain language over that graph. Reporting becomes the model writing the analysis on demand. The interface gets thin, because the heavy logic has moved to the model and the graph.
Interface
Wave oneThe workspace and admin console people sit in front of.
Analytics and reporting
Wave oneThe dashboards and figures read back off the data.
Automation and workflow engine
Wave twoThe rules that route, tag and act when something happens.
Query and segmentation
Wave twoHow records are filtered and grouped into the lists and views people work from.
Integration layer
Wave twoThe connectors and interfaces that carry channels in and send data out.
Event and message pipeline
Wave twoEvery email, call, chat and note, captured against the record it belongs to.
Data model
Wave threeThe typed records (people, companies, deals, tickets) and the defined links between them.
Record store
Wave threeThe one database that holds every record, and the identity that says who is who.
None of that is a new invention. It is an assembly of parts that are already understood, and writing the software itself has collapsed from a project of months to a matter of hours. The work that remains is not the build, it is the data, knowing what to build, and knowing whether it is working. The hard parts are self-evident: cleaning the records before you move them, matching records that mean the same real person, keeping figures consistent across systems, keeping plain-language answers accurate over time, and deciding what an agent is allowed to write.
In all my projects, I maintain that a person should always remain in the loop, for two reasons. The AI cannot yet be trusted to run unattended, so its output is a draft for a person to check. And the business has to keep the human capacity to do the work for the times the AI is unavailable or wrong; once that capacity is gone it is costly to rebuild.
Automation read this way frees people rather than removes them. Every routine customer contact is also a chance to strengthen the relationship. You automate the routine so the people you have can spend their time on the contact that builds those relationships, which is work only a person can do.
Gartner established customer-journey mapping as standard practice in customer experience, and any plan to use AI has to begin there. Map where the journey is already covered across the current stack, across marketing, sales, support and product analytics, and map where the gaps are, before building or buying anything. Without that map there is no way to see where AI should sit.
The first value is low-risk, and it is reading what you already hold. Point your own AI at the systems you already run, through their connectors or their APIs, and let it read across them. A support team knows more about its customers than anyone has time to read. The AI reads all of it and returns a short list worth acting on. A person still decides, and the output is a draft to check. This is wave two, and it pays back in days rather than months, which buys you the time to plan the deeper change.
Effective AI adoption does not start with the tools. It starts with reorganising how information flows through the business, so that it makes sense to rebuild systems around what AI can now do. Do that and you find that many legacy applications, the ones built for people to click through, are now the biggest source of friction and the biggest technological risk you carry. That is the real work, and most of it is not yet being reported while the headlines go to individual adoption.
I believe everyone will reach wave three within about five years (or become obsolete). The sooner you get there, the longer you hold the advantage before it becomes the norm. What sets the pace is not the technology, it is closing the gap in what you do not yet know is possible, and putting a few capable people who understand both the customers and the tools inside the business.
Because the build itself has collapsed to weeks, not months, the value has moved from the builder to the operator. What is left is the data and the judgement. A team that knows its customers can build a better system than it can buy, because the value is in that knowledge, not in the vendor’s code. The person who holds that knowledge now decides where customer experience goes. The choice of tool sits underneath that decision.
My own view on timing is that the window is short. The businesses that start the reorganisation now are the ones that will define their category by 2027, because at that point early integration begins to outweigh the old moats of network effect, brand equity and switching costs. Keep the decisions reversible and the data portable while you do it. The five-year shift will impact everyone one way or another.
If you are weighing whether to keep renting your customer-experience stack or to own the data and run the model directly on it, that is a conversation we have every week. We help you map the journey, build the graph you own, and keep a person in the loop at every step.