State of Agent Readiness 2026: What We Found Across 75 Software Platforms
We spent six months running AI agents against software.
Not to test the AI — to test the software.
Our benchmark methodology is simple in principle and laborious in practice: take a standardized set of AI agent journey simulations and run them against the documentation, API surfaces, and SDK ecosystems of 75 production software platforms. Score each platform against the ARS 1.0 model. Compile the results.
The findings are the State of Agent Readiness 2026 Report.
This is the summary. For the full dataset and methodology, the complete report lives at glintbase.dev/research.
The central finding: the gap between the most agent-ready and least agent-ready platforms in our 2026 cohort is not a quality gap — it is a philosophy gap. The best platforms treat documentation as an engineering artifact. The rest treat it as a communication artifact.
What the ARS 1.0 Model Measures
The Agent Readiness Score (ARS) is a composite metric built from eight weighted sub-dimensions.
| Dimension | Weight | What It Measures |
|---|---|---|
| Entry Point Clarity | 22% | How quickly an AI agent can orient and begin navigating |
| Code Sample Validity | 19% | What percentage of code examples execute correctly |
| Structural Coherence | 16% | Consistency of terminology, navigation, and information architecture |
| Prerequisite Explicitness | 16% | How clearly prerequisites and dependencies are stated |
| Context Discoverability | 13% | Availability of machine-readable indexes (llms.txt, OpenAPI, etc.) |
| API Surface Completeness | 8% | Completeness and accuracy of API/SDK reference documentation |
| Error Recovery Guidance | 4% | Quality of error code documentation and debugging guidance |
| Version Parity | 2% | Alignment between documented and current SDK versions |
Each dimension is scored 0–100. The weighted sum produces the final ARS.
Scoring is performed via automated agent traversal — not human review. A simulated AI agent attempts a standardized set of developer tasks using only the publicly available documentation. We measure tokens consumed, correction loops triggered, tasks completed, and tasks abandoned.
The Headline Numbers
Cohort: 75 production software platforms across 12 categories (Developer Tools, Infrastructure, Payments, Data, AI/ML, Security, CRM, E-Commerce, Analytics, Communication, IoT, and Healthcare Tech).
Median ARS: 41.3 out of 100
Mean ARS: 43.7 out of 100
Highest Score: 91 (developer tooling category)
Lowest Score: 12 (legacy enterprise platform)
Platforms scoring above 70: 14 (18.7% of cohort)
Platforms scoring below 40: 34 (45.3% of cohort)
The majority of platforms in our cohort — nearly half — score below 40. This means that for most production software in 2026, an AI coding agent attempting a standard developer workflow will encounter significant friction, correction loops, and elevated token costs.
Category Breakdown
Performance varied significantly across software categories.
| Category | Avg ARS | Top Score | Bottom Score |
|---|---|---|---|
| Developer Tools | 67.4 | 91 | 44 |
| AI / ML Platforms | 62.1 | 88 | 31 |
| Infrastructure | 54.8 | 79 | 28 |
| Payments | 49.3 | 74 | 23 |
| Data Platforms | 44.2 | 68 | 19 |
| Security | 38.7 | 61 | 14 |
| CRM | 36.1 | 58 | 17 |
| E-Commerce | 34.9 | 62 | 16 |
| Analytics | 33.4 | 55 | 12 |
| Communication | 31.8 | 57 | 18 |
| IoT | 28.3 | 49 | 14 |
| Healthcare Tech | 24.7 | 43 | 12 |
Developer tools lead by a wide margin. This is not surprising: developer tool companies build software for developers, and their documentation is maintained by engineers who are themselves using AI coding assistants. They encounter the friction personally and fix it.
Healthcare Tech and IoT trail the field significantly. Documentation in these categories tends to be compliance-driven, dense with regulatory context, and maintained by teams without strong developer experience culture.
The Five Findings That Surprised Us
Finding 1: Marketing ownership of documentation is the single strongest predictor of low ARS scores.
When we cross-referenced our scores against publicly available information about documentation ownership within each company, the pattern was stark. Platforms where the documentation team reported to marketing averaged ARS 29.4. Platforms where documentation was owned by engineering averaged ARS 61.7.
The documentation was not necessarily worse in terms of polish or completeness. It was worse in terms of structural integrity, version parity, and machine-readable context — the dimensions that matter for AI agent traversal.
Finding 2: Code sample validity is the most variable dimension in the dataset.
The range of executable sample rates across our cohort was 14% to 96%. The standard deviation was higher for this dimension than any other. This means there is no typical performance on code sample validity — platforms are scattered across the full range.
The 14% outlier was a fintech platform whose documentation had not been synced with its SDK for over 18 months. Every code sample used deprecated method signatures. The platform's own developer support team confirmed they were aware of the issue.
Finding 3: Platforms with llms.txt score 22 points higher on average.
This is the most practically actionable finding in the report. Of the 75 platforms, 31 had published a valid llms.txt file. These platforms averaged ARS 57.2. The 44 platforms without llms.txt averaged ARS 35.1.
The improvement is not solely attributable to llms.txt itself — platforms that publish llms.txt tend to be more deliberate about machine-readable documentation generally. But the presence of llms.txt is a strong proxy signal for overall machine-readiness philosophy.
Finding 4: Authentication documentation is the #1 failure point across all categories.
71% of agent traversal failures occurred at or before the authentication step. The most common failure modes:
- OAuth flow described without clear redirect URI examples
- API key scoping not explained
- Token expiry and refresh not covered
- Rate limiting on authentication endpoints not documented
- Sandbox vs. production credential differences not distinguished
Authentication is the gate that determines whether an agent can access any other part of your product. Its quality has outsized leverage on overall ARS.
Finding 5: Platform size does not predict ARS score.
We expected larger platforms — with more resources and larger documentation teams — to score higher. They did not, consistently.
The highest-scoring platform in our cohort has 31 employees. The lowest-scoring platform has over 4,000. Team size, funding, and market position were not correlated with agent readiness. Engineering culture and documentation philosophy were.
The full report includes platform-by-platform percentile rankings, sub-dimension breakdowns, and the complete ARS 1.0 scoring rubric. It also includes the raw traversal log data for the 12 standard agent journey tasks used in our benchmark protocol.
What High-Scoring Platforms Have in Common
We analyzed the 14 platforms that scored above 70 to identify the structural patterns they share.
They treat documentation as a release artifact. Documentation updates ship with code changes. Stale examples are caught in CI before they reach production. The documentation is versioned alongside the SDK.
They publish structured machine-readable context. Every platform in the top quartile had at minimum an llms.txt file and an OpenAPI specification. Seven of the fourteen had a published MCP server configuration.
They front-load prerequisites. Every guide begins with a clear prerequisites section: what you need installed, what credentials you need, what version of the SDK is expected. This single pattern eliminates the majority of prerequisite-related agent failures.
They maintain a single source of truth per concept. High-scoring platforms resist the temptation to explain the same concept in multiple places. Repetition creates inconsistency. Inconsistency creates ambiguity. Ambiguity is the primary driver of agent hallucination.
They expose a flat, navigable documentation structure. Deep nesting — documentation buried four or five levels into a navigation tree — dramatically increases discovery overhead. Top platforms keep their most important content within two navigational steps of the homepage.
What Low-Scoring Platforms Have in Common
The bottom quartile shows an equally consistent pattern.
Documentation is treated as a separate product from the software. It is maintained on a different schedule, by a different team, with different quality gates. The result is inevitable drift between documentation and implementation.
Examples are aspirational, not tested. Code samples are written to illustrate concepts, not to be executed. They reference the API as it was designed, not necessarily as it currently behaves.
Machine-readable context is absent. No llms.txt. No OpenAPI spec (or an outdated one). No semantic metadata. Agents must discover the product structure through expensive HTML traversal.
Error guidance is missing. Error code documentation is sparse or absent. When an agent encounters a failure, it has no reliable way to diagnose the cause from documentation alone — triggering costly correction loops.
The Trajectory
The 2026 benchmark establishes the baseline.
We intend to re-run this benchmark annually. Our expectation — based on the rate of adoption of llms.txt and MCP standards across the developer tooling ecosystem — is that the median ARS will climb approximately 8–12 points per year as documentation practices adapt to the agentic era.
The gap between the top and bottom quartiles will also narrow, but not because the bottom improves quickly. It will narrow because platforms that do not improve will lose developer adoption to platforms that do.
Agent-mediated discovery is becoming the dominant mode through which developers evaluate new software integrations. If your platform is hard for agents to navigate, it will increasingly be invisible to developers.
Read the complete State of Agent Readiness 2026 Report → glintbase.dev/research