Agent readiness: fix the repos slowing your rollout

A coding agent can finish a change in one repository and spend the next session trying to discover how another repository starts. Buying the same model for both teams does not remove that difference. Agent readiness makes the repository’s contribution to the result visible.

Factory’s Agent Readiness evaluates the structure, validation, and operational signals that support autonomous work. The useful output is a set of gaps an engineering team can fix, rather than a score to put beside its adoption target.

Use agent readiness to choose the first repositories

Start with repositories that receive real engineering work. A quiet demonstration repository can make a pilot look healthy while the systems that matter still require undocumented setup and manual verification.

Run Factory’s readiness report in each candidate repository. The command discovers independently deployable applications, evaluates criteria, and returns recommended actions. In a monorepo, an application-scoped result such as 3/4 means three of the four evaluated applications pass. Inspect the fourth application before treating the repository as uniformly ready.

Factory’s published maturity-level explorer gives the rollout discussion a shared vocabulary. These levels describe engineering foundations and possible workflows, not guarantees that every task is safe to delegate.

The diagram comes from the Agent Readiness launch. Use the current report and documentation for the criteria in your evaluation. Keep authorization separate: a strong readiness result does not grant an agent production credentials or permission to bypass review.

Turn agent readiness findings into reviewed changes

Choose a failing criterion that explains observed friction. If Droid repeatedly guesses the test command, document the command and make it reproducible. If a package lacks a local check, establish that check before measuring how quickly an agent can modify it.

Factory’s /readiness-fix works from the latest stored report to address failing signals. Scope the request to the work you want, review the resulting patch, and run the repository’s validation. Re-run /readiness-report afterward so the next discussion uses evidence from the changed repository.

The readiness dashboard gives platform teams a view across repositories and historical reports. Assign an owner to each remediation rather than asking every team to improve every score at once. Pair readiness changes with practical outcomes such as setup failures, successful validations, and reviewer intervention.

A higher score is useful when it changes what the team can delegate reliably. It should not become a reason to add empty configuration files or tests that do not exercise behavior. Keep the failing workflow beside the criterion so the remediation has an engineering purpose.

For the next cohort, reuse the instructions, environment setup, and checks that worked. Keep repository-specific exceptions explicit. That makes a rollout repeatable without pretending that a service, a library, and a monorepo need identical preparation.

Discuss a pilot with Factory around your active repositories and the outcomes you want to measure.

Further reading

• How to measure agent readiness
• Browse published readiness reports
• Readiness Reports API