The question “should we let the agent run on its own?” has no answer as asked, because it is a request for a prediction. Rephrase it as “what evidence would convince us?” and it becomes a measurable process with four stages and a defined exit at each one.
The process below assumes the action category is eligible in the first place. Some categories never are, regardless of how good the numbers look, and those are set out in which business actions an AI agent should never perform unchecked.
Stage 1: shadow mode, where nothing is executed
Shadow mode is running the agent on real cases while recording its proposals and executing none of them. Humans continue to handle the same cases as though the agent were not there, which is the point: you are generating paired data, one agent decision and one human decision per case.
Two properties make shadow mode worth the effort rather than theatre.
The proposal must be recorded with its parameters, not just its intent. “Would have sent an email” is not comparable to a human decision. “Would have sent this email, to this recipient, with this amount” is. In Oneop, suggest mode writes nothing to your workspace but still records the proposed action and its full parameters on the run trace, so the comparison is available after the fact rather than requiring a re-run.
The humans must not see the proposals. The moment a reviewer sees what the agent suggested, your measurement is contaminated by anchoring, and agreement rate stops meaning anything. Run the comparison offline.
Cover one full cycle of variation in the work before moving on. Weekly rhythm, monthly close, seasonal peak, whichever shape applies. And do not exclude the messy cases; they are the entire reason you are measuring.
Stage 2: agreement rate, and the three ways it lies
Agreement rate is the proportion of paired cases where the agent proposed what the human decided. It is the right headline metric and it is easy to compute wrong.
| Failure | What it looks like | The fix |
|---|---|---|
| Aggregate blindness | 94% overall, driven entirely by a large easy category | Segment by case type before reading the number |
| Counting near-misses as hits | Agent proposed a correct action with a wrong parameter | Score parameters, not just action type |
| Human baseline treated as truth | Agent disagreed and was right | Review disagreements individually; some are agent wins |
That third row is not a rhetorical hedge. Reviewing disagreements is where the real value of shadow mode lives, because a disagreement is either a defect in the agent or a defect in a human process, and both are findings you wanted.
Track one secondary metric alongside agreement: the distribution of how the agent’s runs ended. Runs that never produced a proposal at all (they hit a ceiling, looped, or the tool failed) are not agreements or disagreements, and a high rate of them is a reliability signal that agreement rate cannot see. Instrumenting that is the subject of AI agent observability.
Stage 3: narrow the scope to what earned it
This is the stage teams skip, and skipping it is the single most common cause of a failed rollout.
Agreement is never uniform. Segment your paired data and you will typically find one or two case types where the agent matched humans almost perfectly, and a long tail where it did not. Promoting the agent wholesale takes the average into production, which means the tail runs unchecked.
So promote the segment, not the agent. Narrowing takes three forms, and the first is strongest:
- Narrow the tool set. Remove write tools the agent did not need in the segment that earned promotion. A tool it does not hold is refused rather than improvised, which is a stronger boundary than an instruction.
- Narrow the input scope. Route only the qualifying case type to the autonomous agent and leave everything else on the approve-mode instance.
- Narrow the bound. Lower the action ceiling for the autonomous configuration. If the segment needs one write per run, do not leave three available.
In Oneop the tool boundary is the concrete version of this: eleven of the twenty available agent tools only read, analyse or draft, and nine can write. An agent granted invoice reads and no invoice writes cannot change an invoice whatever it concludes, because every write in the product passes through one governed dispatch function. The AI agents page sets out the catalogue and the split.
Stage 4: promotion criteria and the rollback trigger
Write both down before launch. Criteria decided after seeing the data are not criteria.
A promotion record should state, in one paragraph each: the segment being promoted, the agreement rate measured on that segment and over what period, the action ceiling and tool set in the autonomous configuration, the rollback trigger, and the named person who owns the decision.
The rollback trigger is the part most teams leave vague, and vagueness is what turns a bad week into a bad quarter. Make it a rate or an event, never a judgment:
- Escalation rate on the promoted segment above a level you set now.
- Any single occurrence of a named category: one wrong outbound send, one wrong amount.
- Volume anomaly in either direction, because an agent doing twice as much as usual is as suspicious as one doing nothing.
And make the rollback cheap to execute. In Oneop, autonomy is stored on the agent rather than passed in when a run starts, so reverting to approve is one deliberate edit to the agent and it applies to every subsequent run — no deployment, no code change, no ticket. That property matters more than it sounds: a rollback that requires engineering does not get pulled at 6pm on a Friday, which is precisely when it is needed.
The failure case: the triage agent that was promoted on a quiet month
A support team runs a ticket-triage agent in approve mode through August. Agreement rate comes back high, reviewers report the queue is boring, and the agent is promoted to autonomous across all ticket types at the start of September.
Two weeks later a product release ships, and the ticket mix changes completely. A category that barely existed in August is now a quarter of the volume — and the agent had almost no August examples of it, so the high agreement rate said nothing about it either way. The agent routes them confidently and wrongly, tickets sit in the wrong queue, and the first anyone notices is a spike in time-to-first-response three days later.
Nothing malfunctioned. The model did not degrade. The measurement was correct and the inference from it was wrong: agreement rate on August’s distribution was never a prediction about September’s, and no one had written down that promotion was scoped to the categories actually measured.
Two controls would have caught it. Scope narrowing, so unmeasured categories stayed at approve by default rather than inheriting autonomy. And a volume-shape alert, since a category going from one percent to twenty-five percent is visible days before its consequences are.
What autonomy does and does not mean
One clarification worth making explicitly, because the word oversells itself in most products. Autonomy describes what happens after the agent proposes an action: whether an approver stands between the proposal and the write.
Whether the agent starts is a separate mechanism. In Oneop they are genuinely separate, and it is worth knowing before you plan around it: an agent run is started by a person. There is no scheduler behind it and no record event that fires it, so an autonomous Oneop agent is unattended by an approver, not unattended by you. If you need something that starts by itself when a deal closes or a ticket goes quiet, that is the automation engine, which has real event triggers.
The other thing autonomy cannot override is a category lock. Money and stock actions in Oneop are refused at the dispatch point regardless of autonomy mode and regardless of a human approval, until that class is separately switched on — the check sits underneath the approval rather than beside it. Which controls are absolute and which are configurable is documented on AI governance.
The position
The stage most teams want to skip is the one that pays for itself: narrowing. Running an agent autonomously on the sixty percent of cases where it demonstrably matches your people, while the rest stays queued, is a better outcome than full autonomy plus a weekly incident — and it is also the configuration you can defend when someone asks why the agent was trusted with a particular decision. The three-position model underneath all of this is set out in autonomy levels, and the input-side controls that remain in force at every stage are in AI agent guardrails.