AI is not the USP. Context is.

By Adam Dustagheer

There is a point in almost every AI conversation where someone starts looking for the clever bit.

Which model are we using? Is it an agent? Is it predictive? Can it learn? Do we need sensors? Could it be conversational?

All valid questions. But they can also be a very efficient way of getting lost.

The thing I keep coming back to, particularly when we are working in public services, is that the technology is not the USP. As I said recently in a discussion on applying AI in care, “the technology is an accelerator”.

That does not mean the technology is unimportant. It is hugely important. It is also getting easier to access, quicker to build with and more capable by the month. But that is exactly why it is less likely to be the thing that makes a service, product or organisation distinctive in the long term.

The differentiator is what sits around the technology: the problem you choose, the data you bring together, the context you apply, the standards you set, the safeguards you build and the way people actually use it.

Or, more bluntly, if we are not careful, we end up with a lot of very impressive kit that is not solving the right problem.

Start with the “so what?”

Public services are dealing with increasing demand and finite, often diminishing, supply. That is the reality. So the question is not simply what can AI do. It is what is the best route through, pragmatically, and what gives you the most bang for your buck?

That needs to be the starting point.

Before we get too far into architecture, models or hardware, we need to define the problem in a way that is real enough to test. What is the outcome we are trying to improve? Who needs to make a better decision? What action could they take as a result?

I tend to call this the “exam question”.

If we are talking about a really big, complex area, there is a danger that you try to boil the ocean. You can pull together every data source, imagine every possible capability and still end up with something that does not have a clear reason to exist.

The more useful question is: if we get all of this from raw data through to an outcome, what is that outcome? And does the market, or the service, actually care about it?

That is the grounding point. Without it, “the meatballs get lost in the sauce”.

Use what is already there

There is often a rush to introduce more technology. More sensors. More devices. More data collection.

Sometimes that is right. But it should not be the default.

In a lot of public-service environments, there is already a huge volume of information available. It may be spread across care plans, case notes, risk assessments, service records, incident logs, operational systems and documents. It may be structured badly. It may not talk to other systems. But it exists.

So the first design question should usually be: what can we scoop up from data that is already available, and how can we use it properly?

That is not an argument against sensors. They can be useful. But data is only valuable if it supports an actual decision or action.

For example, a sensor may tell you that something is medium or high risk. From a clinical or operational point of view, that may not be enough. If the result is hedged, if it does not explain what has changed or what someone should do next, it can be difficult to apply safely.

The goal is not to collect everything. It is to identify the smallest useful combination of information that helps someone understand what is happening and act appropriately.

The real work is context

We started Datnexa thinking that we were a data company. Then we thought we were a technology company.

Actually, we are neither.

“We’re in the bit in between. We’re like a, we’re an ontological company. We provide context, right?”

That is the bit that matters.

Raw data can tell you what exists. It can tell you that there is a door alarm, when it went off, what type it is and where it was supplied from. That is content.

Context explains why any of that matters.

“The context is this is what you use when you’ve got someone who’s wandering at 3 o’clock in the morning.”

That is a much more useful proposition. It connects the device, the data, the person, the circumstances and the possible action.

Context may include basic metadata, such as format, provenance, thresholds and confidence. But it also includes the real-world understanding that says: this is the scenario in which this information is relevant; this is the outcome we are trying to influence; and this is what should happen next.

It is not just the content. “It’s not just the content, it’s the context to get you deliverable.”

That is what turns a collection of data into something that can support a decision.

Standardisation gives data operational teeth

If you are combining information from different sources, you need to get it speaking the same language.

That means standardisation. But it is important not to think of this as simply a technical clean-up job.

Standards become valuable when they make data interoperable in a context where it can actually be used. As I put it in the discussion, the value is in being able to “standardize across different data sets and then increase, like, the interoperability of that data in a context that then actually gives it, like, operational teeth”.

That last point is key.

A shared data standard is useful. A standard that helps a frontline team understand risk, decide what to do and explain why they did it is much more useful.

There is also a strategic point here. Technology platforms change. Models change. In a few years, today’s “must have” capability will likely be table stakes or replaced by something else.

But if you have defined the rules of the game, established the standards, built the contextual model and helped people adopt it, there is real defensibility in that.

“If you are first in place to define the rules of the game, I put the standards down, then that kind of places you into that sort of winner-takes-all approach.”

I would caveat that this is not legal advice on IP. But from a product and service perspective, the durable value is often not owning the model. It is owning, stewarding and improving the layer that makes the model useful.

Build a stable scaffold

One of the least glamorous but most important design choices is deciding what the system is actually organised around.

If you are working across multiple data sets, what is your core entity? Is it a person? A household? A property? A care package? An episode of care? A condition over time?

You cannot avoid making that call.

I describe this as building a stable scaffolding model. It is the decision about what becomes your “one version of the truth”, even when you are bringing together sources that have been designed around completely different things.

In one setting, the base unit may be the person. In another, it may be the care package. In another, it may be an episode of care. A single person may have multiple care packages, each with several episodes.

If you do not establish the scaffolding early, complexity does not simply add up. It compounds.

“For every time you don’t make one of those decisions, there’s a point later on down the line. When that lack of decision, having two options, doesn’t double stuff, it kind of squares stuff.”

This is where normalisation, categorisation and a clear model matter. You need to be able to bring heterogeneous data into consistent entities, understand what those entities mean and be clear about how you aggregate or disaggregate them.

It also helps explainability. If an AI tool later identifies a pattern, raises an alert or produces a summary, there needs to be a clear line back through what it saw, how that information was treated and why it produced that output.

You need, in effect, a defence log.

Do not use AI where rules will do

There is a tendency to assume that every AI-enabled service needs AI in every part of it.

It does not.

If the task is fundamentally “if this, then that”, you may be better using clear, deterministic logic. It is easier to explain, easier to test and often safer.

“If it’s something that needs to be like, if this, then that, there’s no point having a four-by-four and sticking it on rails.”

In a care setting, for example, there may be clear thresholds or deviations from a known baseline that should trigger a check-in. That could be a defined rule. It does not necessarily need a probabilistic model.

AI becomes more useful where there is ambiguity, scale or patterns that are difficult for a person to see across many sources of information. It may be good at spotting trends underneath the hood. It may identify gaps in the information. It may help summarise a large, complex record. It may help interpret intent in a conversation rather than just matching keywords.

That is where it can act as a useful first or second pair of eyes.

But it needs to be used deliberately. The question is not whether an AI can do something. It is where it is of most use and where it is appropriately used.

Give the agent a contract

One of the ways we think about agents is that they need a contract.

“You’ve got the brain, you’ve got the Claude that’s doing the thinking, but you need to tell it what its parameters are.”

That contract should be explicit.

Here is the information you can access. Here are the services you can use. Here are the things you can do. Here are the things you cannot do.

This matters in any environment, but it matters particularly when you are dealing with care, health, safeguarding or public services more broadly. The stakes are higher. The data can be sensitive. The decisions can affect people directly.

There is a real risk in putting too much into an agent and asking it to do too much, too consistently, over time. A lot of AI is probability-based. That can be useful. But it is not the same as a clear operational rule, and it should not be treated as one.

I would be particularly cautious about using AI to define the rules for AI without the right level of oversight. That is where you can create a system that becomes difficult to challenge, explain or control.

The job is to set the boundaries first, then use the model within them.

Human in the lead

Human oversight cannot be a footnote.

Even if a system can do more, the question is whether it should. In many public-service settings, I do not think the market would wear a fully autonomous system. More importantly, I do not think it would be the right design choice.

“Human in the loop” is a useful phrase. But increasingly, I think we should be aiming for human in the lead.

AI can help staff see what they may not otherwise see. It can draw together information. It can flag a pattern. It can make a complex data set easier to interrogate.

But the system should support professional judgement, not quietly replace it.

There is also a practical risk of over-reliance. If a tool labels someone as low risk and that assessment is wrong, the consequences can still be serious. So we need to design for worst-case scenarios, not just the happy path.

This is why the human element needs to shape the entire process. What actions are available? What does a risk level actually mean? Who is responsible for responding? What should happen when information is incomplete? What is the appropriate level of intervention?

An alert is not an outcome. The outcome is better judgement followed by appropriate action.

Make it configurable and test it in reality

AI projects often fail because they are designed as a fixed product, bought by IT and handed over to people who were not involved in creating it.

Then nobody uses them.

The practical design principle is to code as little as possible and abstract as far as possible, so that changing a configuration does not always require a developer. This does not mean abandoning rigour. It means creating a service that can be adjusted as people learn what works.

There are two parts to this work. There is the technical architecture. Then there is the conceptual design: how the data fits together, what it means and how people will use it.

The conceptual work comes first.

You can build a dashboard. You can build a conversational interface. You can add an agent that checks for patterns, flags anomalies or answers questions. But the choice should come after we understand the use case, the users and the operational decision we are trying to support.

As a team, we place as much value on the people side as the technical side. “The adoption of the tools [is] almost as important as the tool itself.”

User acceptance testing is not a final hurdle. It is how you refine the system, build confidence, surface contextual knowledge and avoid creating a very expensive tool that does not fit the reality of the service.

The work has moved upstream

There is a slightly odd thing happening with AI.

The technology is making some forms of building much easier. Work that might have needed large teams and long delivery cycles a few years ago can now be done much more quickly.

But the work has not disappeared. It has moved.

“It’s a displacement effect.”

The hard work is now more clearly in defining the problem, understanding the operational context, agreeing standards, setting thresholds, building safeguards and designing for adoption.

That is not a problem. It is a good thing. It gives organisations an opportunity to focus on what they should have been focusing on all along: outcomes.

If we can really crisply define the problem, the technology can increasingly help us do the rest. But if we cannot explain the problem, the user, the context, the decision and the desired outcome, then no amount of AI capability will rescue the project.

The best public-service AI will not be the flashiest. It will be the AI that helps people do better work, makes services more understandable and responsive, and delivers value that lasts.

That is the bit worth building.