What does an AX engineer do?

An AX engineer, or agent experience engineer, makes a product work well for the AI agents that use it on someone’s behalf. The work covers the surfaces an agent reads and calls: tool descriptions, MCP servers, command-line tools, documentation written for agents, error messages and the way an agent gets access. It also covers measurement, because a change that sounds agent-friendly can still make agents do worse.

Scope: This guide uses “agent experience” for AI agents acting for people, as defined in What is Agent Experience?. Everything below comes from public job postings, team pages and vendor writing, each retrieved on 8 October 2026. Postings close and change, so treat each one as a dated snapshot.

Where the role comes from

The AI sense of agent experience is attributed to Mathias Biilmann of Netlify, in a post dated 28 January 2025. He framed it as a concern for the whole company rather than one team: “Our next company-wide obsession is AX” (biilmann.blog). Netlify’s own page, updated 7 October 2026, draws the line with developer experience in one sentence: when a customer’s agent tries to integrate with an API and fails silently, that is “an AX problem, not a DX one” (netlify.com).

Microsoft’s developer blog published “What is Agent Experience (AX)?” on 6 October 2026, by Waldek Mastykarz. It defines AX as “the experience AI agents have when discovering, choosing, and using your technology”, names three places to work (the documentation agents read, agent extensions such as skills and MCP servers, and the interfaces agents use, such as APIs, CLIs and error messages), and warns that “best practices are hypotheses until you measure them” (developer.microsoft.com).

Neither source says who inside a company should do this work. Job postings do.

What public job postings say

These postings were read on 8 October 2026. They are a small sample chosen because they use agent experience language, not a survey of the market.

Two more postings show that the same words can describe different jobs:

• ACTO, Agent Experience (AX) Engineer, remote from Toronto (Collage). This role designs, builds and tests AI agents for sales and medical teams in life sciences. It is agent building, not making a product work for outside agents. The posting lists CAD 90,000 to 100,000 a year.
• Toast, Senior Software Engineer, AI Agent and Experience Team, Dublin (Toast careers). The posting calls this “Toast’s internal platform team for AI”: an LLM proxy, a plugin marketplace and MCP service templates for Toast’s own engineers. That is the inward meaning, where the agents belong to your own engineering team.

So when you see the title, read the duties. The outward role this guide describes is the first group.

What an agent experience team looks like

Cloudflare runs a public page for its AX team at team.ax.cloudflare.dev. It is a team-run site on a Cloudflare developer domain rather than a press release, so read it as the team’s own description. Its mission is “Make Cloudflare legible to agents”, and it lists five principles: build on public primitives, design docs, APIs and error messages for agents, make authority and approval explicit, measure outcomes, and feed what the team learns back to platform teams. Its projects page lists an agent interface that makes “explicitly approved changes”, a public coding benchmark, and a code-mode wrapper for MCP servers.

Two further mentions are third-party or individual statements, and are labelled as such here. Nx’s blog post of 5 March 2026 credits the pattern collection agent-experience.dev to “the Cloudflare AX team” (nx.dev); that attribution is Nx’s, not Cloudflare’s. Some Cloudflare engineers also name the team in their public social profiles, which are personal statements.

Cloudinary’s posting gives a second picture of team shape: the engineer works “closely with Product, Ecosystem, and Discoverability across the AX team”. So an AX team is often a mix of engineering, product and discovery work rather than one specialist.

The work, surface by surface

The postings and team pages point at the same short list. Each item below links to the guide on this site that covers it.

1. Tool descriptions and schemas. The name, description and input schema are all an agent reads before it chooses a tool. See tool descriptions.
2. MCP servers and tool catalogues. Which tools exist, how many an agent sees at once, and when a large API should be searched rather than listed. See tool catalogues.
3. Command-line tools. JSON output, a mode that never stops for a prompt, dry runs, and exit codes that tell the truth. The examples gallery shows several from public CLIs.
4. Documentation for agents. Markdown versions of pages, llms.txt and AGENTS.md files, and pages an agent can read in one pass. See agent-readable documentation.
5. Discovery files. Machine-readable lists of what a service offers, such as an ARD manifest.
6. Error design. Errors with a fixed code and a next step, so an agent can recover instead of retrying blindly. See design for recovery.
7. Access and approval. Scoped, expiring credentials, sign-up flows an agent can start, and approval steps a person can trust. See approval workflows.
8. Evaluation. Microsoft’s terms are useful here: propensity is whether agents choose your technology, and efficacy is whether they use it correctly once chosen. Both are measured against a bare baseline, the same tasks run with no extensions. See measure agent experience and evaluating agent workflows.
9. Upkeep. Published instructions, skills and tool lists drift away from the live product unless someone checks them against each other.

Skills employers ask for

Across the postings above, the same skills recur. The posting that asks for each one is named in brackets.

• API and protocol design: authentication, scoped permissions, versioning, idempotency and rate limits (Cloudinary).
• SDKs and CLIs that other engineers depend on (Cloudinary, WorkOS).
• Hands-on MCP or LLM tool calling (Cloudinary, Toast, Deepgram).
• Evaluation: writing evaluations, and standing up measurement for each stage of the agent’s path (WorkOS, Deepgram).
• Writing. Cloudinary asks for strong written communication, noting it “matters more than usual when your consumers are machines”. Convex’s posting says “writing is the heart of this job”.
• Public, shipped work. Deepgram asks for AI software “and it is public”, such as agents, MCP servers, CLI tools or evaluation harnesses.

How it differs from DevRel, DX and developer-tools engineering

The boundaries are blurry, and several postings combine roles. The table shows the usual centre of each.

Two cautions. First, “developer experience” also has an inward meaning, the experience of a company’s own engineers, and some vendors now measure coding agents inside engineering teams under the AX name. Second, the outward roles are converging: WorkOS puts “Developer and Agent Experience” in one title, and Convex’s head of developer experience owns docs for humans and agents alike.

A week in the role (illustrative)

This week is invented for illustration. It is not drawn from any company’s practice, and the product is fictional.

The product is the Acme invoicing API, with an MCP server and a CLI.

• Monday: write tasks. The engineer writes eight tasks in the words customers use. Four name Acme (“use Acme to send invoice 1042”). Four do not (“remind my client that the March invoice is unpaid”), to test whether agents choose Acme at all.
• Tuesday: run a baseline. Each task runs five times with one fixed agent setup and no Acme skills installed. Two problems show up in the transcripts. For reminders, the agent calls create_invoice and makes a duplicate. And when a date is in the wrong format, the error says only invalid request, so the agent retries the same call three times.
• Wednesday: fix one surface each. The create_invoice description gains one sentence: “Do not use to remind a client about an existing invoice; use send_reminder.” The date error gains a fixed code and a next step: invalid_due_date: use YYYY-MM-DD, for example 2026-11-30.
• Thursday: run again. The same tasks run five more times with the same setup. The reminder tasks now choose send_reminder in more runs than before, and the date error is fixed on the first retry. A third change, a longer description for every tool, adds tokens without changing any outcome, so it is dropped.
• Friday: keep it true. Both failing tasks join the standing task set. The engineer checks that llms.txt, the skill file and the MCP tool list all use the new tool names, and writes a short change note for the docs team.

What matters in the example is its shape: one task set, a baseline, one change at a time, and a decision based on what agents did.

How to get started

You can practise the work on any public product, including your own.

1. Read What is Agent Experience? and decide which meaning you are working on.
2. Walk through the agent experience examples and run its checklist on one product you use.
3. Pick one job and profile it with the Open Agent-Readiness Rubric. Fix stoppers first.
4. Rewrite one tool description using the MCP tool-description test cases.
5. Run a small with-and-without test, as in measure agent experience, and write up what changed and what did not.
6. To review a whole workflow, follow run an AX review.

Publish what you find. The postings above ask for evidence of shipped, inspectable work, and a dated write-up of one fixed task is that kind of evidence.

What this guide does not claim

It does not estimate how many AX roles exist, how fast the field is growing, or what the role pays across the market. The postings are a small, dated sample, and pay figures are quoted only where a posting publishes them. Nothing here ranks employers or says that any team’s approach works better than another’s.

Frequently asked questions

What is an AX engineer? An AX engineer, short for agent experience engineer, works on how AI agents discover, choose and use a product on a person’s behalf. Public postings describe owning MCP servers, an agent-friendly command-line tool, SDKs, scoped credentials and documentation written for agents, and measuring whether agents succeed with them. The title is new and not standardised, so the duties in a posting matter more than its name.

What does an agent experience engineer do day to day? Much of the work is a loop: write realistic tasks, run an agent on them a few times, read where it went wrong and what it read, change one surface such as a tool description, an error message or a page of documentation, then run the same tasks again and compare quality and cost. Around that loop sit building work (MCP servers, CLIs, SDKs, access for agents) and upkeep, such as checking that published agent instructions still match the live product.

Is an AX engineer the same as an AI agent engineer? Usually not. An AI agent engineer typically builds agents. An AX engineer usually makes a product work well for agents that other people built. The names are not used consistently, though: at least one public posting titled Agent Experience (AX) Engineer, from ACTO, is about designing and building AI agents for life sciences teams.

How is AX engineering different from developer relations or developer experience? Developer relations mainly reaches human developers through content, samples and community. Developer experience improves the human developer’s path through docs, SDKs and tools. AX engineering works on many of the same surfaces, but its main reader is an agent acting for the developer, and it judges a change by repeated agent runs on fixed tasks. In practice the teams overlap, and some postings combine both, such as WorkOS’s Developer and Agent Experience Engineer.

What skills does an AX engineer need? The public postings reviewed for this guide ask for API and protocol design (authentication, scoped permissions, versioning, idempotency, rate limits), experience building SDKs or CLIs, hands-on work with MCP or LLM tool calling, the ability to write evaluations, and strong written communication. One posting also asks for public, shipped AI work such as MCP servers or evaluation harnesses.

How much does an AX engineer earn? There is no reliable market figure yet. Some postings publish a range: on 8 October 2026, WorkOS listed $175,000 to $275,000 plus equity for its Developer and Agent Experience Engineer (United States and Canada), and Deepgram listed $200,000 to $268,000 for a Staff Product Manager, Agentic Experiences, with multiple ranges. Cloudinary’s AX posting published no range. These are single postings, not a salary survey.

How do I become an AX engineer? Build public evidence of the work. Pick a product you use, write a few tasks, run an agent on them, and publish what went wrong and what you would change. Improve a tool description or an error message in an open-source MCP server or CLI. Learn MCP, JSON Schema and basic evaluation design. The postings reviewed here value shipped, inspectable work over titles.

What is an agent experience team? A group that owns how agents experience a company’s product. Cloudflare publishes a page for its AX team with the mission “Make Cloudflare legible to agents” and principles covering agent-legible docs, APIs and errors, explicit authority and approval, and measured outcomes. Cloudinary’s posting describes an AX R&D team that spans product, ecosystem and discoverability work. Elsewhere the same words can mean an internal AI platform team or a contact-centre team, so check the context.

Whatever the title ends up being, the work is clear enough: find where agents go wrong with your product, fix the surface that misled them, and check that the fix helped.