Readiness Score
Agent-Native Readiness Assessment
Score your team across architecture, tooling, evals, operations, and delivery in 15 questions, see your maturity level, and get the three gaps to close first.
Pick the option closest to how things actually are today, not where you plan to be.
0 / 15 answered
Architecture and runtime
How model calls, agent state, and failure paths are structured.
Tools, integration and MCP
How agents reach the systems they act on, and what limits them.
Evals and observability
How you know a change is safe, and what you see when it is not.
Operations, security and governance
Cost control, untrusted input, and who can change what in production.
Team, delivery and coding agents
How the team builds with agents and ships agent features.
About you
Not scored. Used only to pick the most relevant next step.
15 unanswered; unanswered questions are left out of the score.
TL;DR
Answer 15 questions about how your team builds and runs agents today, about four minutes, and get a 0-100 score across five dimensions: architecture and runtime, tools and MCP, evals and observability, operations and governance, and team delivery. The score maps to one of four levels, from Exploring (prompts inline in handlers, nothing measured) to Agent-native (agents as runtime units with evals on production traces). You also get the three dimensions to fix first and a next step matched to your role and team size. Nothing leaves the browser.
The four levels of agent-native maturity
Updated Sep 25, 2026The overall score (0-100) maps to one of four levels. A level is a description of how a team works today, not a grade: most teams shipping agent features in production sit at Piloting or Operating, and the gap between them is mostly evals, tracing, and versioned configuration rather than model choice.
| Level | Score | What it looks like | Typical failure | What unlocks the next level |
|---|---|---|---|---|
| 1 Exploring | 0-29 | Prompts inline in application code, no evals, no per-run tracing, and one or two people who understand how it works. Cost appears on the monthly invoice. | A demo that works in a meeting and breaks on the first real user. | Put model calls behind one interface, log every call with its inputs and outputs, and write down the ten cases the feature must get right. |
| 2 Piloting | 30-54 | A wrapper around the provider SDK, conversation history stored, manual spot checks before releases, prompts and completions logged, a spend dashboard, and a few engineers who use coding agents on their own. | Silent regressions after a prompt or model change that nobody can trace back. | A fixed eval set that runs in CI, a trace per run, a single tool registry, and prompts released through the same review as code. |
| 3 Operating | 55-79 | An orchestration layer with durable run state, a tool registry behind MCP or similar, automated evals in CI, per-run traces, cost per feature, versioned configs with rollback, and shared conventions for coding agents. | Evals drift away from production; permissions and cost limits are policies on paper rather than enforced in the runtime. | Evals sourced from production traces, runtime budgets and scopes, staged rollouts with eval gates, and coding agents that own tickets under CI. |
| 4 Agent-native | 80-100 | Agents with durable, replayable state and per-run budgets, a versioned tool catalogue with policy-enforced permissions, evals on production traces with regression gates, staged rollouts with approval for high-risk agents, and coding agents that take tickets end to end. | Over-engineering: platform work for agents that nobody has shipped yet. | Stay there: review patterns as models change, measure outcomes rather than activity, and retire what stopped earning its keep. |
Per dimension, the same four levels look like this. Use the row for your weakest dimension to see the concrete state to aim for next.
| Dimension | 1 Exploring | 2 Piloting | 3 Operating | 4 Agent-native |
|---|---|---|---|---|
| Architecture and runtime | Prompts inline in handlers; stateless calls | SDK wrapper; history stored, no durable runs | Orchestration layer; versioned prompts; durable runs | Agents as runtime units; replayable state; run budgets |
| Tools, integration and MCP | Hand-written schemas; bespoke glue per integration | Generated schemas; shared HTTP layer; allowlisted writes | Tool registry; MCP servers; scoped writes with dry runs | Versioned tool catalogue; policy-driven permissions; sandboxes |
| Evals and observability | Outputs eyeballed; application logs only | Manual spot checks; prompt logs; feedback button | CI evals; per-run traces; failures triaged into cases | Production-trace evals; regression gates; drift alerts |
| Operations, security and governance | Monthly invoice; injection not considered | Spend dashboard; 'ignore instructions' in the prompt | Cost per feature; versioned configs; injection in evals | Runtime budgets; staged rollouts; red-team runs |
| Team, delivery and coding agents | Autocomplete; one person knows the system | Some agent use; ad-hoc pairing; shipped as experiments | Repo instructions; documented patterns; eval baseline | Agents own tickets under CI gates; everyone ships |
Dimension score = mean of its three answers (0-3) scaled to 0-100. Overall = mean of the dimension scores. Thresholds: Exploring below 30, Piloting 30-54, Operating 55-79, Agent-native 80 and above.
How it works
15 questions across 5 dimensions, 3 per dimension. Each question offers four options describing concrete states of practice, scored 0 to 3. dimensionScore = mean(answers) × 100 / 3; overall = mean(dimensionScores) over dimensions with at least one answer.
Levels are thresholds on the overall score: Exploring < 30, Piloting 30-54, Operating 55-79, Agent-native 80+. The "where to focus" cards are the three lowest-scoring dimensions. The next-step recommendation is picked from the two unscored segment questions (role and team size).
Scoring runs in the browser; answers are kept only in your browser's localStorage. No answer data is sent anywhere.
FAQ
- What does agent-native mean?
- An agent-native team treats agents as first-class parts of the system rather than a prompt bolted onto a request handler: agents have durable state and designed failure paths, tools are defined once and permissioned by policy, changes are gated by evals on production traces, cost and security limits are enforced at runtime, and the team itself uses coding agents under shared conventions. The assessment measures how far a team is along each of those five dimensions.
- Is this for individuals or teams?
- Both, but it is built for teams. An individual engineer can score their own project in about four minutes and get a reading list. For a team, the useful signal is the spread: have three or four people score it independently and compare where they disagree. Engineering leads and teams of six or more are pointed at the team program as the next step; individuals are pointed at the self-serve material.
- How is the score computed?
- Fifteen questions, three per dimension, each answered 0 to 3 where each option describes a concrete state of practice. A dimension score is the mean of its answers scaled to 0-100. The overall score is the mean of the five dimension scores (only dimensions with at least one answer count). Levels are fixed thresholds on the overall score: Exploring below 30, Piloting 30-54, Operating 55-79, Agent-native 80 and above.
- Is my data stored anywhere?
- No. Scoring runs entirely in your browser and nothing is sent to a server. Answers are kept in your browser's localStorage so you can come back to them; the Retake button clears them. The only thing that leaves the page is an anonymous 'tool used' analytics event with no answer data.
- What should a level-2 (Piloting) team do first?
- Get a fixed eval set running in CI and a trace per agent run. Those two changes turn 'we think the last prompt change was fine' into something you can check, and they are prerequisites for everything at level 3: versioned prompts and configs with rollback, per-feature cost attribution, and a single tool registry. Do them before adding more agent features.