Measuring AI Readiness: Beyond Tool Adoption
Counting which AI tools a team has installed is not a measure of readiness. We propose a behaviour-based assessment grounded in observed work, and report what it surfaces that survey-based measures miss.
Abstract
AI readiness is commonly measured by tool adoption: which models are licensed, which integrations are turned on, how many seats are issued. These metrics correlate weakly with whether the organisation produces better outcomes with AI. We describe a behaviour-based readiness assessment that scores teams on how they decompose work for agents, how they design feedback loops, and how they handle disagreement between human and model. The instrument is short, repeatable, and yields a different ranking than tool-adoption surveys.
Why tool adoption is the wrong proxy
Adoption tells you what was bought, not what is used or what works. Two teams with identical tool stacks routinely produce very different outcomes, and the difference is rarely about the tools.
The four behavioural dimensions
- 01Decomposition: does the team factor work into units an agent can actually finish?
- 02Feedback: how short is the loop between an agent's output and a verifiable signal?
- 03Disagreement: when a human and a model disagree, what happens, and how is it recorded?
- 04Iteration: do prompts, skills, and evaluations get versioned, or are they rewritten from scratch each time?
What this surfaces
- 01High-tool, low-readiness teams: lots of seats, no compound learning.
- 02Low-tool, high-readiness teams: a small surface area but tight loops, often outperforming their better-resourced peers.
- 03Stuck-in-pilot teams: the readiness score plateaus when feedback loops never close.
Limits
A short instrument cannot replace working with a team. The score is a starting conversation, not a verdict, and it does not currently account for domain-specific constraints (regulated industries, safety-critical work).
- Cite this note
- Versalist Research (2026). Measuring AI Readiness: Beyond Tool Adoption.
- Publication record
- Published February 18, 2026
More from the research notebook
Inspectable Scores: What a Trace Is and Is Not
An inspectable score needs evidence. This note defines trace metadata and the payloads that trace rows do not duplicate.
Read note →Inspectable EvaluationEvaluation Generation as a Post-Selection Step
Most generated challenges never ship, and evaluations written for them are wasted work, so the pipeline defers evaluation generation until promotion. What that buys, what regenerate-not-edit means in practice, and what the generated module is not.
Read note →Skills as Accuracy PrimitivesSkills as Accuracy Primitives
On Versalist, a skill is a named and versioned instruction bundle. Clients can record observations, and proposed changes use recorded history for scored comparisons.
Read note →