Set per issue type, not per platform
A password reset and a safety-critical fault do not belong at the same level, and no global setting is right for both. Autonomy per category is what makes the decision reviewable.
Nobody goes from human-handled to fully automated in one step, and a vendor who suggests you should is telling you something about themselves. This is the same issue handled three ways — suggested, drafted for approval, and resolved end to end — so you can decide where each kind of work sits, and move it when the evidence supports it.
The two common failures are opposites. Turn automation on everywhere and the first confidently wrong answer to an important customer costs more trust than the project saves. Keep everything human and you have bought an expensive suggestion engine.
The real question was never whether to automate. It is which work is safe to automate — and safe is a property of the issue type, the customer it belongs to and what happens if the answer is wrong, which cannot be settled in a workshop.

The levels are the easy part. The handover out of each one is what deserves the scrutiny.
The system proposes and the agent decides. Every suggestion accepted or rejected is evidence about whether that category is ready to move up.
The response is written, with its reasoning and sources attached, and a person releases it.
For issue types where the evidence supports it, the interaction resolves without a person — and stays reviewable afterwards like any other.
Each level has a defined point where it stops and hands to a person with the work attached. This determines how a bad case ends.

You are not deciding how much you trust AI. You are deciding which specific work it handles.
A password reset and a safety-critical fault do not belong at the same level, and no global setting is right for both. Autonomy per category is what makes the decision reviewable.
Anything reaching a customer is approved by a human unless you deliberately decided otherwise for that category. That is the correct default for a system that will sometimes be wrong.
Every accepted suggestion and edited draft says something about whether a category is ready. A level change should follow what happened in your queue, not a projection.

Two of these are too fast, one is too slow, and one is unanswerable.
The first confidently wrong answer to an important customer costs more than the automation saved.
Safe and static. It keeps a person in every loop including the thousands that never needed one.
Forces one answer across password resets and safety-critical faults.
Produces a policy based on what people imagine is in the queue. The queue disagrees.

Worth pinning down, because "autonomous" is used to mean all three of these.
The other half of the picture: what has already been prepared before an agent opens the case.
What the top level looks like across a field service loop rather than a single support case.
How work gets sequenced across agents once more than one of them is involved.
Agent to Agent Workflows
Bring your issue-type breakdown and we will work through which categories are genuine candidates to move up a level, and which ones should stay with a person.
Talk to us