The rollout does not fail in the meeting. It fails in the four weeks afterwards, and almost silently.

Everyone in the room agreed the demo was impressive. Nobody objected. The agent was connected, the access was granted, the training session happened and was well attended. And then, gradually, the team went back to doing the work the way they did it before, and the tool became something that exists rather than something that is used.

There is a temptation to read this as a technology problem, because a technology problem is the kind you know how to solve. It is usually not. The most common reason an agent does not get adopted is that nobody ever said what it meant for the people expected to adopt it, and in that silence they reached their own conclusions.

Resistance almost never announces itself

Open refusal is rare and, when it happens, it is a gift. Someone who says in a meeting that they think this is a bad idea has given you a position you can engage with.

What you get instead is agreement followed by absence. The agent flags something and the flag is not actioned. The summary arrives each morning and is not opened. Somebody asks a question in the group chat and nobody answers it, and the question is not asked again. None of this looks like opposition. All of it is.

The reason it stays quiet is straightforward. In most organisations, being visibly unenthusiastic about a new technology is a bad career move, and people know it. So the objection goes underground, where it cannot be addressed, and expresses itself as inertia instead.

If you want to know whether your team is behind the rollout, the honest signal is not what they said in the session. It is what they did in week three.

Three things people mean when they go quiet

The unspoken objection is usually one of three, and they need completely different responses.

The first is: I think this is here to replace me. This is the one everybody assumes and the one least often true, but it does not need to be true to do damage. If an agent has been introduced to a team whose work it visibly overlaps with, and nobody has said anything about headcount, people will draw the obvious inference. Silence on this point is not neutral. It reads as confirmation.

The second is quieter and far more common: I think this will make me look slow. Somebody who has spent nine years becoming the person who knows where everything is has a real stake in the existing system, and a tool that makes that knowledge instantly available to everyone else does not feel like relief to them. It feels like a demotion nobody announced. This is not irrational, and it is rarely admitted.

The third is the most practical: I think I will be blamed when it gets something wrong. This one is usually correct. When an agent drafts a reply and the reply is wrong, the accountability lands on the person who sent it, not on the vendor. Being asked to put your name to output you did not produce and cannot inspect is a reasonable thing to be cautious about. Anyone who has worked somewhere long enough has seen how quickly a shared tool becomes an individual's mistake.

Only the first of these is about fear of AI. The other two are about the specific politics of your business, which is why generic reassurance about how the technology is here to help does nothing for either of them.

The announcement sets the frame, and you only get one

Whatever is said on the day the tool is introduced becomes the story the team tells about it, and it is very hard to revise later.

The framing that fails most reliably is efficiency. Telling a team that a new system will save them time sounds positive and lands as a threat, because the obvious follow-on question is what happens to the time, and the answer everyone assumes is that it gets taken. Efficiency is a story about the business. It is not a story about the person in the room.

The framing that works is specific and small. This agent reads the shared inbox overnight and tells you which four things need you before lunch. That is not a claim about transformation. It is a description of a job, and it is checkable by Thursday, which means it can earn trust rather than asking for it.

It also helps enormously to say the unsaid thing directly. If nobody's role is changing, say that, plainly, early, and without hedging it into meaninglessness. If something is changing, say that too. People handle bad news considerably better than they handle ambiguity, and a team that suspects something is being managed around them will spend more energy on that suspicion than on the tool.

Why asking first changes the politics

The third objection, the one about blame, has a structural answer rather than a reassuring one.

An agent that acts on its own puts the person nearest to it in an uncomfortable position: accountable for output they did not see coming. An agent that proposes, and waits, puts them back in a familiar one: reviewing something and deciding whether it goes. The second is a role people already know how to occupy, and it carries the authority that makes the accountability fair.

This is why the ask-before-acting pattern matters more for adoption than it does for safety, which is not the reason it usually gets discussed. A team will tolerate a tool that occasionally proposes something silly, because catching it is their job and they are good at it. The same team will not forgive a tool that sent something silly on their behalf, and they will be right not to.

The same logic applies to the record. An agent that can show what it looked at and why it concluded what it did lets a person defend a decision they approved. Without that, approving anything is an act of faith, and people are sensibly reluctant to be the one who took it.

Choose the first user carefully

The instinct is to start with whoever is most enthusiastic. This is usually a mistake, because the enthusiast will make it work regardless and therefore proves nothing to anybody.

The person to start with is the one with the most tedious version of the problem. Not the most senior, not the most curious, but whoever currently spends an hour every Monday reconciling something by hand. Their enthusiasm is irrelevant. If the agent genuinely removes that hour, they will tell people, and the sentence that gets repeated in your business will be it saved me the Monday thing rather than we are adopting AI. One of those spreads and the other does not.

There is a second reason to do it this way. A sceptic who is won over is far more persuasive internally than an advocate who was never in doubt, because everyone can see they had nothing to gain by being convinced.

Show the work it removed, not the work it did

Most reporting on this gets pointed in the wrong direction. Dashboards tend to show what the agent processed, which is a number about the tool, and nobody outside the project is interested in it.

What people want to know is what stopped happening to them. The Friday report that nobody now assembles by hand. The message from a client that would have been missed in a group chat and was not. The recurring hour that is simply no longer in the week. These are the only results that alter how the team feels about the thing, because they are the results the team can feel.

It is worth naming these out loud at the point they occur, and naming them as something the team achieved rather than something the software did. A rollout that is framed as the tool's success invites people to be spectators of it.

Where Kritmatta stands on this

We build this into how agents behave rather than treating it as a training problem.

Agents ask before they act, so a person decides anything that carries consequence, and the authority sits where the accountability does. Every action is logged with when it happened, why the agent did it and what data it used, so a decision can be explained after the fact rather than defended on trust. Everything an agent knows is browsable by category, with where it came from and when it was learned, and any single memory or an entire category can be deleted immediately. You choose which data each agent can see and which team members can change its settings, which means access can follow the shape of your team rather than overriding it.

The same thinking runs through how we roll agents out with businesses. The last step of our enablement work is showing the team what the agents do, how to check on them and how to adjust them, on the straightforward principle that a tool nobody can inspect is a tool nobody will trust.

The test is six months out

Any rollout can look successful in week one, when attention is high and the novelty is doing the work.

The question worth asking is what happens after the person who championed it moves on, and whether the agent is still running because it has become genuinely load-bearing or is still running because nobody has got round to turning it off. That outcome is usually decided early, by whether the people expected to use it were told what it meant for them or left to guess.

Resistance is not an obstacle to the rollout. It is information about it, and it is almost always more accurate than the enthusiasm.