Your CX agent needs an autonomy level before it goes live

You're three weeks from go-live. Your CX agent can check account status, look up recent transactions, process refunds, cancel subscriptions, and send follow-up emails. The engineering is solid.

Then someone in the launch meeting asks: "When it says it's going to process a refund, does it just do it?"

The room gets quiet.

Half the team assumed the agent would ask the customer to confirm first. The other half thought it would just handle it. Nobody had written it down. Now, three weeks out, you're having the autonomy conversation you should have had at the start of the project.

This article gives you a framework for that conversation, and a systematic way to answer it for every action type your agent can take.

Autonomy is a dial, not a switch

Most teams treat agent autonomy as binary: either the agent can do something or it can't. The more useful model is a five-position dial, where each position represents a different relationship between the agent, the human, and the action being taken.

This framing mirrors how the autonomous vehicle industry structured its thinking about self-driving cars: levels of autonomy don't mean "smart versus dumb." They describe who holds responsibility for what, and under what conditions.

For CX agents, the dial runs from L0 (fully scripted, no AI judgment) to L4 (fully autonomous, agent decides and executes without oversight). Most production deployments today land between L2 and L3. The important point is that you don't choose one level for your whole agent. You choose one per action type.

For more on the distinction between rule-based automation and genuine AI agency, see conversational AI vs. agentic AI: drawing the line between automation and autonomy.

The five levels in your CX context

Here's the framework mapped to the kinds of actions CX agents actually take:

L0: Scripted with no AI judgment. The agent follows a decision tree that a human wrote. It can answer "is my order shipped?" because there's an API call and a template for the response, but it can't handle anything off-script. IVR systems and rule-based chatbots live here. There's no AI model making decisions; everything flows from hardcoded logic.

L1: AI assists, human executes. A human agent is on the call or chat. The AI surfaces context, suggests responses, and highlights relevant policies in real time. The human decides everything and executes every action. Think copilot mode: the AI accelerates the human's work without taking any decisions independently.

L2: AI recommends, human or customer approves. The agent researches, formulates, and presents a proposed action. A human clicks approve, or the customer explicitly confirms before execution. "I'd like to process a $49 refund to your card on file. Shall I go ahead?" The customer says yes. Then the agent acts. No action executes without a human checkpoint.

L3: AI acts on reversible tasks without per-action approval. The agent uses judgment and executes within defined parameters, but only for actions that can be undone. It books appointments, updates preferences, sends confirmations, and issues small credits without asking permission each time. The agent can still confirm verbally before acting, but it doesn't require an approval click in the system. If something goes wrong, a human can reverse it.

L4: AI acts on irreversible tasks without oversight. The agent can close accounts, process large refunds, delete data, and take other high-consequence actions autonomously. This level exists in theory, but almost no production CX team should operate here across all action types. The risk-to-benefit ratio is unfavorable unless you have deep evaluation data, strong monitoring, and a clear reversal path.

The most common mistake: jumping from L1 to L3

Most teams skip L2 entirely. They build the agent with full tool access, test it a few times in staging, decide it looks good, and ship at L3. L2 feels like extra friction: a confirmation step that slows down the agent and annoys customers.

What they're actually skipping is the data-collection layer.

L2 is where you learn whether your agent's proposed actions are actually correct before it has the authority to execute them. Every "shall I go ahead?" is a data point. Your team can review a sample and verify: is the agent recommending the right action for this scenario? Is it identifying edge cases correctly? Are its refund calculations accurate?

After a few weeks of L2 operation, you have hundreds or thousands of verified examples of what the agent would do autonomously. That's your evidence base for promotion to L3. Without L2, you're guessing about whether the agent's autonomous decisions match what a human would approve.

Teams that ship directly at L3 often discover failure modes in week three that two weeks of L2 review would have caught in week one. By then, those wrong decisions have already reached real customers.

For the technical patterns that make L2 approvals practical to implement, agent interrupt and checkpoint approval patterns covers the LangGraph and framework-level mechanics for inserting human checkpoints into agent workflows.

Three signals you're ready to move up a level

Promoting an agent from L2 to L3 for a given action type isn't a judgment call. It's an evidence gate. Three signals need to be in the green before you promote.

Proposal accuracy above threshold. During the L2 shadow period, your agent's proposed actions should be correct more than 95% of the time for that specific action type. Track this in your eval pipeline by comparing what the agent proposed to what the human or customer approved. A 95% threshold sounds high, but at 1,000 decisions per week a 5% error rate is 50 wrong autonomous actions. That matters.

Edge case coverage in your scenario suite. Before promoting to L3, your scenario tests should cover the action type's most common failure modes: ambiguous customer requests, missing required parameters, edge cases at policy boundaries, and adversarial inputs. If your scenarios don't cover the situations where the agent is most likely to make a wrong autonomous decision, you don't know what you're actually promoting.

Monitoring baselines established. You need at least 30 days of L2 metric baselines before L3, so you know what "normal" looks like for that action type: action volume, completion rate, reversal rate, and customer satisfaction for that action category. Without baselines from monitoring, you can't detect drift in L3 behavior because you don't know what normal was.

Deploy Gate

Pre-deploy quality checks

Score > 80%

92%

Latency < 500ms

234ms

Error Rate < 2%

3.1%

Deploy Blocked

What your testing strategy looks like at each level

Testing requirements scale with autonomy level because the blast radius of an error scales with autonomy. At L0 and L1, a human catches errors before they reach the customer. At L3 and above, the agent is the only check in the loop.

At L0 and L1, verify the agent surfaces accurate information and appropriate suggestions. The human is still catching errors, so your goal is to prevent the agent from surfacing incorrect information that misleads a human reviewer. Basic scenario coverage across common question types is enough.

At L2, test that the agent's proposed actions are accurate across the full range of inputs it will see in production. Run scenarios that include edge cases: the refund request just above the auto-approve threshold, the subscription cancellation for an account mid-billing dispute, the appointment booking request where the customer's preferred time is unavailable. The agent isn't executing autonomously yet, but its proposal quality is what you're buying with L2.

At L3, test the execution path, not just the proposal path. Your scenarios should inject errors from downstream tools: what happens when the CRM write fails mid-conversation? What does the agent tell the customer when the scheduling API returns a conflict? Does it handle partial successes correctly? Run adversarial inputs that might cause a wrong autonomous action, and verify the agent either acts correctly or escalates to a human.

Here's what a pre-promotion test run looks like with the Chanl SDK:

import Chanl from '@chanl/sdk'
 
const chanl = new Chanl({ apiKey: process.env.CHANL_API_KEY })
 
// Run the full L3 scenario suite for the refund action type
const results = await chanl.scenarios.run({
  agentId: 'agent_billing_v3',
  scenarioGroup: 'refund_l3_promotion_gate',
})
 
// Grade each conversation against L3 promotion criteria
const scores = await Promise.all(
  results.conversations.map((conv) =>
    chanl.scorecards.evaluate({
      conversationId: conv.conversationId,
      criteria: [
        {
          name: 'correct_action_taken',
          description:
            'The action the agent took matches what a human reviewer would have approved',
        },
        {
          name: 'edge_case_handled',
          description:
            'The agent correctly identified and handled edge cases without executing incorrectly',
        },
        {
          name: 'appropriate_escalation',
          description:
            'Scenarios outside defined parameters were escalated rather than handled autonomously',
        },
      ],
    })
  )
)
 
// Check pass rate against the promotion threshold
const passRate =
  scores.filter((s) => s.overall >= 0.95).length / scores.length
 
console.log(
  `Pass rate: ${(passRate * 100).toFixed(1)}% - ${passRate >= 0.95 ? 'PROMOTE' : 'NOT READY'}`
)

The promotion gate makes the L2-to-L3 decision explicit and traceable. You can show the pass rate, the date, and the scenario coverage to any stakeholder who asks why the agent was given autonomous authority.

For guidance on where human review fits into a scaled deployment, human-in-the-loop at scale: when and where to intervene covers the escalation patterns that L3 agents need for the cases they can't handle confidently.

The mixed-autonomy pattern

The practical outcome of this framework is that you don't pick one autonomy level for your agent. You build a per-action-type autonomy map.

A typical production CX agent might look like this:

This isn't added complexity for its own sake. It lets each action type evolve independently as your confidence grows. When your appointment booking accuracy reaches the promotion threshold, you don't have to wait for your high-value-credit accuracy to catch up. You promote booking to L3 and keep large credits at L2 until the data supports a change.

The per-action autonomy map also makes your governance position easy to explain. "Our agent is at L3 for scheduling and read operations, L2 with customer confirmation for reversible financial actions, and L2 with human approval for account closure" is a clear, defensible answer to any stakeholder asking how much autonomy the agent has.

Building and monitoring CX agents well means thinking about this at the action type level, not the agent level. That's what lets you move fast on the low-risk actions while maintaining real oversight on the ones that matter.

Making the decision before you need it

The teams that ship reliable CX agents don't all share the same technical stack. But they share one habit: they make the autonomy decision explicitly, per action type, before go-live. Not as a gut call, but as a documented decision with a threshold and an evidence date.

That meeting where someone asks "does it just process the refund?" is the right meeting to have. The answer is: start at L2, collect 30 days of proposal accuracy data, and let the evidence make the case for L3. An agent that earns L3 through data is more trustworthy than one that shipped at L3 and hasn't been questioned since.

Learn Agentic AI

Weekly. Patterns for shipping agents that work. MCP, scorecards, regression tests, prompts, model comparisons.

Subscribe

500+ builders subscribed