How to measure agent readiness

May 27, 2026 - 2 minute read

Agent readiness measures how well a codebase supports autonomous coding agents. A repository with clear structure, good tests, and documented conventions lets an agent plan and verify its own work; a repository without them forces the agent to guess. Measuring readiness turns that quality into a score you can track and improve, rather than a vague sense that some repos work better with agents than others.

Factory exposes agent readiness across three surfaces: a report you run in the Droid CLI, a dashboard in the Factory app, and an API. This guide covers how to measure readiness with each, and how they fit together.

What agent readiness measures

Factory's Agent Readiness Model scores the signals that let an agent work autonomously in a repository. These include whether the project explains itself to an agent, whether there are tests an agent can run to verify a change, and whether conventions are written down rather than assumed. The output is a score with the specific signals that raised or lowered it, so the result is actionable rather than a single opaque number.

The point of a score is comparison over time and across repositories. A team can see which services are ready for autonomous work and which need investment before agents will be productive there. For the underlying practices that move the score, see making your codebase AI-agent ready.

Run a readiness report in the CLI

The fastest way to measure a single repository is the /readiness-report command in an interactive Droid session. It evaluates the repository you are in and returns the score with the signals behind it. The readiness report command documentation covers what it checks and how to read the output.

When the report flags gaps, /readiness-fix works through the failing signals from the latest report and proposes changes to address them, such as adding an AGENTS.md, filling in missing test scaffolding, or documenting a convention. That closes the loop between measuring readiness and improving it in the same session.

Track readiness across the organization

A single report is useful for one repository, but platform teams need the trend across many. The readiness dashboard in the Factory app aggregates scores so you can see readiness by repository and watch it move as teams invest in the signals that matter.

The dashboard is where readiness becomes a program rather than a one-time check. It shows which repositories are ready for higher autonomy levels and which are holding back an agent rollout, which lets you sequence the work instead of treating every repository the same.

Measure readiness programmatically

To fold readiness into existing pipelines and reporting, use the Readiness Reports API. It gives programmatic access to reports so you can pull scores into your own dashboards, gate changes on a readiness threshold, or schedule regular checks without a person running the CLI each time.

An API-driven check is what lets readiness scale past a manual audit. A CI job can request a report on a schedule, store the score, and alert when a repository regresses, so readiness is monitored continuously rather than measured once and forgotten.

Turn the score into a plan

Measurement is only useful if it drives action. A practical loop is to run /readiness-report on a repository, apply the highest-impact fixes surfaced by /readiness-fix, and then re-run the report to confirm the score moved. Across an organization, use the dashboard to pick the repositories where readiness is blocking autonomous work, and use the API to keep scores current as code changes.

Higher readiness maps directly to how much you can delegate. Repositories that score well support higher autonomy levels and longer-running work, because the agent can verify its own changes against tests and conventions rather than waiting on a human to catch mistakes.