Launching: AX Tier List

Mika Sagindyk · Sep 17, 2026

AI agents are becoming the power users of the web, operating on behalf of human users. This raises an important question: can an AI agent start using your tool without a human in the loop?

Intrigued by this question, we scanned dozens of providers and published our findings on the AX Tier List.

The AX Tier List at 2027.dev/axlist: a table with columns for provider, tier, discovery, login flow, bot protection, paywall and sign-up. The visible rows are the complete S tier (Mastra, Clerk, AgentMail, WorkOS, Netlify, Anchor Browser, ElectricSQL, Browser Use, Browserbase, Hyperbrowser, Sanity, Vercel, Neon, Exa, Steel and Upstash), each marked Hands-off, with discovery reading a dash, then Found, then Only when pointed, then Never found.
The top of the list at 2027.dev/axlist, showing the S tier.

How we graded it

Four things stand between an agent and its first working API call, and those four are the columns: the login flow, bot protection, the paywall, and sign-up.

A provider's tier is its weakest of the four, because activation is a chain rather than an average. A single blocking step stops the whole thing. A tool with a clean SDK, a generous free tier and no bot wall is still out of reach if sign-up demands a phone number, because the agent never gets far enough to enjoy the rest. Averaging the four criteria would hide precisely the step that matters.

Grades come from our own eval runs, plus provider documentation where no run covered a particular step. The runs are from our eval program between June and September 2026, spanning Claude Opus, Sonnet and Haiku alongside GPT-5.6 and Grok harnesses, so a grade reflects how several different agents behaved rather than one model's quirk.

Each provider gets a tier, and the tier name says how much a human still has to do:

  • SHands-off: 16 providers (47%)
  • AJust confirm: 3 providers (9%)
  • BCopy a key: 8 providers (24%)
  • CFigure it out: 5 providers (15%)
  • DBlocked: 2 providers (6%)

What we learned

The blockers cluster at sign-up, not at the API. Captchas, phone verification and card-on-file are where autonomous setup dies. Once an agent is holding a key, most tools on the list simply work. The hard part is the front door, not the building. That is good news, because front doors are far easier to change than products.

B, "copy a key", is 8 of 34, the largest group after S. That is the ordinary dashboard flow that nearly every developer tool ships, and there is nothing wrong with it as a human experience. It is just a human in the loop. The agent gets to the edge of working and then has to stop and ask.

The S tier has a shape. Almost everything in the hands-off tier hands out a claimable resource. WorkOS's installer prints workos env claim. Netlify's --allow-anonymous ships a live site with no account at all. ElectricSQL pre-provisions a scaffold the user can claim later. In each case the agent gets working credentials immediately, and the human identity attaches afterwards.

That pattern takes apart an argument that has been stuck for a while. "Let agents in" and "know who your users are" only look like opposites if identity has to come first. Claimable resources put it second. The account still gets created and the usage still gets attributed; it just happens after the agent has demonstrated there is something worth attributing.

S tier doesn't mean agents actually use it

The tier measures capability: does a hands-off path exist? The list carries a second column, discovery, which measures something different: did the agent actually find it? Those two are close to independent, and the discovery numbers are humbling. Of the 31 providers where there was a better path to find, agents found it in 12 cases (39%), never found it in 12 (39%), found it and it did not work in 4 (13%), and used it only after we pointed at it in 3 (10%).

In more than half of those cases, the thing we graded and the thing that happened in a real run are two different things. The examples below are all good implementations.

Sanity ships one of the cleanest agent paths we have seen. npx sanity new provisions a project with a token and a 72-hour window to claim it, and it is listed in their root llms.txt. That is close to the ideal design. In our runs the agent missed it anyway: it reached for the interactive browser login, failed that, and finished by writing a login script for a human to run later. The capability was one command away and correctly documented, and the run still ended with a note asking a person to take over.

Upstash is starker still. A POST to upstash.com/start-redis returns a live endpoint and token with no signup at all, and it is the first block in their docs addressed to AI agents. We verified that it works. No run ever used it.

Neon shows a third variant: the agent-friendly path did not break, it moved. The old entrypoint still fails, with a generic "Failed to create database" and no pointer to the command that does work, so our runs never found the working one. The capability is intact and the discoverability is broken. From inside an agent run, those two are indistinguishable.

Browser Use is the only provider on the list publishing a working auth.md with valid OAuth metadata, which is about as deliberate as agent-facing design currently gets. The agent used a dashboard key instead.

None of these are engineering failures. They are placement problems. The agent-ready path existed in every one of them; it just was not where the agent looked.

An llms.txt entry is necessary and nowhere near sufficient. Agents do not browse a site the way a curious developer does. They follow the first plausible path from wherever they land (usually the quickstart, usually the same install command a human would run), and then they commit to it. If your agent path is a second, better option sitting politely alongside the human one, it will mostly lose.

Takeaways for teams

  1. Keep an eye on your main blocker Activation is a chain rather than an average, so one step sets the tier for everything around it. Walk the whole chain (login, bot protection, paywall, sign-up) and find the moment where an agent has to stop and ask a human for help. That is the step worth your attention.
  2. Put the agent path where the agent already looks Put the command you want an agent to run in the quickstart, in your CLI's first-run output, and in the error message it hits first. When that path moves, make the old one point at the new one — a generic failure with no pointer costs you the run even when the capability is sitting right there.
  3. Test discovery, not just capability Give an agent a cold start with no hints and watch what it reaches for. It is the only reliable way to see the gap between what you shipped and what actually gets used.
  4. Prefer claimable to gated Provision first, attach identity after. It is what the hands-off tier has in common, and it lets you keep attribution without making an agent wait for a human.

The full list is at 2027.dev/axlist, with the per-criterion grades and the discovery column for all 34 providers. We will keep it current as these paths change, and add more providers continuously. If your tool is missing, request an evaluation. And if you think a grade is wrong, especially if your agent path exists and our runs did not find it, that is exactly the signal we want. Tell us and we will re-run it.

Making a tool usable by agents is mostly not a research problem. It is putting the working path where the agent is already looking.

Request access

If research like this interests you, we are hiring engineers and researchers at 2027.dev.