Adoption is part of agent reliability

An agent completes 92% of evaluation cases. In live work, half the intended users avoid it, experienced staff silently redo its outputs and new staff accept every recommendation. Is the agent reliable?

Not as an operating workflow. Technical performance describes what the system can do under evaluated conditions. Reliability describes whether the combined human and technical system produces acceptable outcomes repeatedly. Adoption determines which cases enter that system, how outputs are interpreted and whether controls function under real workload.

Treating adoption as communications after launch leaves a blind spot in assurance. It should be designed, tested and monitored alongside model, tool and workflow behaviour.

Replace adoption rate with adoption quality

An active-user count cannot distinguish useful reliance from coerced use, curiosity or accidental clicks. Measure several behaviours:

• reach: which eligible people and cases encounter the agent;
• appropriate use: whether the agent is used for intended cases;
• reliance: whether people accept, revise or reject its outputs;
• challenge: whether weak or unsupported outputs are detected;
• escalation: whether uncertain and exceptional cases reach the right person;
• workaround: whether people maintain parallel or hidden processes;
• persistence: whether useful behaviour continues after launch support recedes; and
• outcome: whether the combined workflow improves the intended result.

Segment by role, experience, case type and consequence. An average can hide that experts use the agent selectively while less-experienced staff over-rely, or that normal cases improve while exceptions deteriorate.

NIST notes that human–AI interaction outcomes vary and that role design, context, information presentation and cognitive bias all matter (Human–AI Interaction). Adoption evidence should therefore test the actual configuration, not presume that adding a reviewer creates effective oversight.

Define the intended reliance pattern

Before rollout, specify what people should do in representative conditions.

Condition	Intended human response
Complete evidence, low-consequence case, checks pass	proceed through normal review
Missing or conflicting evidence	inspect sources and request resolution
Action outside delegated authority	refuse or escalate
Agent expresses uncertainty	apply named review route
User knows material contrary information	challenge and record correction
Tool or source is unavailable	use approved fallback or stop
Possible external effect is ambiguous	reconcile state before retry

This makes adoption testable. It also prevents a contradiction common in rollout messaging: leaders promote universal use while control owners expect selective reliance.

The intended pattern should include non-use. A reliable service makes it easy to recognise excluded cases and move them into a safe path.

Observe work, not only surveys

Ask users what helps and frustrates them, but combine their accounts with workflow evidence:

• sampled sessions and case traces;
• review edits and evidence opened;
• overrides and their reasons;
• escalation destinations and resolution;
• duplicate entry or parallel spreadsheet use;
• cases started but completed outside the system;
• queue movement and downstream correction;
• support requests and repeated confusion; and
• outcomes before and after introduction.

A person may report that the agent saves time while still performing unrecorded checks. Another may say they dislike it but use it safely and effectively. The goal is not sentiment management; it is understanding the operating behaviour that produces outcomes.

Use privacy-respecting telemetry and be transparent about what is observed. Adoption monitoring should not become covert worker surveillance.

Treat workarounds as diagnostic evidence

People route around systems when the official path conflicts with getting work done. A workaround may expose poor usability, slow review, missing authority, incomplete data, misaligned incentives or an important exception the design omitted.

Classify rather than punish it:

1. What goal was the person trying to achieve?
2. Which official step blocked that goal?
3. Did the workaround introduce risk or preserve a necessary control?
4. Is it isolated, role-specific or systemic?
5. Should the workflow, policy, training or tool change?

If people copy agent output into an unapproved tool because the handoff queue takes two days, more awareness training will not solve the reliability problem. The operating design must address the queue and provide a safe route.

Design participation before training

Involve the people who perform, receive and are affected by the work while defining the workflow, evaluation cases and rollout. They know exception paths, informal coordination and consequences that process documents miss.

OECD survey findings associate worker consultation with better perceived usability, risk mitigation, engagement and acceptance, while noting that implementation can change work organisation and training needs (OECD). ILO case studies similarly show worker representatives shaping workplace AI decisions across sectors and regions (ILO). These sources do not imply that consultation guarantees success. They support treating workforce voice as design evidence rather than a launch announcement audience.

Training should then be role-specific and practical. Use cases where the agent is right, wrong, uncertain, unauthorised and unavailable. Test whether users can identify evidence, challenge an output, route an exception and recover the task.

Make the interface support calibrated reliance

Users need more than a confidence label. Show the information necessary for the next decision:

• what the agent understood the task to be;
• sources and their freshness;
• material assumptions and missing inputs;
• proposed actions and expected effects;
• policy checks and permissions;
• uncertainty that changes the route; and
• a clear way to correct, refuse, escalate or stop.

Avoid interfaces that make approval the fastest path and review the costly path. If the agent produces a long polished answer but hides contradictory evidence, it encourages superficial acceptance.

The UK Department for Education’s service guidance emphasizes user research, whole journeys, support routes and performance evidence across delivery phases. Apply the same service-design standard to the human–agent interaction, including offline and failure routes.

Add adoption cases to the evaluation suite

Technical test cases should be paired with human-use exercises:

• Can a reviewer find the evidence for a material claim?
• Do users notice when the case is outside scope?
• Can an operator distinguish not attempted from possibly committed?
• Does workload cause approval quality to decline?
• Do incentives encourage users to suppress escalations?
• Can affected users obtain correction or human review?
• What happens when the agent is unavailable?

Measure the joint result. A highly accurate recommendation that reviewers cannot interrogate may be less reliable than a slightly less capable system that communicates evidence and uncertainty well.

NIST’s core framework calls for operator proficiency, defined human oversight, stakeholder feedback and monitoring throughout the lifecycle (AI RMF Core). Adoption evaluation operationalizes those expectations.

Govern rollout as a reliability expansion

Expand by evidence, not enthusiasm. Widen one dimension at a time: users, case variety, volume, data or action authority. At each step, monitor both technical and adoption indicators. Establish thresholds that trigger pause or scope reduction, such as unresolved escalations, rising downstream correction, high review latency or prohibited workaround patterns.

Do not define success as making the old process disappear immediately. A controlled fallback may be necessary while evidence builds. But name its owner and retirement conditions so it does not become an invisible parallel system.

An agent is adopted well when people understand its role, can challenge it, use it for suitable work and reach safe alternatives when conditions change. Those behaviours are not softer complements to reliability. They are part of what reliable operation means.