Almost every conversation I have right now about agentic programmability starts in the wrong place. There is budget, there is a mandate from somewhere above, and there is a shopping list — an MCP server, a set of agent skills, an agent gateway, maybe an x-agentic-access classification bolted onto whatever contract exists. What is almost never on the list is the boring work underneath: the contract itself, the auth story, the error envelope, the examples, the rate-limit headers, the changelog. That work does not feel like an AI investment. It is the only part of the AI investment that reliably pays.
I can now say that with numbers instead of opinion. The API Evangelist Rating System gives every provider in my catalog two scores that are deliberately never blended into each other. The composite Kin Score is the foundation number: six facets — contract quality, developer ergonomics, access clarity, operational transparency, contract governance, discoverability — asking whether this API can be discovered, understood, adopted, and operated without a sales call. Agent readiness is a separate 0–100 score on its own axis, asking a narrower question: can an autonomous agent drive this API without a human papering over the gaps? Keeping them apart is what lets me ask how they actually relate, and this week’s run — rubric 0.15.1, scored 2026-08-27, 27,310 providers holding both scores — answers it.
The relationship is not subtle
Across all 27,310 providers, the correlation between composite Kin Score and agent readiness is r = 0.891. In a catalog this messy, that is about as close to a straight line as anything I measure. Cut it by composite decile and the shape is obvious:
| Composite decile | Composite range | Mean agent readiness | Agent-Ready or better |
|---|---|---|---|
| 1st (bottom) | 0.0 – 4.1 | 0.0 | 0.0% |
| 3rd | 5.2 – 7.6 | 0.2 | 0.0% |
| 5th | 10.6 – 14.2 | 1.0 | 0.0% |
| 6th | 14.2 – 20.7 | 3.3 | 0.2% |
| 7th | 20.7 – 30.6 | 12.3 | 4.7% |
| 8th | 30.6 – 38.7 | 21.3 | 13.5% |
| 9th | 38.7 – 47.8 | 25.9 | 29.2% |
| 10th (top) | 47.8 – 92.3 | 33.2 | 62.8% |
The bottom half of the catalog by foundation does not produce agent-ready providers. Across the 13,655 providers in the bottom five deciles, exactly two reach the Agent-Ready band. Whatever agentic ambitions those companies have, the score cannot see them, and neither can an agent.
The single cleanest cut is the contract. 18,397 of the 27,310 providers hold no machine-readable contract of any kind — not OpenAPI, not a FHIR CapabilityStatement, not GraphQL introspection, nothing. Their mean agent readiness is 1.43. The 8,913 that hold one average 26.97. Of the 18,397 with no contract, exactly 49 claw their way to Agent-Ready or better — 0.27% — and 42 of those 49 got there by publishing a provider-verified MCP server, with 48 of 49 serving machine-readable auth metadata. They did not skip the foundation; they built a different one. There is no version of agentic programmability that skips this step. An agent calls APIs from contracts, not from your docs site.
The honest caveat, which turns out to be the argument
Some of that correlation is structural, and I am not going to pretend otherwise. The two scores share inputs. Contract presence, auth clarity, error semantics, examples, and rate-limit signalling all earn points on both axes, because they genuinely matter to both a human developer and an agent. A skeptic should discount r = 0.891 on those grounds.
So discount it. Restrict the population to the 8,913 providers who already hold a contract — removing the biggest shared term entirely — and the correlation falls to r = 0.579. That drop is the finding. Contract presence is the dominant variable in the whole relationship, and even after you control it away, more than half the remaining relationship survives. Foundation work keeps paying after the spec exists.
Necessary, and nowhere near sufficient
The other direction is where the shopping-list crowd should slow down. A strong foundation does not hand you agent readiness:
| Composite band | Providers | Mean agent readiness | Agent-Native |
|---|---|---|---|
| Exemplar | 292 | 42.1 | 19.5% |
| Strong | 1,169 | 34.5 | 10.4% |
| Developing | 3,818 | 27.3 | 3.3% |
| Thin | 4,181 | 19.7 | 0.6% |
| Emerging | 6,552 | 3.8 | 0.0% |
| Minimal | 11,298 | 0.2 | 0.0% |
Even in the top composite decile, only 8.5% are Agent-Native, and 37.1% of the best-foundation providers in my catalog fail to reach Agent-Ready at all. These are companies with real contracts, good docs, clear pricing, published status pages — and an agent still cannot safely drive them. A good API is not automatically an agent-drivable API. The foundation buys you the option to become agent-ready. It does not exercise it.
Run it backwards and the dependency shows up as a floor. Of the 334 Agent-Native providers in the catalog, 91% sit at Developing or above on the composite. Only 30 are below it, none lower than a composite of 19.8, and the median across all 334 is 55.0 — solidly in the Strong band. Nobody arrived at Agent-Native from a weak foundation.
What the agent layer is actually made of
Look at what the agent-readiness dimensions ask for and the foundation dependency stops being statistical and becomes mechanical. A stable error envelope, so a retrying agent can tell “try again” from “stop.” Idempotency, so a retry is not a second charge. Documented rate-limit state, so an agent backs off instead of hammering. Request and response examples, so it does not invent a payload. Every one of those is ordinary API design hygiene that has been on my list for fifteen years, now with a machine as the consumer that will not forgive you for skipping it.
And the catalog is thin exactly there. Only 771 providers of 27,310 (2.8%) document idempotency at all — and that is after excusing the 1,001 read-only providers for whom the check is legitimately N/A. Only 18.2% publish a stable error envelope. Those two are precisely why the Agent-Native band gate exists — a provider can clear the point threshold and still be demoted for missing them, because a score that calls an API agent-native when a retry can double-charge a customer is not measuring anything worth measuring.
Then there is the provenance problem, which is the part I would put in front of any executive writing a check this quarter. In my catalog, 6,617 providers carry a derived agentic-access contract and 31 publish their own. For MCP, 793 servers are provider-verified against 1,297 that are merely documented somewhere. Most of the agent layer that exists today is work done about providers rather than by them — including work my own enrichment pipeline did — which is why authorship grades the award and derived artifacts carry a fraction of the credit. You cannot buy past the foundation with a generated artifact. The generated artifact is a placeholder telling you what the foundation is supposed to hold.
The exception that names its own mechanism
There is a real counterexample and I published it two days ago: Australia’s banks score low on composite and high on agent readiness. Fifty banks, none breaking 51 composite, most of them Agent-Native. That decoupling is genuine, and it happens for a nameable reason — a regulator handed all fifty of them one identical mandated contract, and uniformity is exactly what agent tooling wants. Machine-legibility came free with compliance, and the product dimensions the mandate never required (examples, rate limits, events, idempotency) are barren.
That is not a route anyone can choose. If a regulator has not written your contract for you, the only path to a machine-legible surface is building one. And the Australian case makes the same argument from the other side: agent readiness arrives when someone builds the foundation. In that market it just was not the banks.
Sequence it accordingly
If you are allocating budget for agentic programmability, the order is not a matter of taste, and it is visible in the data:
- Ship a machine-readable contract for every API you expect an agent to call. Below this, nothing else you fund can be measured, by my rubric or by an agent.
- Make auth machine-readable — served metadata, declared scopes, no prose-only OAuth walkthrough.
- Publish a stable error envelope and idempotency semantics. Fewer than one in five providers has the first and fewer than one in thirty has the second, and together they are what stands between an agent’s retry and an incident.
- Add examples and rate-limit signalling so an agent can construct a call and pace itself.
- Then build the MCP server, the skills, and the agentic-access classification — first-party, because derived artifacts are scored as the placeholders they are.
Steps one through four are just APIs done well. That is the uncomfortable part of the message and the reason I keep repeating it: the agentic turn did not introduce a new discipline, it removed the human who was quietly absorbing the cost of skipping the old one. You can check where any provider sits on both axes at APIs.io, and the full rubric — every facet, every dimension, every band cut and the reasoning behind it — is at apis.io/rating.
