Agent experience (AX) is a term that defines how well an AI agent can find, choose and use a product for the person it works for. Once a coding agent writes the code, it also chooses what the code runs on. Asked to add payments or email, Claude Code, Codex or Cursor picks the API, the package or its own code.
That makes coding agents an acquisition channel for developer tools, APIs and fintech infrastructure. Machines are moving from retrieving information to making decisions and then to completing transactions. A coding agent already reads the docs and picks the product inside one task, and with Stripe Projects it can also create the account and keys. Each agent settles on a short list of default picks, and the products on it win integrations a developer once chose by hand.
Readiness scanners grade the public website, yet for a developer tool, the agent that matters works in a terminal or an editor. This guide follows one request to working code, then covers six factors a company controls and how to measure them.
Key takeaways
- Agent experience defines how well an AI agent finds, chooses and uses a product. For developer tools, coding agents such as Claude Code, Codex and Cursor now choose the product when a task names none, which makes them an acquisition channel. By August 2026, over 55% of new Stripe integrations involved some form of AI assistance.
- A coding agent picks and integrates a product in five stages. Recall, listing and selection choose the product, and retrieval and integration make it work.
- The category default and a challenger need different first moves. Because the agent mostly chooses from what it already has, in Omnius's reading, the default protects correct use, and a challenger reaches the repository and the instructions through starters, skills and rules files.
- Fix what stops a run first. Keys that need a browser or a sales call, errors without a fix, unpinned installs and docs that come back empty lose integrations before any listing helps.
- Measure agent experience with task panels. Tasks that name no product show whether agents choose it, and tasks that name it show whether they use it correctly.
What is agent experience (AX), and why do developer tools need it?
Mathias Biilmann, Netlify's CEO, coined agent experience in January 2025 for the experience AI agents have as the users of a product or platform.

Microsoft's developer team defines agent experience as what an AI agent experiences when it discovers, chooses and uses a product, and the practice of improving it. For a developer tool, AX covers every surface an agent operates. That means the docs, the package, the CLI and the API's errors, the keys, the MCP server and the skills.
In Netlify's framing, developer experience (DX) serves the people who build on a platform, and AX serves the agents those people send to do the work. Agent-readable websites are a related job, covered in our guide to agentic SEO, where research agents compare B2B SaaS vendors. Agents that pay or call an API at runtime for an end user fall under AX too, and this guide leaves them aside. Here the agent sits inside a codebase and decides whether to install the product.
Most developers now work with coding agents. In JetBrains' 2026 survey of more than 15,000 professional developers, 90% used AI coding agents at work at least weekly, and use of Claude Code and Codex at work more than doubled between January and mid-2026:

Once the agent does the work, it also makes the choice a developer used to make. In June 2026, Stripe reported that agents sent 70% of its CLI requests for API resources and made up nearly 40% of the traffic to its docs. For PostHog, AI assistants and coding agents are already the largest acquisition channel by self-reported signup attribution, larger than Google. The agent's pick now carries part of distribution.
Since June 2026, coding agents have gained new marketplaces, provisioning and measurement:
- 11 June 2026: Stripe expanded Stripe Projects, which lets coding agents provision third-party services from the CLI, to 49 providers.
- 24 June 2026: Netlify released AXIS, an open-source framework that runs real agents against scenarios and scores the result.
- 6 August 2026: Vercel's CLI began installing a provider's published agent skills together with its Marketplace integration.
- 23 September 2026: Anthropic opened the Claude Marketplace with more than 2,000 connectors and plugins.
- 6 October 2026: Microsoft published What is Agent Experience (AX)?, with measured results from its own developer platforms.
Netlify's CEO Mathias Biilmann on the rise of agent experience at CascadiaJS 2026.
How do Claude Code, Codex and Cursor choose and integrate products?
The agent's pick starts with a task that leaves the product open, such as add password-reset emails to this Next.js app. Claude Code has already loaded the project's CLAUDE.md, the descriptions of installed skills and the names of MCP tools. Codex and Cursor load their AGENTS.md files, rules and skills. The agent then reads the repository, acts and checks the result in a loop, with web search and fetch as tools. None of the three documents a step where it searches the web before choosing.
The loop has two approval points. In plan mode, Claude Code researches and writes a plan, and edits wait until the developer approves it. Installs need approval too, which Claude Code's auto mode, the default on every plan since late September 2026, hands to a classifier that allows dependencies declared in the project's manifest and blocks piped install scripts. Headless runs have no developer to approve either step.
We model that loop as five stages. Three choose the product and two make it work, the split Microsoft calls propensity (picking the product) and efficacy (using it correctly).

1. Recall: what the model already knows
The model first proposes what it learned in training, which favours products that were common in public code, examples and docs before its cutoff, June 2026 for the current Claude models. That memory concentrates the choice. Amplifying measured it by giving Claude Code starter projects and prompts that named no tool, and in its February runs one tool took most picks in 12 of 20 categories. GitHub Actions took 94% of CI/CD picks and Stripe 91% of payments picks.
Memory also lags, as Microsoft's AX explainer points out. A model that learned a product's docs in training sees no update until the next model ships, yet an agent that fetches the docs while it works sees it on its next run. So a renamed package or a new API version starts behind in the model's memory.
When a task is small enough to write, such as a cache or a feature flag, the agent often writes the code itself, and that share grew with each model generation in Amplifying's runs:

2. Listing: MCP servers, skills and plugins a team installs
Developers and platform teams browse the marketplaces and install extensions, from MCP servers in the MCP Registry or an agent's own catalog to plugins and skills in the Claude Code, Codex and Cursor marketplaces. Skills are folders of instructions, and a plugin bundles skills, MCP servers and other parts into one install.
The agent works from what is installed. At session start it sees a skill's name and description or an MCP tool's name, and it loads the full skill only when the task matches the description.
So a listing has two audiences: the people who search for and install Claude Code plugins and MCP servers, and the agent deciding whether a description fits the task. The MCP Registry is built to feed other marketplaces and directories, and agents and editors are not meant to read it directly. When we paged through its public API on 14 October 2026, it held 43,543 self-published servers, 27,874 of them with a remote endpoint, and its roadmap rules out ranking them.
An installed extension still has to get used. In Microsoft's SharePoint Framework upgrade test, run in GitHub Copilot Chat, a third-party documentation MCP server added no meaningful lift: its tools did not load in three of five runs and were not called in the other two. For a company, a listing reaches only teams who install it, and it helps only when its description matches the task.

3. Selection: the stack, the instructions and the candidates
Selection weighs, roughly in this order, a dependency already in the project, the developer's instruction or rules file, framework starters and platform defaults, installed extensions and finally the model's own default. In Amplifying's runs, the repository shaped the pick more than the prompt's wording did. In July, the tool Claude Code chose changed with the starter project's stack in 13 of 20 categories.
That order is Omnius's reading, because no study we found tests a repository with a competing SDK installed. One study of agent-written pull requests in popular GitHub repositories found that agents imported libraries in 29.5% of them but added a new dependency in only 1.3%, so in an existing codebase agents mostly work with the dependencies already there. For a company, getting into the repository and the instructions, through starters, templates and a rules snippet, counts for more than how the model remembers the product.
4. Retrieval: docs fetched after the choice and after each error
In the closest published evidence, the docs came after the plan. Microsoft watched an agent form its plan for a SharePoint Framework upgrade from training before it fetched any documentation, and build the release-notes URL from memory. In Profound's comparison of the same answer-engine prompts, Claude Code searched the web in 13% of its responses, against over 93% for Claude in chat.
Claude Code's WebFetch asks the server for Markdown, converts HTML when HTML comes back and strips scripts, and for most fetches a separate model call reads the page and returns only what the agent asked for.
We pointed WebFetch at Swagger UI's demo reference, which builds its page in the browser. The model got back one heading, Swagger UI, and none of the endpoints. The same API's swagger.json, fetched the same way, returned all 14 paths. As the WebFetch docs describe, what arrives is a converted copy of the server's HTML, so a docs page has to carry its content there or in Markdown.
The installed package also informs the agent, because its type definitions fail a wrong call at the type check and its README and docstrings ship with the version in the project. After Microsoft fixed the release notes the agent fetched, every run in its test used the right tool without being told.
5. Integration and use: install, authenticate, call the current API
The agent installs the package or CLI, gets credentials, writes the integration and runs it, reading install output, responses, errors and test results to decide its next step. Each new session starts again from a fresh context and the model's training, so a later upgrade, new endpoint or fix can bring a deprecated call back from memory until the docs, an error or a warning corrects it.
Agents also trust what comes back, in Microsoft's phrase. In its scaffolder test, an unpinned npx command, run on a Node version the SharePoint Framework does not support, installed v1.11.0 from July 2020 instead of v1.23.0, the latest release at the time. The agent treated the scaffold as a success, and developers judge a technology by what the agent produces, as Microsoft notes.
A step that needs a person, such as creating an account or a key in a browser, stops a headless run or sends the agent to its own code.
Each agent documents what it reads at each stage:
| Stage | Claude Code | Codex | Cursor |
|---|---|---|---|
| 1. Recall | The model's training; June 2026 cutoff for the current Claude models | The model's training | The selected model's training |
| 2. Listing | Skill descriptions and MCP tool names load at session start; plugins come from marketplaces | Skill names and descriptions load within about 2% of the context; MCP servers come from config.toml | Skills load at startup, including Claude Code and Codex skill folders; MCP servers install from the Marketplace |
| 3. Selection | CLAUDE.md (or AGENTS.md when there is none) and the repository; plan mode proposes before editing | AGENTS.md files from the global file down to the working directory, up to 32 KiB | Rules go first in the context; nested AGENTS.md files apply in their folders |
| 4. Retrieval | WebSearch returns titles and URLs; WebFetch asks for Markdown and converts HTML, up to 100,000 characters | Web search uses a cached index unless run with --search | A web tool writes and runs searches |
| 5. Integration and use | In auto mode a classifier approves actions; manifest installs pass, piped install scripts are blocked | Network is off by default; the Auto preset asks before network commands | The sandbox blocks network by default; MCP calls need approval |
| Headless runs | claude -p denies actions that would need a prompt | codex exec starts in a read-only sandbox | agent -p only proposes changes unless the script passes --force |
- Claude Code, Codex and Cursor each document loading instruction files and skill descriptions before the task starts, Claude Code in its context window docs, and none documents a web search before choosing.
- In Microsoft's test, the agent planned from training before fetching any docs, and in Amplifying's runs the starter project's stack changed Claude Code's pick in most categories.
- In the loop, the agent reads fetched docs, type errors, install output and errors before its next step.
- The agent mostly chooses from what it already has, and the docs mostly decide whether the chosen product works.
- The product agents already pick protects correct use, while a challenger has to reach the repository and the instructions before the model's memory decides.
What are the six factors of agent experience?
Six factors decide whether a product clears those stages, in the order the agent meets them. A company cannot change the model or the agent, yet it controls the eleven product surfaces those factors sit on:
| Factor | Surface | What the agent does with it | Where it lives | Common gap |
|---|---|---|---|---|
| Known and default | Starters and templates | Starts a project with the provider already in package.json | Framework examples, platform templates and provisioning catalogs | Absent from the starters of the frameworks customers use |
| Known and default | Rules snippet | Loads it as instructions at session start | AGENTS.md, CLAUDE.md and Cursor rules in the customer's repository | No copyable snippet in the docs |
| Listed | MCP server | Calls its tools by name and description | The MCP Registry and client marketplaces | Unlisted, or described in internal terms |
| Listed | Skill or plugin | Loads the body when its description matches the task | The Claude Code, Codex and Cursor marketplaces | A description too vague to trigger |
| Retrievable | Docs | Fetches them after the choice and after each error | The docs website, served as Markdown | Content rendered in the browser; versions not stated |
| Retrievable | Installed package | Reads types and errors when a call fails | Types, docstrings and the README shipped in the package | Untyped SDK or an out-of-date README |
| Retrievable | Changelog | Fetches it when a call fails after an upgrade | The docs website | Deprecations not stated in text |
| Installable | Quickstart | Follows it step by step to the first call | One page per framework | Steps behind a dashboard; unpinned installs |
| Self-serve | Test keys and free tier | Needs a credential to finish | The CLI, the dashboard and the pricing page | Keys only after a browser signup or a sales call |
| Operable and verifiable | CLI | Runs commands and reads output and exit codes | The package registry | Interactive prompts only; output written for people |
| Operable and verifiable | API errors | Reads the message to decide the next step | API responses | Codes without the fix |
1. Known and default: in the model's memory, code and starters
Recall and selection both favour the documented default, the provider that a framework's starter or a platform's integration puts into package.json. Platforms now provision services for agents directly. With the Vercel CLI, a coding agent can provision a Marketplace provider and connect it to the project in one command, then pull its credentials with a second. The Stripe Projects catalog listed more than 60 providers in October 2026.
What to do:
- Keep one package name, and point old names to the new install command.
- Get the product, with its current API, into the starters, templates and public examples of the frameworks customers use.
- Integrate with the platforms that provision providers, such as the Vercel Marketplace and Stripe Projects, where the category fits.
- Put the product name where developers write instructions, in a copyable rules snippet for AGENTS.md, CLAUDE.md and Cursor rules.
- ❌ A renamed SDK whose old package name still installs, with nothing in its README to say it moved.
- ✔ One package name, and the old package's README and registry entry give the new install command.
2. Listed: an MCP server, skills and plugins in the marketplaces
A listing earns its place when it gives the agent the integration rules and the wrong approach to avoid as soon as the task matches. In Microsoft's upgrade test, telling the agent to use the right CLI raised its result from 30 to 75 of 80 configuration checks. As Microsoft concluded, that instruction helps only developers who know the CLI or install the skill that carries it.
Measure every listing against a run without it. On three of Netlify's own AXIS scenarios, run with Claude Code and Codex, adding a skill raised scores by 26 points on average. Yet the third-party documentation server in Microsoft's test added no meaningful lift, so only a run with and without a listing shows which case applies.
Anthropic advises two directory submissions, the MCP server as a connector and a plugin whose skills teach its use. Cursor also reads Claude Code and Codex skill folders, so one skill format reaches all three agents.
Anthropic explains how Claude loads agent skills when a task needs them.
What to do:
- Publish a remote MCP server and register it in the MCP Registry.
- Package a skill with the integration rules and the wrong approach to avoid, inside a plugin, since Anthropic's directory takes skills only in plugins.
- Write each description in the words developers use for the task, with the main use case first.
- Submit to the Claude, Codex and Cursor marketplaces, and link the install commands from the docs.
- Test whether the skill triggers, with and without the plugin installed.
- If the plugin is in Anthropic's official marketplace, have the CLI print Claude Code's plugin hint, so a developer whose agent runs the CLI in an interactive session is offered the plugin once.
- ❌ Skill description: Vendor A helpers.
- ✔ Skill description: Send transactional email with Vendor A from Node.js: password resets, receipts and sign-up verification. Use when adding or fixing email sending.
3. Retrievable: docs and the package agents read while they work
Retrieval decides whether the current version reaches the agent. Every docs page should serve its content as Markdown to agents. Stripe serves any docs page as Markdown with .md appended or to a request for text/markdown, and Mintlify does the same for every docs project it hosts. Stripe's llms.txt goes further and tells agents to distrust version numbers from training:

On 14 and 15 October 2026 we requested the quickstarts of 44 well-known developer tools, chosen by hand across payments, auth, email, databases, hosting, analytics, observability and AI APIs, with Claude Code's user agent. Of the 42 that loaded, 40 returned Markdown to a Markdown request or at a .md URL, and 41 published an llms.txt. Among these tools, a Markdown export no longer sets a product apart.
The docs also need to sit in the indexes agents search after an error. Anthropic names Brave Search as a web search provider for all its products, and Brave's crawler skips any page closed to Googlebot. Cursor names Exa as its web search provider, and Exa's crawler follows a website's rules for the major search engines. ChatGPT search answers leave out websites closed to OAI-SearchBot.
What to do:
- Serve each docs page as Markdown at its .md URL and to requests with Accept: text/markdown.
- State current versions and deprecations in the text of the docs and the changelog.
- Ship typed packages with docstrings and a current README.
- Publish llms.txt for the docs, and measure whether agents use it.
- Keep the docs open to Googlebot, ExaSearchBot, OAI-SearchBot and Claude-SearchBot, whose robots.txt rules Claude's, Cursor's and ChatGPT's search follow.
- Publish the OpenAPI spec at a stable URL, with response schemas.
- Answer a missing docs page with a Markdown 404 that links llms.txt and related pages, as Mintlify does.
- Point agents to the skills index with a Link header or a /.well-known file, as Stripe's docs do, and list the MCP server's URL in the docs.
A plain request shows what an agent receives. Stripe's payments quickstart answered ours on 14 October 2026 with Markdown and a Link header pointing to its agent skills index:
4. Installable: one command to a working integration
A quickstart an agent can run end to end turns a choice into an integration. Pinned versions matter too, as the 2020 scaffold showed, and a package-manager install avoids the block Claude Code's auto mode puts on piped install scripts.
PostHog reports a conversion gap by install path. New users who chose its AI setup wizard, a single command that runs an agent to install PostHog in a project, converted to paid far more often than other new users:

What to do:
- Give each framework one package-manager install command.
- Pin scaffolder versions.
- Name every environment variable and prerequisite, such as the supported runtime version, in the quickstart.
- Run each quickstart headless with an agent before release.
- ❌ See the SDK reference to get started, and an install line that pipes a remote script into a shell.
- ✔ One package-manager command, three named environment variables and a short example that runs as written.
5. Self-serve: test keys and a free tier without sales
Amplifying's July report says why Claude Code builds instead of buying: "accounts and API keys only a human can create." Stripe puts the boundary in the same place. In June it reported that agents can now write the integration code, while managing credentials and setting up accounts are still too hard for them alone.
Stripe's docs now give agents a way past the account step. Run from a CLI that is not logged in, stripe sandbox create returns a sandbox with working test keys and no account, and the sandbox expires after 7 days unless it is claimed.
Stripe recommends a restricted key, never an unrestricted secret key, for any key given to an AI agent. The commands Claude Code and Codex run inherit the developer's environment variables by default, secrets included. A restricted key tagged for an agent also falls under Stripe's default approval rules, so its refunds and subscription cancellations wait for a designated reviewer. Stripe Projects lets a developer set a spend cap per provider.
What to do:
- Issue test keys from the CLI or through a device-code login, the OAuth flow for devices without a browser.
- Offer restricted keys for anything an agent holds, with a spend cap and approval for payouts, refunds and configuration changes.
- State the free tier, its limits and paid prices with units on a public page.
- For payments and fintech, open a sandbox before KYC.
- ❌ Contact sales for API access, or keys shown only in a dashboard after a browser signup.
- ✔ vendor-a login prints a device code, and vendor-a keys create --test writes a restricted test key to .env.
6. Operable and verifiable: errors, warnings and checks agents act on
Agents read errors to decide their next command, and Anthropic advises tools to return errors that state a specific fix the agent can act on. On 14 October 2026 we called 20 well-known developer APIs without a key, one endpoint each, and 17 answered with an authentication error. Six of those named the header or format that would fix the call, and only Stripe's also linked its authentication docs. None of the 17 said where to get a key, the self-serve step above.
Docs steer the agent when they say its plan fails, and Microsoft credits the wording, not the alert box. In Microsoft's SharePoint Framework docs test, a warning naming the failing approach, Manually updating package.json alone will result in build failures, steered far more runs to the right tool than a tip pointing to it:

Interfaces built for agents still need measuring. In an example from Fintech Brainfood, Ramp's CLI returns a transaction in about 105 tokens in its agent mode, against 280 tokens for people. In Microsoft's CLI test on Windows, though, a JSON-only input mode cost 4 to 11 times more per task than regular arguments and lowered the smaller models' accuracy, so a compact output mode and a JSON-only input mode need separate tests.
What to do:
- Give every command non-interactive flags and stable exit codes.
- Offer JSON output as an option, and keep the regular arguments.
- Write errors that name the cause, the fix and a docs link, and for a missing key, the command or page that creates one.
- Send rate-limit headers with API responses, and a 429 status when a limit is hit.
- Where the approach agents default to fails, say so in the docs and name the alternative.
- Ship typed SDKs, test-mode responses an agent can check and local webhook forwarding, as the Stripe CLI offers.
- ❌
Error 401 - ✔
Missing VENDOR_A_API_KEY. Create a test key with vendor-a keys create --test and add it to .env.
What do llms.txt, an agent skill and an MCP entry look like?
Several of those fixes are short text files in published formats, shown here for Vendor A, an invented email API. The llms.txt states the current SDK version, the MCP entry sits under a namespace the company controls, and the skill's description says when to use it:
What happens when Claude Code adds email sending to an app?
Vendor A reappears in the session below, a composite built from Claude Code's documentation and the published tests. A developer opens Claude Code in a Next.js app that uses Auth.js and types Add password-reset emails to this app. Vendor A, Vendor B and Vendor C are invented email APIs:
| Step | What Claude Code read or ran | What came back | What it decided | Surface that decided it |
|---|---|---|---|---|
| 1. Session start | CLAUDE.md, skill descriptions, MCP tool names | Nothing about email | No email tool is in reach | Listing |
| 2. Reading the repository | package.json, the Auth.js setup, .env.example | Next.js and Auth.js; no email provider and no key | The reset flow needs a sender | Selection (the stack) |
| 3. Choosing | Its own training, with no search | Vendor A is the email API it knows for Next.js | Proposes npm install vendor-a, which the developer or the auto-mode classifier approves | Recall |
| 4. First attempt | Writes the send call from memory and runs the type check | A type error on an old signature | The call is out of date | Integration and use |
| 5. Fetching the docs | Vendor A's quickstart, then quickstart.md | The HTML holds only navigation; the Markdown holds the current call | Fixes the call | Retrieval |
| 6. Getting a key | vendor-a login with a device code, then vendor-a keys create --test | A test key written to .env | Carries on once the developer approves the code in a browser | Self-serve |
| 7. Verifying | Runs the reset flow in test mode | An error naming the unverified sender and the command that fixes it | Runs the fix; the test passes | Operable and verifiable |
In this session the choice takes one step and draws on memory, and the four steps after it decide whether the product works.
Three changes would have produced a different session. With Vendor B's skill installed and its description matching the task, Vendor B wins at step 3, and the current send call comes from the skill. With Vendor C's SDK already in package.json, the agent uses Vendor C. When no product offers a key the agent can obtain, it can write its own SMTP code, which Claude Code already chose in about a fifth of email answers in Amplifying's February 2026 runs.
How to optimize a developer tool for coding agents
That is why the first rule is to fix what stops a run before adding anything new. The order follows Microsoft's AX guidance: start with the docs and interfaces agents already use, and add new extensions last. Each step below names an owner:
- Run a baseline task panel. The growth or DevRel lead runs the panel described under measurement, using tasks that name no product, and records what each agent installs.
- Remove the blockers. The docs and platform teams fix keys that need a browser or a sales call, errors without a fix, unpinned installs and docs that come back empty on a plain fetch.
- Steer the agent. The docs team states current versions, examples and deprecation warnings in the text.
- Ship what teams install. DevRel and platform engineering publish an MCP server, a skill and plugin listings, each measured against a run without it.
- Get into starters and catalogs. DevRel and partnerships get the product into starters, templates, provisioning catalogs and framework docs.
- Rerun the panel monthly. Growth reruns it after each default model change, and asks new signups whether an AI assistant or coding agent sent them.
If only three things: let a developer create a test key from the CLI, make every common error name its fix, and serve every docs page as Markdown with the current version in the text.
Netlify on how developers were building for agents in May 2025.
The first move also depends on where the product stands. The product agents already pick and a challenger trying to replace it need different starting points:
| Position | First move | Why |
|---|---|---|
| Category default (the product agents already pick) | Protect efficacy: the current API stated in docs, errors and deprecation warnings, and pinned installs | Agents already choose it, so the losses come from old calls and failed integrations |
| Challenger | Get into the repository and the instructions ahead of the model's memory: starters and templates, a skill teams install, framework docs and a rules snippet; be the named upgrade path in hand-built code | Recall moves only with the next model, while the project's stack changes the pick |
A challenger can also appear in the agent's own code. A third of Claude Code's hand-built answers in Amplifying's July runs named the vendor they expected to swap in later, so being that named upgrade path keeps a product's name in the code even when the agent builds first.
Priorities also shift with the business model:
| Business model | First | Second | Can wait |
|---|---|---|---|
| API-first infrastructure (payments, email, auth) | Test keys from the CLI, errors that name the fix, Markdown docs with current versions | A skill with the integration rules and an MCP server listed in the marketplaces | Agent payment protocols such as x402 or ACP |
| CLI-first developer platforms (hosting, databases) | A non-interactive CLI with a device login, pinned scaffolders and a quickstart per framework | Starters, templates and provisioning catalogs (Vercel Marketplace, Stripe Projects) | A JSON input mode for the CLI |
| SDKs and libraries | Typed packages with docstrings, a current README and deprecations stated in text | A rules snippet and a skill for correct use | An MCP server, unless the library wraps a hosted service |
| Regulated fintech infrastructure | A sandbox with restricted test keys before KYC | Limits, regions and compliance stated in the docs' text | Live-mode onboarding through an agent |
How to check agent readiness, and what scanners miss
Scanners check some of those fixes on the public surfaces, and none shows whether an agent given an unbranded task, one that names no product, picks it. Is Agentic, which Vercel built on Ora's scoring, checks public URLs for Markdown, agent-friendly 404s and content readable without JavaScript. Its documentation says it skips signed-in product states, and the agent task shown in each report does not change the score. Its report for ora.ai on 14 October 2026 shows how the score adds up:

Cloudflare's Is It Agent Ready checks website standards, from AI bot rules and Markdown negotiation to discovery files for MCP, OAuth and Agent Skills. Netlify's open-source AXIS runs real agents on a team's own scenarios. It tests propensity only when those scenarios name no product, so the unbranded panel still matters. Run this checklist before the baseline panel and again after the fixes:
| # | Factor | Check | Passes when | Tool |
|---|---|---|---|---|
| 1 | Known and default | Package name | One current package name; old names point to the new install command | Package registry |
| 2 | Known and default | Starters | The product is in the starters or templates of the frameworks customers use | Manual check |
| 3 | Known and default | Provisioning catalogs | The product is listed where platforms provision providers, when the category fits | Manual check |
| 4 | Listed | MCP server | A remote MCP server is in the MCP Registry, with a description of 100 characters or fewer | MCP Registry |
| 5 | Listed | Skill or plugin | A skill or plugin is listed in the Claude Code, Codex and Cursor marketplaces, and its description names the tasks in developers' words | Marketplace pages |
| 6 | Listed | Rules snippet | The docs offer a copyable snippet for AGENTS.md, CLAUDE.md and Cursor rules | Manual check |
| 7 | Retrievable | Markdown | Every docs page returns Markdown at its .md URL or to Accept: text/markdown, a missing page answers with a Markdown 404, and every link in llms.txt returns 200 | curl, Is Agentic |
| 8 | Retrievable | No JavaScript needed | The quickstart's content is in the HTML the server sends | curl, Is Agentic |
| 9 | Retrievable | Versions stated | Current versions and deprecations are stated in the docs and the changelog | Manual check |
| 10 | Retrievable | Package docs | The package ships types, docstrings and a current README, and the OpenAPI spec with response schemas sits at a stable URL | Package registry, Is Agentic |
| 11 | Installable | One command | Each framework quickstart installs with one package-manager command and pinned versions | A headless agent run |
| 12 | Installable | Named variables | The quickstart names every environment variable and prerequisite, such as the supported runtime version | Manual check |
| 13 | Self-serve | Test keys | A test key comes from the CLI or a device-code login, with no sales call | Manual check |
| 14 | Self-serve | Prices in text | The free tier, its limits and paid prices with units are stated on a public page | Manual check |
| 15 | Operable and verifiable | Non-interactive CLI | Every command runs with flags alone and returns stable exit codes | A headless agent run |
| 16 | Operable and verifiable | Errors and limits | Each common error names the cause and the fix, with a docs link, and API responses carry rate-limit headers and a 429 when a limit is hit | Manual check, Is Agentic |
| 17 | Operable and verifiable | Test mode | A test-mode call returns a response the agent can check, and webhooks forward locally | A headless agent run |
| 18 | Listed | Discovery files | The docs point agents to the skills index and the MCP server with a Link header or a /.well-known file, and a search for the product's API docs returns them | Is It Agent Ready, Is Agentic |
| 19 | All | Unbranded task | An agent given a task that names no product picks it and finishes the integration | AXIS on the team's own scenarios |
How to measure agent experience
Scanners stop short of the test behind agent experience, a paired run. Microsoft runs each task with and without a change, scores both the result and its cost, and treats every practice as unproven until those runs confirm it. AXIS can repeat each scenario and report the median, so one lucky run cannot decide the result. Microsoft's method also splits the tasks: those that name the product show whether agents use it correctly, and those that name none show whether they pick it.
The panel is a fixed set of realistic tasks run headless, each from a clean sample repository, recording the package each run installs and whether the integration works. Microsoft's starting point is 3 to 5 common tasks, each run 5 times with and without a change, on the same model, agent and prompt. PostHog calls the same idea agent preference.
Each agent can record what a run did: claude -p --output-format json reports the run's estimated cost, and codex exec --json lists every command, file change and search. To test discovery, run Claude Code without --bare, which skips installed plugins, skills and CLAUDE.md. Installing needs write and network access: permission allow rules for claude -p, Codex's workspace-write sandbox with network on, or Cursor's --force with sandbox network allowed.
Docs logs show which agents already arrive. Mintlify counted 257 million agent requests to the docs it hosts in August 2026, against 131 million human page loads, and its March count by user agent put Claude Code and Cursor first. Claude Code's fetches identify as Claude-User. Codex sent no identifiable user agent in Mintlify's data, and Mintlify also counts any Markdown fetch from a client that is not a known crawler as agent traffic.
In PostHog's data, coding agents also made most third-party calls to its MCP server:

Answers in chat are a weak proxy for those choices. In Profound's comparison, Claude and Claude Code named only one brand in five in common for the same prompt, against one in two between two Claude answers and two in five between two Claude Code answers. Tracking AI answers to developer prompts, as in our guide to Claude SEO, therefore measures the answer engine, and a task panel measures the agent that installs packages. Each measure answers a different question:
| Measure | What it shows | What it misses | How often |
|---|---|---|---|
| Unbranded task panel | Which product each agent installs for a task that names none | Interactive sessions where the developer names a product or the agent asks | Monthly, and after each default model change |
| Branded task panel | Whether the agent uses the current API, finishes, and at what cost per run | Whether agents choose the product | Monthly |
| MCP calls by client | Which agents call the product's MCP server, and for what | Agents that integrate without the server | Weekly |
| Agent traffic to docs | Which pages agents fetch, by user agent | What the agent did with the page | Weekly |
| Listing analytics | Installs, active accounts and versions of a listed plugin | Whether the plugin is used for the task | Monthly |
| Self-reported attribution | Signups that name an AI assistant or coding agent | Choices in repositories that never sign up | Continuous |
| AI answers to developer prompts | Which products answer engines name for questions such as which email API to use | What coding agents install | Monthly |
What do teams get wrong when optimizing for coding agents?
Five mistakes come from fixing the wrong surface or from skipping that measurement:
- Treating AX as the marketing website. Coding agents work with product surfaces such as the docs, the package, the CLI and the keys.
- Rewriting the CLI for agents without measuring. In Microsoft's CLI test, a JSON-only input mode cost more than regular arguments and lowered smaller models' accuracy.
- Shipping an MCP server without checking that agents call it. The documentation server in Microsoft's test added no meaningful lift, and agents called its tools in none of the five runs.
- Keeping keys behind a browser signup or a sales call. Amplifying names that signup wall as the reason Claude Code builds its own code.
- Counting chatbot mentions as agent preference. Claude Code and Claude in chat name different brands for the same prompt.
Two of those mistakes, the website and the chatbot mentions, sit where agent experience meets AI search.
How we approach agent experience at Omnius
As an SEO and AI search agency, we treat coding agents as an acquisition channel for developer tools, APIs and fintech infrastructure, and we work on what agents and answer engines read about a product. The Omnius memo sets out why. Codex, Cursor and Claude Code have made building software cheaper, so distribution becomes the most valuable part, and for developer tools part of that distribution now runs through coding agents.
In AI answers to tracked prompts about one API category in the Omnius datasets, 18.1% of ChatGPT's citations pointed to documentation pages, against 1.9% for the other engines combined. In ChatGPT, docs are part of the answer before any agent installs anything. The work runs in four parts:
- Machine access: we optimize how AI crawlers and agents reach a company's pages and docs, and what they receive.
- Entities: our entity work keeps the company's facts, documentation and profiles consistent wherever agents read them.
- Docs and guides: we refresh and publish the guides that answer the tasks developers give agents, and work on how documentation pages are retrieved and cited.
- Measurement: we track the answer-engine side, from AI answers and citations to AI-referred signups and the documentation pages those answers cite.

Frequently asked questions
What is an agent skill, and what does one look like?
An agent skill is a folder of instructions that an agent loads when a task needs it. Its SKILL.md file holds a name, a description of up to 1,024 characters and the steps to follow. Agents read only the name and description at startup and load the rest when a task matches. Agent Skills is an open standard, so one skill works in Claude Code, Codex, Cursor and dozens of other clients. The Vendor A skill above shows the format.
How is agent experience different from developer experience?
DX serves the developer, and AX serves the agent the developer sends. A developer can sign up in a browser, watch a video or ask in a community forum, while Claude in Chrome pauses at a login page and hands it back to the developer. An agent can also run the same task five times with and without a change, which Microsoft notes no team would ask of a room of developers, so AX can be measured in ways DX rarely is.
Does llms.txt help coding agents?
Some agents read llms.txt, but most agent fetches ask for Markdown: 65% in Vercel and Ora's study. In the same study, 36% of the runs that reached llms.txt grounded the answer in it. Ahrefs found that 97% of about 38,000 llms.txt files received no requests in May 2026. Claude Code also asks servers for Markdown directly, so a docs server that answers that request with Markdown reaches it whether or not llms.txt exists.
Should a developer tool build an MCP server, a skill or a plugin?
Build the skill first when agents misuse the product, and the MCP server when agents need to act on a hosted service. Anthropic describes the two as complementary, since the server gives the agent tools and the skill teaches it to use them. A plugin packages both for one install. A library with no hosted service rarely needs a server.
Is agent experience the same as contact-centre agent experience?
No, the term has other meanings. In contact centres, agent experience means a human service agent's daily working environment. DX, an engineering-intelligence company, uses Agent Experience for a per-session score of how well coding agents are set up inside an engineering team. This guide uses Biilmann's meaning: the experience of AI agents as the users of a product.
Methodology
The evidence behind this guide:
- Omnius datasets. We counted documentation URLs among the citations in AI answers to tracked prompts about API providers from 13 July to 11 October 2026, by engine, anonymised and aggregated. They cover answer engines, not coding-agent runs.
- Analysis. The five stages, their order, the six factors and the steps are our analysis of Claude Code, Codex and Cursor documentation read on 14 October 2026 and of the studies below. The walkthrough is a composite and the Vendor A artifacts are invented, both built from documented behaviour.
- Our checks. On 14 and 15 October 2026 we requested 44 developer-tool quickstarts with Claude Code's user agent, called 20 APIs without a key, paged through the MCP Registry's public API and fetched one browser-rendered API reference through Claude Code's WebFetch. The quickstarts and APIs were chosen by hand.
- Recent developments. Each date is the announcement date on the primary source, checked on 14 October 2026, and the screenshots were taken on 14 and 15 October 2026.
- Limits. Agents, models and marketplaces change monthly, and picks vary by model, repository and run. No study we found measures how often coding agents search the web before choosing, so the stage order is our reading. Headless runs differ from interactive sessions.
- Other sources. Agent behaviour comes from Anthropic, OpenAI and Cursor documentation. Third-party figures come from Amplifying, a studio that benchmarks coding agents for developer-tool companies; PostHog, which sells product analytics; Stripe, which sells payments infrastructure; Microsoft's developer relations team, whose tests mostly concern Microsoft's own SharePoint Framework and, where the post names the agent, ran in GitHub Copilot Chat on Windows; Netlify, which sells web hosting and makes AXIS; JetBrains, which sells developer tools; Profound, which sells AI visibility tracking; Vercel, which sells web hosting, and Ora, which sells an agent-readiness score, for the agent study; Mintlify, which sells documentation hosting; and Ahrefs, which sells SEO tools.
Sources
The documentation and studies behind this guide:
- Anthropic: how Claude Code works, the context window, memory, permission modes, skills, MCP, plugins, Anthropic's marketplaces, publishing to the directory, plugin evals, tools reference, headless runs, models overview, web search tool, sandboxing, Anthropic subprocessors, writing tools for agents, the Claude Marketplace and measuring agent autonomy
- OpenAI: AGENTS.md, skills, plugins, approvals and security, MCP, non-interactive mode and OpenAI's crawlers
- Cursor: rules, skills, agent, MCP, run modes, plugins and headless CLI
- Standards and registries: Agent Skills, Agent Plugins, the MCP Registry, the llms.txt proposal and RFC 8628
- Agent experience: Biilmann's introduction, One Year of AX, Netlify on AX, Netlify on AXIS, AXIS on GitHub, Microsoft's AX explainer, Microsoft's AX stack, Microsoft on SharePoint Framework skills, Microsoft on docs tips, Microsoft on CLIs and Microsoft on scaffolders
- Studies and market data: Amplifying, February 2026, Amplifying, July 2026, PostHog's AEO handbook, PostHog on MCP calls, PostHog on its setup wizard, Stripe Projects, JetBrains Research, Profound on Claude Code, Vercel and Ora's agent study, Ahrefs on llms.txt, Mintlify's State of Knowledge, Fintech Brainfood on agent customers and an agent pull request study
- Developer docs cited as examples: Stripe's llms.txt, Stripe for agents, Stripe sandboxes, Stripe restricted keys, Stripe CLI listen, Stripe Projects docs, Stripe approvals, Mintlify Markdown export, Vercel's Marketplace skills, Vercel Marketplace for coding agents, Is Agentic, Is It Agent Ready, Brave's crawler and Exa's crawler



.png)










