Digital Economy Dispatches #293 -- Where is the Intelligence in Your AI Strategy?

Ask most senior leaders what they mean when they talk about artificial intelligence, and you will most often get an answer about capability. Larger models. Better reasoning. More automation. Faster answers. The conversation almost always fixes on what the technology can do.

That framing is not wrong. But it misses a more important question: where does the intelligence sit once a technology like this is loose in an organisation? The answer to that question has changed profoundly in recent years, and most enterprise AI strategies have not yet caught up.

From products, to services, to outcomes

For most of the last century, businesses thought of themselves as producers of things. Value was manufactured, packaged, and shipped. The customer's role was to buy, use, and eventually replace. The intelligence, such as it was, sat inside the product itself: in its design, its features, its engineering.

The shift to services complicated this picture. Value was no longer just in the artefact but in the ongoing relationship. Cars became transport contracts. Software became subscriptions. Elevators became lifecycle service agreements with predictive maintenance built in. The intelligence shifted into the service delivery model: the workflows, the SLAs, the support functions that made the relationship work.

Then came platforms and access-based models. Instead of owning a service, customers gained the ability to draw on capability when they needed it. The intelligence appeared to move again, this time into the infrastructure that allowed access at scale.

More recently, the frame has shifted once more, this time toward outcomes. Increasingly, buyers do not want a product, a service, or even access. They want the result: the diagnosis, the decision, the completed task. That shift changes almost everything about where the intelligence needs to sit as we seek to deliver greater value from AI.

What Vargo and Lusch saw twenty years ago

The intellectual scaffolding for this shift is older than most enterprise AI conversations. In 2004, Stephen Vargo and Robert Lusch published a paper in the Journal of Marketing titled "Evolving to a New Dominant Logic for Marketing"" that reframed how we should think about value creation. They called their framework service-dominant logic, or S-D logic, and its central claim was quietly radical.

Value, they argued, is not embedded in things. It is co-created between provider and user within the specific context in which a product or service is put to use. A car sitting in a showroom has no value. The same car in the hands of a driver, on a road, going somewhere that matters, is where value comes into existence. The provider offers a value proposition. The user, applying their own knowledge, context, and needs, completes the act of value creation.

This idea has been developed by a wide community of scholars over the past two decades and echoed in adjacent work. Prahalad and Ramaswamy's paper "Co-creation Experiences: The next practice in value creation" argued that the interaction between firm and consumer is becoming the centre of value creation. Earlier still, Normann and Ramírez had made the case in "From Value Chain to Value Constellation" that successful companies do not simply add value but reconfigure the relationships among suppliers, partners, and customers so that value can be produced together. The common thread across all three is consistent. Value is not delivered. It is produced together, in use.

Why this matters for AI

If value is co-created, then intelligence cannot sit purely in the product or be wrapped around a service. A large language model, however capable, is inert until it is used in a specific context by a specific person trying to do a specific job. It cannot know, by itself, what a good answer looks like for this user, in this moment, for this purpose.

Intelligence also cannot sit purely in the service delivery mechanism. Wrapping a model in a chatbot interface, or plumbing it into a workflow, does not by itself produce a useful outcome. The chatbot that answers everything competently and nothing well is now a familiar feature of enterprise pilots.

Nor does it sit purely in the AI infrastructure. Compute, data pipelines, and model registries are necessary but not sufficient. Plenty of well-provisioned organisations have deployed impressive stacks and produced disappointing results.

Even the accumulated experience of the organisation providing the service is not quite the right answer. Organisational knowledge matters, but it is a resource brought to the interaction, not the interaction itself.

The intelligence, in any serious sense, lives in the interaction. Most people, when they hear that, translate it as “workflow”. That is understandable. Workflow is the familiar language of enterprise IT: define the steps, plug in the tool, measure the throughput, iterate on the process. It is also the operating assumption of most enterprise AI programmes, which treat the workflow as the unit to be redesigned around a model, a copilot, or an agent.

But workflow and interaction are not the same thing, and the difference matters. A workflow is the designed sequence of steps that describes how a process is meant to run. An interaction is what actually happens when a user, an organisation, and an AI system meet in a specific moment to produce a specific outcome. Two organisations can run an identical workflow and get very different results, because the interactions inside it play out differently, on different data, with different users, under different pressures. The workflow is the script. The interaction is the performance.

Design at the level of the workflow, and you optimise the sequence while hoping the interactions inside it are good enough. Design at the level of the interaction, and the workflow becomes a consequence of what you learn from thousands of specific exchanges. It is the interaction that brings together a user's context and intent, an organisation's capability and knowledge, and an AI system's models and data to produce something useful. That choreography is where the value is created. It is also where the intelligence has to be designed, governed, and improved.

From doing AI to being AI

This is why so many enterprise AI programmes stall in what I have called pilot purgatory. Organisations approach adoption as if they are installing a product or standing up a service. They procure the technology, define the workflow, train the users, and wait for the value to arrive. It rarely does, because the model of value they are working from is the wrong one.

The organisations that are making genuine progress are doing something different. They treat intelligence as an interactional property. They invest heavily in the mechanisms that capture what happens when users engage with AI, govern how that engagement takes place, support the user in getting the most from the system, and enhance the system based on what is learned. They build feedback loops as first-class infrastructure. They treat the interaction, rather than the model, as the product.

That is the shift from doing AI to being AI. Doing AI is a project, an initiative, a line on a transformation roadmap. Being AI is a change in how the organisation understands where its value comes from, and what it takes to sustain that value in an era of co-created outcomes.

There is a reasonable objection here. Not every AI application needs to be understood this way. A spam filter, a fraud-detection model, or a defect classifier can reasonably be thought of as a product feature that either works or does not. Fair enough. But the frontier of enterprise AI adoption today is precisely in the domains where the objection breaks down: knowledge work, judgement, customer relationships, decisions with context. Those are the domains where co-created intelligence is not a metaphor. It is the operating model.

Questions worth asking

If any of this resonates, three questions are worth discussing with your senior team.

First, when you look at your current AI initiatives, where does your organisation assume the intelligence sits? In the model? In the process? In the platform? What follows from that assumption, and is it still the right one?

Second, what mechanisms do you have in place to capture, govern, and learn from the actual interactions between your users, your systems, and your customers? Are these first-class investments, or afterthoughts wired in once the pilot has already launched?

Third, if value is genuinely co-created in the moment of use, what does that mean for how you measure success, and for how you distribute the returns between provider, user, and the wider system in which both operate?

The organisations that answer these questions well are the ones that will move beyond the pilot phase. The rest will keep buying technology and wondering why the results keep disappointing.