AI lands or it doesn't. Culture decides.
The technical work to ship an AI agent is the easier half of the engagement. The harder half is what happens in the team that has to use it. In our work across our four offices, the engagements that compound are the ones where the cultural conditions for adoption were addressed alongside the build. The ones that stall are the ones where the cultural work was treated as a follow-up.
Three cultural conditions that decide adoption.
When we look at AI deployments that landed and AI deployments that did not, in the work we have done across our four offices, three cultural conditions sit underneath almost every successful case. The first is psychological safety to flag bad output. The second is willingness to share the work that the model can learn from. The third is comfort with measured judgement over hero intuition.
Psychological safety to flag bad output sounds obvious until you watch a team in practice. The operator who accepts the agent's first answer without challenge is the operator who has either decided the agent is right enough or decided that flagging it is not worth the friction. Both are bad signals for adoption. The teams that compound are the teams where flagging the output is normal, expected, and rewarded.
Willingness to share work the model can learn from is the second condition. Agents get better when they have access to the patterns the experienced operators have built up. If the operators see the agent as a competitor for their role, they hold their patterns back, the agent fails to improve, and the loop confirms their fear. If they see the agent as a tool they can shape, they share the patterns and the loop reinforces adoption.
Comfort with measured judgement over hero intuition is the third. AI introduces measured judgement to workflows where intuition has been the dominant signal. The teams that struggle with adoption are usually the teams where the most experienced operator built a reputation on intuition and is now being asked to defer to a measured output. The teams that adopt well are usually the teams where intuition and measurement are seen as a pair, not a hierarchy.
Change management has to happen alongside the build.
The most common mistake we see, and we have seen it across industries and offices, is to sequence the change management after the build. The team builds the agent in isolation, ships it to the operating team with a training session, and assumes adoption will follow. Adoption does not follow. The operating team experiences the agent as something done to them, finds the seams that do not match their workflow, and silently routes around it.
The work that produces adoption starts before the first line of code. The operating team is in the design conversation. They define the workflow the agent is meant to support, name the points where their judgement still owns the decision, and identify the cases where the agent's output should be challenged by default. The agent that ships is then a tool the operators have shaped, not a tool imposed on them.
The cost of running change management alongside the build is real. The build takes longer. The conversations are messier. The conversations also produce a different kind of agent, one that lands at launch rather than after a quarter of remediation.
Adoption happens at the operator's desk. The executive sponsor sets the conditions. The operator decides whether the work changes.
How to spot rejection early.
The most common signal of rejection is silent non-use, and it is the signal teams miss most often. The agent ships, usage is high in week one because everyone is curious, drops in week two because the curiosity wears off, and flattens in week three at a baseline well below the design target. The operating team does not complain. They have simply absorbed the agent into their toolset at a level that does not change their workflow.
We watch four metrics in the first six weeks of any deployment to catch the silent non-use pattern. Active user count by week. Average sessions per active user. Acceptance rate on agent suggestions. Time from launch to first user-flagged correction. Each of those four tells a different story, and the combination tells us early whether the deployment is landing.
When the pattern of silent non-use shows up, the first response we recommend is conversation rather than feature work. We sit with three or four operators and ask them what they do instead of using the agent for the cases the agent is meant to handle. The answers are almost always operational rather than technical. The agent's output is good. The operators do not trust it enough yet, or the workflow integration is one click too many, or the agent's confidence display does not match their own sense of confidence.
The operator drives adoption. Not the executive.
Executive sponsorship matters. It sets the conditions for the work, allocates the budget, and signals that the deployment is serious. It does not produce adoption. Adoption happens at the operator's desk, in the moment they choose to use the agent or to bypass it. That choice is influenced by the executive sponsor's tone, but it is decided by the operator's experience of the tool.
The teams we have seen reach durable adoption have invested heavily in identifying the operators who can carry the deployment with their peers. They tend to be early-career enough to engage with the new tool without ego, experienced enough that their peers respect them, and curious enough to push the agent through its edge cases. Two or three operators of this profile, embedded in the design conversation and visible in the rollout, do more for adoption than any town hall the chief executive can run.
Identifying those operators is the work the change management function should be doing in the first month, not the third. The teams that delay this step usually find that the deployment moves through executive comms but never moves through the operating team.
Culture is the feature you cannot license.
The agent vendor cannot ship culture. The consulting firm cannot install it. The platform decision cannot fix it. Culture is the slow work of conversations, rituals, hiring choices and incentive design that builds the conditions for new tools to be adopted, and it has to be done with the team that will own the workflow.
In the engagements we run, the share of effort that goes into the cultural conditions for adoption usually surprises clients who expected a build-heavy programme. The share that goes into the build itself is smaller than the share that goes into the operating team conversations, the literacy work, the workflow redesign and the identification of the operators who will carry the change.
If your organisation is preparing an AI rollout and the cultural work is sitting in a follow-up phase, the move we recommend is to bring it forward. The teams that do this in advance ship deployments that land at launch. The teams that do not ship deployments that need a remediation programme three quarters in. The Consulting and Tech Factory teams in our Paris, Dubai, Singapore and Bali offices are reachable from the brief form below.
Frequently asked questions.
How long does cultural change for AI adoption take?
In our experience, the visible behavioural shift in a team takes three to six months for a well-led deployment. The deeper cultural change, where new operators arriving inherit the new norms, takes a year or more. The teams that try to compress the timeline tend to compress the change-management work, and the deployment slips back.
Can incentives shift the culture?
Incentives matter but they cannot do the work alone. A team incentivised to use the agent without a workflow that supports adoption will produce the usage metric without the value behind it. The incentive design has to sit alongside the workflow redesign, not in place of it.
What if the team actively resists?
Active resistance is rarer and easier to address than silent non-use. The resistant team is telling you what they think is wrong. The silent team is hiding it. When we see resistance, we treat it as a design signal, work with the resistant operators to understand the friction, and most of the time we find a real workflow issue that improves the agent for everyone.
How do you measure cultural adoption?
Through a mix of usage metrics, structured operator interviews, and the qualitative signals that surface in the first three months. The metrics catch the broad pattern, the interviews catch the texture, and the combination tends to tell a clearer story than either alone.
How does this differ across geographies?
The cultural conditions are universal. Their expression varies by region. The teams we work with in our Singapore and Bali offices tend to surface adoption friction more indirectly than the teams in our Paris and Dubai offices, and the change management work has to adjust to that. The underlying conditions are the same.
Where does HR fit?
HR is one of the change management owners, not the only one. The hiring profile for the affected workflow, the literacy expectations defined for managers, and the recognition systems that reward operators who shape the agent are all HR territory. The work succeeds when HR is in the room from the design conversation forward.
Where this lands
How we'd take this further with you.
Consulting pillar
Transformation & Organisation
Operating model design, change management, capability build for what comes next.
Consulting pillar
AI-Augmented Enterprise
From maturity diagnosis to use case prioritisation to durable adoption across the organisation.
Engine
Consulting
Our strategy and transformation practice across four pillars and four offices.
Writing is one thing. Shipping is the other. Selected work from the partners writing here.
See the work