IBM cites research that 31% of employees admit to working against their company's AI strategy. No agent survives that. How to get people on side first.
The figure nobody puts in the business case
IBM's guide to return on agentic AI quotes a Forbes survey in which 31% of employees admitted they were actively sabotaging their company's AI strategy. Not ignoring it. Working against it. Alongside that, 81% of the executives IBM surveyed said that winning with AI depends on having the right people in the right roles with the right incentives.
Put those two numbers next to each other and you have the real reason most agents do not pay back. The agent works. The people around it do not use it, do not trust it, or quietly route around it. The measure from the first post in this series never moves, and the sprawl from the second grows because everyone builds their own instead.
We run projects for a living, and this is the part of an AI programme that decides it. Not the model. Not the architecture. Whether the thirty people whose jobs just changed come with you.
Why people resist, and why they are often right
It is tempting to treat resistance as a change management problem to be managed. Mostly it is information. People resist agents for reasons that are usually sound.
They have seen the agent be wrong. One confident, incorrect answer in front of a customer and trust is gone for a year. If the agent reasons over data the business does not trust, the people who know that data will not trust the agent either. This is the same thing we say about dashboards: the number has to be trusted before anyone acts on it, and AI makes that matter more, not less.
They do not know what it means for them. An agent that takes the first draft of every quote is either a relief or a threat depending on what you have told the person who used to write them. If you have told them nothing, they will assume the worst.
They were not asked. The people who do the process know where it actually breaks. If the agent was designed by someone who has never done the job, it will automate the easy part and ignore the part that hurts, and the people will know within a day.
What works
IBM's advice is to turn employees into ambassadors, from the top down and the bottom up. We would put it more plainly. Involve the people who do the work, early, and give them a reason to want it.
Start with the people, not the use case. Before scoping an agent, spend half a day with the team that owns the process. Ask them what they would automate if they could. The answers are usually better than the ones in the steering group deck, and the team now has a stake in the result.
Be clear about what happens to the time. If an agent gives a team ten hours a week back, say what those hours are for. More customers, better work, shorter days, fewer temps. Silence on this question is what turns a productivity gain into a redundancy rumour.
Show the agent being wrong, on purpose. In the pilot, put the agent's mistakes in front of the team and let them correct it. People trust a tool they have seen fail and recover far more than one presented as finished. It is also the fastest way to improve the agent.
Measure adoption, not just output. An agent used by three people out of thirty has not paid back, whatever the per-case saving. Track who is using it, who has stopped, and why. We build this into every Analytics Acceleration Programme, because adoption is the number that predicts all the others.
Train for judgement, not for clicks. The skill people need is knowing when to accept what the agent produced and when to question it. That is a one-hour conversation with examples, repeated, not a course. Our post on the skills that matter when the tools stop saying no goes into what that looks like.
The role of the leader
IBM describes executives rallying the organisation and running internal AI challenges with thousands of staff submissions. That is a large-company answer. In a business of two hundred people the equivalent is simpler and harder: the managing director or finance director uses the agent themselves, in front of people, and talks about what it got wrong as readily as what it got right. Nothing we have seen moves adoption faster than a senior person being visibly, cheerfully, a user.
The other leadership job is to protect the kill condition. If the sponsor agreed that the agent would be paused if the measure did not move, and then it does not move, pause it. Teams watch that. An organisation that stops a weak agent earns the right to launch a stronger one.
Where this leaves the business case
Put adoption in it. Name the team, name the person who will lead them through it, and budget the time. In our experience the people side of an agent programme costs about as much as the build and returns more. If a proposal for an AI agent has no line for the people who will use it, the return in that proposal is a guess. Our AI will not replace your analysts post makes the same point from the other direction.
The agent is the easy part. The people were always the project.
Related reading
Only one AI agent in four pays back. Decide what you are measuring before you build one
Agent sprawl: why ten clever agents add up to less than one good workflow
AI will not replace your analysts
What an ongoing data function looks like, and why it beats another one-off project
Claire Harper
Projects Director
Part of the Hopton Analytics team, delivering governed analytics programmes for UK mid-market organisations.
