# Agent readiness > Whether a product can be found, understood and correctly integrated by a coding agent without a person filling the gaps. A checklist, not a score. Source: https://armature.tech/library/agent-readiness Published: 2026-09-03 Publisher: Armature, Inc. (https://armature.tech) --- > **Agent readiness** is whether a product can be found, understood and correctly integrated by a coding agent with no person filling in the gaps. ## Readiness against discoverability These get used interchangeably and they are different things. | | Agent readiness | Agent discoverability | | --- | --- | --- | | Question | Can an agent use us correctly? | Does an agent choose us? | | Scope | Your own product and documentation | The whole market | | Control | Entirely yours | Mostly outside your control | | Cost to fix | Days | Quarters | | Measured by | Checks plus a few agent runs | Install share across hundreds of sessions | Readiness is a precondition. A product that is chosen and then fails at the integration step loses the session anyway, and that loss looks identical in the numbers to never being considered. ## The four layers **Reachable.** The content exists in the HTML source rather than being injected by JavaScript. AI crawlers are allowed by name in `robots.txt`. Nothing important sits behind a login or a form. A Markdown version exists. **Correct.** The quickstart runs when pasted into an empty project. The current version is stated on the page in the text. Every environment variable is named where it is used. Examples are complete files, tested in continuous integration. **Consistent.** The product name, package name, import name, CLI command and page headings are the same string, or the mapping is written down. No similarly named package is going to be installed instead. **Complete.** A full configuration reference with defaults and ranges. Limits published as numbers. Pricing explained in units. Error messages published verbatim with causes and fixes. Pages written in symptom language, not only category language. ## The order that pays The [documentation audit](/library/audit-your-docs-for-coding-agents) has twenty checks. The first six matter more than the other fourteen combined: 1. Is the content in the HTML source? 2. Are AI crawlers allowed? 3. Is there a Markdown twin? 4. Does `llms.txt` exist? 5. Is anything important gated? 6. Does the quickstart run when pasted? Most teams fail at least two of those, and number six is the most common failure of all. ## Why readiness is the cheapest work available Everything else in agent discoverability is slow. Templates take months. Framework integrations take quarters. Training data takes years. Readiness takes an afternoon per item and it is the last step of every session you nearly won. An agent that cannot make your example work does not file a bug. It picks the next candidate. ## How to actually test it The checks are testable with `curl`, a browser and an empty project. What the checks cannot tell you is where sessions stall. For that, take a repository that looks like your users' projects, give an agent a one-line request your product answers, and watch. Five runs, not one. The same agent on the same repository disagrees with itself about a quarter of the time. ## Common questions ### What is agent readiness? Whether a product can be found, understood and correctly integrated by a coding agent with no person filling in the gaps. It covers reachability, documentation correctness, naming consistency and whether the quickstart runs when pasted. ### How is agent readiness different from agent discoverability? Readiness is about your own product: can an agent use it correctly. Discoverability is about the market: does an agent choose you over the alternatives. Readiness is a precondition for discoverability, and it is entirely within your control. ### What is the most common agent readiness failure? A quickstart that does not run when pasted, usually because of an unstated environment variable, an assumed install step, or an example using an interface that changed. ### Can agent readiness be measured objectively? The reachability and correctness checks are objective and testable with curl and an empty project. Whether an agent then integrates you correctly has to be tested by running an agent, several times, because a single run is noise. ## Read next - [Audit your documentation for coding agents](https://armature.tech/library/audit-your-docs-for-coding-agents) (Markdown: https://armature.tech/library/audit-your-docs-for-coding-agents.md) - [Documentation for coding agents](https://armature.tech/library/documentation-for-coding-agents) (Markdown: https://armature.tech/library/documentation-for-coding-agents.md) - [Agent discoverability: the complete guide](https://armature.tech/library/agent-discoverability) (Markdown: https://armature.tech/library/agent-discoverability.md) - [How to write a quickstart an agent can follow](https://armature.tech/library/write-a-quickstart-an-agent-can-follow) (Markdown: https://armature.tech/library/write-a-quickstart-an-agent-can-follow.md) - [Time to first successful call, when the developer is an agent](https://armature.tech/library/time-to-first-successful-call) (Markdown: https://armature.tech/library/time-to-first-successful-call.md) --- Armature helps software products get discovered and used by coding agents. Service: https://armature.tech/discoverability · Results: https://armature.tech/leaderboards/sectors · Contact: contact@armature.tech