The first question every team asks when it sets up an agent is what the agent can do. The better question is what it can do without asking anyone first. Almost every action is fine with a person in the loop. The hard part is deciding where you can take the person out.
Get this wrong in one direction and the agent pings someone for every small step, so nobody saves any time. Get it wrong in the other and it sends an email to a customer that nobody read. Both failures come from the same place: nobody wrote down the rules before switching it on.
Start with the action
It's tempting to think about trust at the level of the agent: "do we trust the support agent?" That question has no useful answer. You trust it to tag a ticket. You probably don't trust it to issue a refund yet.
So list the actions instead. For a support agent, that list might look like this:
- Read a ticket and its history
- Add tags and set a priority
- Draft a reply
- Send a reply to the customer
- Issue a refund
- Close the ticket
Each line gets its own rule. That sounds like more work than one big yes or no, but it's the only version that holds up after the first week.
Sort every action into three buckets
For each action, ask two questions. If this goes wrong, who notices? And how hard is it to undo?
Do it. Nobody outside the team sees the result, and it's easy to reverse. Tagging, sorting, summarising, drafting, updating an internal field. Let the agent do these freely and keep a log.
Do it, then tell us. The result is visible inside the company, or a little harder to undo. Moving a ticket between queues, posting a summary in a team channel, creating a task for someone. The agent acts, and a person sees it soon after.
Ask first. Anything a customer, a partner or the public will see, anything that moves money, and anything you can't take back. Sending an email, issuing a refund, deleting a record, changing a price. The agent prepares the work and waits for a sign-off.
If you can't explain why an action is in the "do it" bucket in one sentence, it belongs in "ask first" for now.
Add thresholds to the categories
Whether some actions are safe depends on their size. A refund of a few dollars on a duplicate charge is routine. A large refund on a disputed order is not.
Set a number. Below it, the agent goes ahead. Above it, a person approves. Pick the number your team already uses when a new hire asks "can I just do this?" You almost certainly have that rule already. It just lives in someone's head.
Move actions up as trust builds
The buckets aren't permanent. After a few weeks of approving every drafted reply for a certain kind of ticket, you'll notice you never change them. That's your signal to move that kind of reply from "ask first" to "do it, then tell us".
Do this on purpose, one action at a time, and write down why. When something does go wrong later, and eventually something will, you'll know exactly which decision to revisit.
Write it where the agent can see it
Rules that live in a meeting note don't help anyone. Put them in the same place the agent reads its instructions: the permissions and approval settings for that agent. Then the rule and the behaviour can't drift apart.
A good test before you switch anything on: hand the list to someone who wasn't in the room. If they can tell you what the agent will do with a refund request, an angry email and a duplicate ticket, the rules are clear enough. If they can't, neither can the agent.