Leaders drive AI value with these 5 actions

Use AI only where the work genuinely needs judgement. Put everything rule-based in code, decide where a human stays in the loop, and base your cost on the full system you will actually build, not on the demo.

What goes wrong

The project is chosen on what AI can do, and the whole job is handed to it. AI is strong where the work needs judgement: reading messy or ambiguous input, weighing options, drawing things together. It is the wrong tool where the rule can be written down. There, plain code is cheaper, faster, predictable, and it cannot make things up.

The common mistake is to hand the whole process to AI in one go, when only a step or two actually needs judgement. It costs more to run, behaves differently every time, and is far harder to make reliable than the same process split into AI steps and code steps. None of that running cost or design work reaches the business case, which is built on the demo, so the numbers are wrong before the project starts.

What good looks like

Break the workflow into steps. Mark the steps that genuinely need AI, and the steps that are rules and belong in code. For each decision the agentic system makes, decide how much it should do on its own. There are four levels, in order of increasing autonomy:

• Provide information. The agentic system produces information; a person interprets it and acts.
• Recommend actions. The agentic system recommends specific actions; a person takes them.
• Act with human approval. The agentic system acts, but only with a person's sign-off on each action.
• Act independently under policy. The agentic system acts on its own within set rules, and a person reviews only the exceptions.

That boundary is the single biggest driver of cost and risk: the more the agentic system does on its own, the higher the running cost and the human oversight needed, and many firms underestimate both.

What decides whether the case works is the cost to run, not the cost to build. Two things move that running cost the most: which AI model you use for each step, and how tightly you manage the information you send it each time. Use a smaller, cheaper model where it is good enough, and the most capable model only where the judgement really needs it, and send it only what it needs rather than everything every time. Done well, that is often the difference between a business case that works and one that does not.

You make an agentic system reliable with checks built around it in code, not by writing a cleverer prompt. Design those checks in from the start, at every point where information goes into or comes out of the AI.

What goes wrong

AI states things it has not checked, and it states them with complete confidence. It also cannot reliably catch its own mistakes, because the same weakness that caused a mistake stops it noticing the mistake. So you cannot make an agentic system reliable by telling it to be careful or to check its own work. That helps for a while, then fails.

AI will also never stop and admit it cannot do something. Ask it for five examples when the information only supports two, and it invents the other three. Tell it it can look something up when that connection was never actually built, and it makes up an answer rather than say it cannot. It fills any gap with something that looks right, to finish the task.

The information the agentic system is given is often messy or incomplete, because preparing it properly is more work than people expect, and the poorer that input, the worse the output and the more the agentic system makes things up. The access it is given, to systems and records, is often wider than it needs to be, so a single malicious input can use the agentic system to reach data it should never have been able to see. AI gets far more attention than the data and the design around it, which is the wrong way round.

And the handover to people is left vague: what the agentic system passes to a human, when, and to whom. Pass too much across and people approve it without checking, and the value disappears. Pass too little and mistakes go straight through. The people who have to approve the agentic system's decisions are often not trained to judge whether it has got them right.

What good looks like

Build the checks into the code that surrounds the AI, not into the AI's instructions, so the AI cannot get round them. Put them in at the very start of the work, not after the agentic system is live, because adding them at the start is far less work, and far less risky, than going back to fit them after something has gone wrong.

Check in three places: what goes into the AI, what passes from one step to the next, and what comes out. Then build the controls themselves:

• Minimise fabrications, and catch any that get through. Instead of letting the AI write out a quote or a figure, have it point to the exact source it is using, and let the code copy the real wording straight from that source, so the AI never writes the quote and cannot fake one. Then add controls at the end of the process to catch anything that still slips through.
• Check the source genuinely backs the claim, not just that a source is named, because a made-up source with a believable title looks fine on the surface.
• Limit what the agentic system can reach. Set exactly what data it can see and what actions it can take, and assume that at some point someone will feed it input designed to make it misbehave.
• Keep a full record of everything it read and did, so that when something goes wrong you can see exactly what happened.
• Be deliberate about what passes to a person. Decide which decisions go to a person, on what trigger, and to whom: send enough that real mistakes get caught, but not so much that people approve everything without reading. Make sure those people are trained to judge the call.

You cannot test an agentic system the way you test normal software, because it gives different answers to the same input. Measure how well it does across a large set of real cases before it goes anywhere near live work.

What goes wrong

The agentic system works in the demo, so it is treated as ready. But AI gives a different answer every time, even to the same input, so one good run tells you almost nothing about the next. Three problems only appear once it is handling real, everyday use:

• Quality varies across the full range of real cases, which the demo never covered.
• The running cost comes in higher than the estimate, because real inputs are longer and messier than the neat ones used in testing.
• Someone can deliberately craft an input that makes the agentic system leak data or take the wrong action.

And what the agentic system does when something goes wrong is usually never tested at all, so no one actually knows. The code looks like it should cope, which is not the same as knowing it does.

What good looks like

Build a test set of real examples: a fixed collection of the real inputs the agentic system will face, each one with the correct answer worked out in advance, and a clear way to mark how close the agentic system's answer is to it.

Run the agentic system over every example in that set, and run it several times over, because it answers differently each time. That shows you the full range of how well it performs and what it costs, rather than one good or bad result.

Check the things that can be counted using code, not the AI itself: whether it used a real source, whether it stayed within the rules you set, how long it took, and what it cost. If you ask the AI to mark its own work on these, it will often give a confident but wrong answer. For the things that need judgement, use a separate reviewer, a different AI model or a person, whose only job is to find where the agentic system gets things wrong.

Then roll the agentic system out in steps:

• Run it alongside the people doing the work, taking no action, and compare its answers to theirs.
• Then a small live trial.
• Then full use.

What lets it move from one step to the next is its scores reaching a level you set in advance, not a date in the plan. And make it fail on purpose during testing, so you find out what it does when something breaks before a customer does.

Lead the agentic system implementation as a change project, not just a technology one. Plan how an agentic system will reshape organisation structure, roles, skills and processes. Evaluate what is possible and desirable, and ensure the business case stacks up once you take everything into account.

What goes wrong

The programme is run as a technology delivery. The big questions are never asked at the start: what the agentic system does to the organisation around it, how the work and the roles change, what new skills are needed, and what it frees people up to do. An agentic system can take real work off a team and free them for higher-value work. It can also change the nature of a job entirely. Either can be easy to absorb or genuinely hard, welcome or resisted, and that shapes which use cases are worth starting with and what the return really is. Without that picture, the build can succeed while the programme fails: the system works, but the organisation never changes around it to capture the value.

What good looks like

Lead the work as a change project from the first sprint, alongside the build. Before the build is committed, work through the effect on structure, processes, roles, resourcing and skills, and put it in the business case, because it changes both which use cases to start with and what the project is worth. Design the benefits to be felt across the organisation, not kept inside one team.

Show the people whose work changes what it means for them, and give them the skills the new way of working needs. Show leaders the same picture, because the choices, on structure, on roles, on where freed-up time goes, are theirs to make. Then apply the basics of good change management: bring sceptics in early rather than working around them, use champions to build confidence, and involve staff representatives where that applies.

An agentic system is not finished at launch. It slowly gets worse on its own, and unlike normal software it does not fail loudly when it does. Someone has to own it, keep watching how well it is doing, and keep fixing it.

What goes wrong

No one owns the agentic system once it is live. It gets worse on its own over time: the inputs it sees change, the AI provider updates the underlying model, and new situations it was never tested on keep coming up. None of this throws an error the way broken software would, so the decline is silent. There is no routine for spotting new failures, no safe way to stop the agentic system when it goes wrong, and no one checking whether it is still worth what it costs. It drifts, and within months the agents are switched off and the manual work comes back.

What good looks like

Give the agentic system a named owner before it goes live. Run the test set you built to prove it works against the live agentic system on a regular schedule, so a drop in quality shows up as a number you can see, rather than as a complaint from a customer.

When the agentic system makes a mistake in real use, do not just correct that one case. Add that case to the test set, and add a check in the code that catches that type of mistake from then on. Over time, every mistake the agentic system has made becomes a test it has to keep passing, so the same problem cannot quietly come back, and the agentic system gets more reliable the longer it runs.

Put in automatic cut-offs that stop the agentic system, or hand the work back to a person, when mistakes start to pile up. Record everything the agentic system does, because you cannot fix problems you cannot see. And review each agentic system regularly on what it actually delivers and what it costs: expand it, leave it as it is, scale it back, or retire it.