A team trusts a new agent the way it trusts a new colleague: with small jobs first, on evidence, and with the right to check. Handing it the most important process in week one does not speed up trust. It removes the chance to build any.

An owner decides to bring in automation, an MSP builds it, and a team that was not consulted arrives on Monday to find a new thing doing part of their job. Whatever its quality, it starts with a deficit. The people who must use it did not choose it, do not know what it can do and have a reasonable interest in it failing.

Start with a job that is easy to check

The first task given to an agent should be one where a person can see at a glance whether it was done right. Sorting incoming requests into categories. Pulling figures into a weekly summary that the person then reads. Drafting a reply that is edited before it goes.

The test is that the person can verify the result faster than they could have produced it, so each use gives them a small, concrete reason to believe it works. Ten of those in a fortnight is worth more than any amount of reassurance in a meeting.

Let it say what it did

Trust grows when an agent is plain about its own work. What it did, what it could not do and what it was unsure of. A tool that reports everything as a success teaches people to check everything, and a team that checks everything has gained nothing.

This is a design choice more than a personality. abi. is built to say what it did and only what it did, to say what it could not read and what to do instead, and to ask before it spends credits. When she reads a document she says how many processes, systems and handoffs ended up on the map and that they came from the document. People can disagree with that. They can also tell whether it was true, which matters more.

Show the edge

A new colleague earns respect by knowing what they do not know. An agent should too. Tell the team plainly what it will not do, such as scoring individuals, making a final call on a customer or touching anything outside its job, and put those limits where people can see them.

Teams often fear the wrong thing. They worry about being replaced when the real risk is quieter: the agent will do something confident and wrong, and nobody will notice. Stating its limits, and showing a person at each step that matters, answers both.

Keep a person's hand on the wheel

Early on, every consequential step should wait for a person to approve it. That is not a permanent arrangement, and it should be said so. The approval is how the team learns what the agent does, and as its record builds, individual steps can be released. Who releases them, and on what evidence, should be decided by the team, not the vendor.

Releasing control gradually works better than the reverse. Taking approval away from a team that has grown comfortable with it is easy. Adding it back after something has gone wrong is hard, and it means starting trust again from a lower place.

What the consultant can do

An MSP is well placed to run this properly because it can do what the owner cannot. Spend a day with the team before the build. Ask what they would hand over and what they would keep. Choose the first job from their answer, not from the proposal. And report back honestly after a month on what the agent did, what it got wrong and what changed.

The deliverable is not only the workflow. It is a team that has seen an agent behave well in small things and has therefore agreed to let it do larger ones.

One thing to try

Pick the smallest job the agent could do for one person on the team. Let them check every result for two weeks, then ask them one question: would you be sorry if it stopped? The answer is the measure of whether you have built trust or only built a workflow.