Telling Staff an Agent Is Doing Part of Their Job Without Losing Them

The moment your team learns an agent is doing part of their job, they are asking one question and it is not about the technology. They want to know whether they still have work next year. Telling staff an agent is doing part of their job goes badly when you answer every question except that one.

Say the honest thing first, in plain words, before you explain anything about how the system works. If the honest thing is that no roles are changing, say so and say who decided. If you do not know yet, say that instead. What you cannot do is skip it.

The order matters more than the wording

People stop listening after the first thing that worries them. So the order of your announcement decides what they hear.

• What is changing, in one sentence, with the specific task named
• What it means for their job, stated as plainly as you can manage
• Who reviews and approves the agent's output, by name or by role
• What you want from them in the first two weeks
• Where to raise a problem, and who reads it

Notice that how the technology works comes last or not at all. A demo before the job security answer reads as a distraction, because it is one.

The promises not to make

The temptation is to reassure. Resist the versions of reassurance you cannot keep.

Do not promise that nobody's role will ever change. You do not control next year's budget and everyone knows it. A promise that gets broken costs more trust than the original worry.

Do not promise the agent will only ever do the boring parts. Task boundaries move. If it turns out to be good at something people enjoy doing, that conversation will happen and your earlier promise will be quoted back to you.

Do not promise it will save a specific amount of time. You do not know yet. Saying you will measure it and share the result is stronger than any figure you invent.

Do not promise that it will not make mistakes. It will. What you can promise is that a person approves output before it ships, which is how systems like SicherOne are built, and that mistakes get logged rather than buried.

What you can promise

There is plenty you can say and keep.

• Who is accountable for the agent's output, named
• That people will be told before the agent's scope grows
• That raising a bad output will never be treated as complaining
• That you will share what the trial found, including if it went badly
• That nobody is expected to pretend the agent wrote something they wrote, or the reverse

The first fortnight

Reactions follow a rough pattern. The first few days are quiet, because people are working out whether to say anything. Around the end of the first week, the first real complaints arrive, usually about a specific bad output rather than the idea. That is the useful moment. How you handle the first complaint sets whether you hear about the next twenty.

Take it seriously, in public, quickly. Fix it or say why you cannot. If the fix is to stop using the agent for that task, do that and say so. Withdrawing one use case builds far more confidence than defending it.

Watch also for the opposite failure. Some people will over trust the output immediately because checking is tedious. That is quieter and more dangerous than complaining. Ask reviewers what they rejected this week. If the answer is nothing, they are not reviewing, which is why it pays to spend time training a team to reject agent output well.

Give people a role in it

The strongest thing you can do is make the team the source of quality rather than the object of the change.

Ask the people who do the work which parts they would hand over and which they would not. Their answers are usually better than a manager's guess, because they know which parts are tedious and which parts carry the judgement. Let them define what a good output looks like for their own workflow. Whether that gets written up as a prompt library or a plain procedure is a choice worth making early.

If somebody's job genuinely does change, have that conversation individually and before the group announcement, not after. Finding out in a team meeting that your work has been reassigned is the thing people remember for years. The same care applies to whoever joins next, starting a new role alongside an agent that already knows the job.

What good looks like after a month

You will know it went well if three things are true. People report bad outputs without being chased. Nobody has quietly stopped using it while pretending otherwise. And at least one person has suggested a new task for the agent themselves.

If instead the team has gone quiet and usage is falling, the problem is not the model. Somebody did not believe an answer they were given in week one, and nobody has asked them why.