The technical plan for your AI agent may be solid. The vendor is chosen, the pilot is scoped, the contract is reviewed. Yet many launches stumble on something simpler: the people whose work changes learned about it from a rumour, a calendar invite or a line in a slide deck. By the time the manager explains, the story has already been told, and it is rarely a kind one.
This article is for the manager who owns the launch and has to talk to the team. It does not replace the work on staged rollout or the human approval and audit trail. It covers the human side that those plans assume is already handled.
1. Speak first, and speak before the pilot
People notice change early. A new tool in the shared drive, a vendor on a call, questions about how long a task takes: staff read these signals and fill the gaps themselves. If the first official message arrives after the pilot has started, you are correcting a story instead of telling one.
A good moment is as soon as the decision to try an agent is made, even if many details are open. Say what you know, say what you do not know yet and say when you will update them. A short message that is honest about uncertainty builds more trust than a polished announcement that answers everything and later turns out to be wrong.
2. Answer the questions people really have
Most concerns fall into a few groups. Name them in your own words before someone has to ask.
- "Is my job at risk?" This is the question behind all the others. If you can truthfully say that the agent is meant to take over repetitive work and that no job reductions are planned, say it, and write it down. If you cannot say that, do not pretend. Tell people what the goal is, who decides and how they will be informed. An evasive answer is worse than a hard one.
- "What will I be doing instead?" Describe the change in concrete tasks. For example, a support team might stop sorting incoming tickets and spend that time on complex cases, while still checking the agent's drafts. Show the before and after of one ordinary day.
- "Will I be monitored or judged by it?" If the agent logs activity, explain what is logged, who can see it and what it is used for. Keep the audit trail of the agent separate from the performance review of people, and say so.
- "What if it makes a mistake and I am blamed?" Decide in advance who is accountable for the agent's output and communicate it. Staff who review the agent's work need to know that catching an error is the job, not a sign of failure.
- "Will I need skills I do not have?" Offer training before launch, not after the first problem.
3. Be precise about what is changing
Vague language such as "AI will support you" invites suspicion. Use a simple table in the team meeting or a one-page note:
- Tasks the agent will do on its own, within limits.
- Tasks the agent will prepare and a person will approve.
- Tasks that stay entirely with people.
- What happens to the time that is freed: more complex cases, quality checks, training, a shorter backlog.
This is the same boundary that your runbook and handover will later record for operations. Writing it once for staff and once for operations, from the same source, keeps the two consistent.
4. Do not promise what you cannot control
Leaders are tempted to reassure with absolutes: "nobody will lose their job", "it will make everything easier". If circumstances change, those sentences become broken promises and cost you credibility for the next change. Promise what you control, such as training, a review of the pilot results with the team and a clear route for feedback. Describe the rest as intentions and say what would change them.
5. Let the people who do the work shape the pilot
The employees who run the process every day know where it breaks, which exceptions matter and which customers need a human. Invite two or three of them to help choose the pilot tasks, to test the agent in shadow mode and to say what the agent got wrong. This does two things: your pilot improves, and the team sees that the agent is something they influence rather than something done to them.
Research on organisational change points the same way. The Prosci ADKAR model describes change as moving through awareness, desire, knowledge, ability and reinforcement (Prosci). Most of what is described above is awareness and desire: people understand why the change is happening and have a reason to take part. Training covers knowledge and ability, and reinforcement is what you do after launch. For a broader look at adoption, see change management for technology adoption.
6. Train for the new role
Working with an agent is a different skill from doing the task by hand. Staff need to learn how to read the agent's output critically, when to override it, how to report a wrong answer and what the agent is not allowed to do. In the EU, the AI Act also expects organisations to make sure that people who operate AI systems have a sufficient level of AI literacy (Article 4). Plan a short practical session with real examples from your own process, and repeat it when the agent changes.
7. Check the formal duties for informing staff
In some cases informing staff is not only good practice but an obligation. For high-risk AI systems used at the workplace, the EU AI Act says that employers who deploy them must inform workers' representatives and the affected workers before putting the system into service (Article 26). National labour law and works council rules may add further requirements. Ask your legal or HR team early whether your use case triggers any of this, and treat the formal notice as the minimum, not the whole conversation.
8. Keep listening after launch
Trust is built in the first weeks of real use. Hold a short check-in after the first week and the first month. Ask what the agent does well, what it gets wrong and what has become harder. Give people a simple place to report problems, respond visibly and publish what changed as a result. When the agent makes a mistake, treat it as a process issue to fix, not a reason to blame the person who noticed it. The NIST AI Risk Management Framework describes the same idea as governance and monitoring that involve the people affected (NIST).
A short checklist
- Have we told the team before the pilot starts, including what is still undecided?
- Have we answered the questions about jobs, new tasks, monitoring, blame and skills?
- Is there a one-page description of what the agent does, what people approve and what stays with people?
- Did we promise only what we control?
- Are two or three people from the team involved in the pilot?
- Is training planned before launch, and have we checked the formal information duties with legal or HR?
- Is there a check-in after one week and one month, and a visible way to report problems?
An AI agent only works well when the people around it use it, check it and tell you when it is wrong. That depends less on the technology than on whether the team believes you were honest with them from the start.
