Stop searching for AI 'use-cases'. Design AI into services.

It’s not a very popular opinion, but I think the clamour in organisations for AI “use cases” is flawed. Not because of the technology per se, but because the search for purely or majority AI services, which is what this implies, misses a greater opportunity.

I’ve had a few people tell me that Platformland doesn’t have much to say about AI. The answer is that, actually, it does, but it just doesn’t lead with it. (For example, the book includes design patterns for agents using verifiable credentials, AI-generated task lists, and summaries of past events.) The reason for that is because my bias is towards seeing AI as part of the design of services.

The principles of what makes a well-designed service remain the same as in the pre-AI digital era. AI should be treated as a design material rather than as a product in its own right. The goal of introducing AI into services should not be to create new “AI services”, but to make services work better for users.

In many cases, AI will only play a small role in a service, supporting particular tasks or parts of a workflow rather than defining the entire experience. In practice, this means embedding AI into the structures and processes that make services work. AI might:

• suggest tasks based on previous interactions
• partially complete an application form before presenting it for human review
• provide real-time context by surfacing relevant information during an online appointment
• categorise a photograph uploaded by a user
• summarise a case history in advance of an in-person visit

In each of these examples, AI and automation are only part of the service; AI simply helps the service operate more effectively for users.

Taking a stance of designing AI into services also means avoiding the assumption that conversational interfaces are the primary or default way to access services. Chat-based interfaces can be useful in some contexts, but they should not become the dominant model simply because the technology makes them easy to build. (I am much more interested in AI appearing in human conversational spaces, in an augmentation role, rather than as an intermediary anyway). Services—especially public services—require a variety of interactions: structured forms, documents, credentials, human conversations, and asynchronous tasks. We should be applying AI to those interactions and those spaces, not only the creation of new ones. ^[1]

Finally, designing AI into services frees us from the framing of AI as some sort of progression matrix in which agentic systems are the de facto “end state”, and everything else is a step on the journey akin to the (flawed) [March of Progress](March of Prorgress). Things like that fit nicely into a consultancy’s maturity model, but are not very helpful when it comes to the task of actually designing services. Future services will use a mix of machine-learning-based pattern recognition, LLM-generated interfaces, and agentic workflows, and they will do this alongside more traditional deterministic rules-as-code approaches. This should be obvious, but it seems to be being lost.

I do understand the clamour by senior leaders for AI use-cases - the need to be seen to do something, the promise of savings, the general excitement - but it probably won't help them in the medium to long term. By positioning AI as a material that can be incorporated into different parts of a service, they can focus on the actual work: improving how services actually work.