The term itself

Agent Experience (AX)

Agent Experience is the quality of a digital product or platform as experienced by an AI agent acting on behalf of a person. It covers whether that agent can discover the product, understand what it does, choose and use the right capability, recover from failure, and hand work back to a human at the right moments. The term was introduced publicly by Mathias Biilmann, CEO of Netlify, in “Introducing AX: Why Agent Experience Matters” on 28 January 2025, where he defined it as “the holistic experience AI agents will have as the user of a product or platform” (biilmann.blog).

The two AI senses of AX

“Agent Experience” is currently used for two different disciplines. The outward-facing sense, the original one, treats the agent as an external visitor arriving on behalf of your customer, and asks what it encounters on your site, in your docs, and at your API. The inward-facing sense treats the agent as an internal engineering tool and measures how well your own codebase and practices support it, as in DX’s April 2026 product that scores coding-agent sessions on Requirements, Steering, and Scope (getdx.com, 2026-04-10). The test is whose technology the agent is using: a developer’s coding agent building with your SDK, API or CLI is outward AX for you, which is the scope of Microsoft’s “What is Agent Experience (AX)?” (6 October 2026), while your own engineers’ agents working in your own repository are the inward sense. Both are legitimate; a team that does not say which one it means will fund the wrong work.

Agent experience, contact-centre sense

In customer-service and contact-centre software, agent experience (AX) refers to the working environment of a human support agent. Genesys defines it as “the quality of an agent’s day-to-day work environment, including the tools, processes and support systems that shape how effectively they serve customers” (genesys.com). This usage predates the AI sense, remains active, and is the reason searches for “AX” return two unrelated literatures.

Agentic experience

A phrasing variant of Agent Experience, used interchangeably by some writers and preferred by a few design commentators who feel “agentic” better describes the mode of interaction than the actor. The originator’s chosen form is “Agent Experience”, and that spelling dominates public usage. Prefer it unless quoting a source directly.

Agent experience design (AXD)

Agent experience design is the practice of shaping the surfaces an agent moves through (entry points, capability descriptions, state, permissions, approval moments, and recovery paths) so delegated work stays legible and controllable. It names design work, and as of September 2026 no canonical framework or certification stands behind the term.

AX review

A structured walk of one real workflow from a person’s goal to a responsible outcome, inspecting each step for whether an agent could find, interpret, choose, act, recover, and hand back. It ends with the smallest change that would make the next attempt more useful, and produces no score.

Agents and their behaviour

AI agent

A software system that pursues a goal on someone’s behalf by planning, calling tools, and acting across multiple steps, rather than producing a single response. What makes it an agent is the loop: it decides what to do next based on what happened last.

Harness

The application that runs a model as an agent: it assembles the context the model sees, decides which tools to expose, executes the tool calls the model asks for, and runs the loop until the task stops. The word is older than agents (test and evaluation harnesses), but in agent work it names this layer; the VS Code team described GitHub Copilot’s harness in these terms on 15 May 2026 (code.visualstudio.com). When the harness belongs to a third party, as it does when customers bring their own assistant, a product team cannot change it except through that vendor; a team that builds its own harness, or runs an open-source one, can change it directly. Either way, the same tool description or document can be read differently in two harnesses.

Agentic browsing

The pattern of an AI agent operating a website (reading its structure, filling forms, clicking controls, and completing tasks) rather than only reading its text. Chrome’s Lighthouse now groups a set of checks under this heading, a sign that browser vendors treat it as its own kind of traffic.

Delegated work

The unit of analysis in AX: a job a person hands to an agent, with a start, an observable outcome, and a boundary beyond which the agent should stop and ask. Calling it delegation instead of automation keeps the person’s accountability in view.

Context window

The finite amount of text a model can hold in view at once, spanning the instructions, the conversation, retrieved documents, and tool results. Most practical AX problems are context problems: the information the agent needed existed somewhere, but not inside the window at the moment of the decision.

Context engineering

The practice of deciding what enters an agent’s context window, in what order, and at what cost, as opposed to prompt engineering, which concerns how a single instruction is worded. This field guide treats it as the main lens for agent reliability, because missing or crowded-out context limits a run more than the wording of any one instruction.

Progressive disclosure

Loading only a short description of a capability or document up front, and the full contents only when the agent selects it. Agent Skills and llms.txt both work this way, and it is the main technique for keeping context windows affordable as the number of available tools grows.

Handoff

The transfer of a task between an agent and a person, or between two agents, along with enough state and reasoning for the receiver to continue. This field guide treats a handoff that loses the reason for the work as one of the main ways an otherwise successful run ends up useless.

Human-in-the-loop (HITL)

A workflow design in which a person reviews, approves, or corrects the agent’s work at defined points rather than continuously. The design question is where to put the person: too many checkpoints and the delegation has no value, too few and consequential actions happen unreviewed.

Approval gate

A deliberate pause before a consequential or irreversible action, at which the agent explains what it intends to do and why, and a person decides. A good approval gate presents the decision in terms the person can evaluate quickly; a bad one presents a raw payload and asks for consent.

Recovery path

What a product offers an agent after something goes wrong: an error that says what to do next, retained state, and a route back to a useful step. This field guide treats failure as a normal part of agent workflows, so the recovery path is a main design surface.

Trace

The recorded sequence of an agent run (prompts, tool calls, arguments, results, retries, and handoffs), used to understand what actually happened. They do for AX what session recordings and analytics do for UX, and this field guide treats them as the most direct evidence a team has of what an agent actually did.

Sandbox

A constrained execution environment in which an agent can act without reaching production systems or irreversible side effects. Sandboxing belongs to the permission layer. In this field guide the harness enforces it, and the model is not asked to police itself.

Capabilities and protocols

Tool

A named, callable capability exposed to an agent, with a description and a schema for its inputs and outputs. From the agent’s point of view a tool is defined entirely by its description; from the system’s point of view it is defined by what it actually does. This field guide locates tool-selection errors in the gap between the two.

Tool description

The natural-language text that tells a model what a tool is for, when to use it, what it needs, what it returns, and when not to use it. Descriptions are read at the moment of selection, so their job is to distinguish a tool from its nearest neighbours as much as to explain it.

Tool annotation

Structured hints attached to a tool, such as read-only, destructive, or open-world markers, used to inform selection and user-facing confirmation. The MCP specification is explicit that these are hints and should be treated as untrusted unless the server itself is trusted; they are not a security boundary.

Model Context Protocol (MCP)

MCP is an open protocol that standardises how AI applications connect to tools, resources, and prompts provided by external servers. Introduced by Anthropic in November 2024 and since adopted broadly across vendors, it is the closest thing the ecosystem has to a common tool-integration layer; the specification is versioned by date, with 2026-07-28 current as of this writing (modelcontextprotocol.io).

MCP Server Card

A small, static JSON document that describes one remote MCP server before a client connects: its name, version, description, endpoints and supported protocol versions, but not its tools, which are read live through the protocol. MCP’s proposal SEP-2127 was merged as Final on 6 October 2026; it recommends serving the card at <streamable-http-url>/server-card and listing it in an AI Catalog at /.well-known/ai-catalog.json for domain-level discovery (modelcontextprotocol.io). The detailed schema lives in an extension repository that still described itself as experimental in October 2026. Adoption remains very small: Cloudflare’s April 2026 scan of 200,000 major domains found fewer than 15 sites publishing MCP Server Cards or API Catalogs (blog.cloudflare.com, 2026-04-17).

Agent2Agent (A2A)

A2A is an open protocol for one agent to discover another, delegate a task to it, and exchange results, without either side exposing its internal implementation. Announced by Google on 9 April 2025 and donated to the Linux Foundation in June 2025, it defines Agent Cards for capability advertisement, Tasks for the work exchanged, and an HTTP/JSON-RPC transport (linuxfoundation.org).

Agent card

A published document describing an agent’s identity, capabilities, endpoints, and authentication requirements, conventionally served from a well-known path so other agents can find it. It is the A2A analogue of what an MCP server card does for tools.

Agent Skills

A portable packaging format for reusable procedural knowledge, built around a SKILL.md file with frontmatter and optional scripts and assets. The host loads only the name and description until a skill is activated, which makes skills a progressive-disclosure mechanism as much as a distribution one.

Agent extension

Anything a technology owner or a developer puts in front of an agent to shape its behaviour: skills, MCP servers, instruction files and custom agents. The term comes from Microsoft’s Agent Experience series, which uses it from “The AX stack” (21 May 2026) and defines it in “What is Agent Experience (AX)?” (6 October 2026) (developer.microsoft.com). The series’ main caution is that extensions compete for the same context window, so one that helps on its own can hurt alongside others.

AGENTS.md

AGENTS.md is a plain-Markdown file placed in a repository to give coding agents durable, project-specific instructions: build and test commands, conventions, and hazards. The format is open and documented at agents.md, has no required fields, and resolves nearest-file-wins in nested directories. Keep it short and operational; it is not a wiki.

WebMCP

WebMCP is a proposed browser API that lets a web page expose its own functionality to an AI agent as typed, callable tools, instead of forcing the agent to simulate clicks. It is developed in the W3C Web Machine Learning Community Group, was first published on 13 August 2025, and now specifies a document.modelContext interface with registerTool, getTools, and executeTool (github.com/webmachinelearning/webmcp). It is a Community Group proposal, not a ratified web standard.

x402

An open payment convention that revives the HTTP 402 Payment Required status code so an agent can be charged for a request programmatically. It appears in agent-readiness checklists as the machine-payment signal, and remains early in adoption.

Discovery and description files

llms.txt

llms.txt is a proposed Markdown file at a site’s root that gives LLMs a curated, link-rich index of the site’s most useful documentation. It was proposed by Jeremy Howard on 3 September 2024 and is maintained as a community proposal at llmstxt.org, not as a standards-track specification. Evidence that production AI search systems read it is weak, and Google states that Search ignores it: see the state of the llms.txt evidence.

llms-full.txt

A companion convention to llms.txt in which the site publishes its full documentation as a single concatenated Markdown file rather than an index of links. It is useful for coding agents that want everything at once and expensive in context for agents that do not.

An emerging convention of advertising a page’s Markdown or LLM-oriented representation via an HTTP Link header rather than requiring the agent to guess a path. It is thinly documented and thinly adopted, but it addresses a real weakness of root-file conventions: discovery by guesswork.

Markdown content negotiation

Serving a clean Markdown representation of a page when the client asks for it, via Accept headers or a .md twin URL, so agents do not have to strip navigation and layout out of HTML. Cloudflare’s April 2026 scan found 3.9% of 200,000 major domains served Markdown on request (blog.cloudflare.com, 2026-04-17).

ai-catalog.json

/.well-known/ai-catalog.json is the well-known path of the AI Catalog, a draft specification for listing AI artefacts (MCP servers, A2A agents, skills and others) on a domain, developed in a Linux Foundation working repository with steering-committee seats held by people at Google, Microsoft, Anthropic and PulseMCP (ai-catalog.io). MCP’s Server Cards proposal (SEP-2127, Final on 6 October 2026) uses it for domain-level discovery. The same path is also the predecessor path of the Agentic Resource Discovery specification, which moved its own manifest to /.well-known/ard.json in v0.91 (26 August 2026). So one path now belongs to two specifications; see how ard.json and ai-catalog.json relate.

Agentic Resource Discovery (ARD)

ARD is an open specification for publishing a machine-readable inventory of the agents, tools, servers and APIs a domain offers, at /.well-known/ard.json, alongside registries that index those manifests and answer natural-language discovery queries. The specification calls itself a discovery envelope rather than an execution mechanism, and names three authors (at Google, Microsoft and Hugging Face), with a wider acknowledgements list including GitHub, Cisco, Databricks, Nvidia, Salesforce, Snowflake and Amazon. Announced 17 June 2026, licensed Apache 2.0, and at v0.91 still marked “Proposal” (developers.googleblog.com). It is very new; treat adoption claims sceptically. See the ARD implementation guide.

Content Signals Policy

A machine-readable extension to robots.txt, published by Cloudflare on 24 September 2025 under CC0, that lets a site state how its content may be used after access: for classic search indexing, for AI training, and for real-time AI input such as retrieval-augmented answers. Cloudflare is explicit that it is a declaration of preference, not an enforcement mechanism (cloudflare.com).

robots.txt

The long-standing convention by which a site tells crawlers which paths they may fetch, now doing double duty as the main place AI crawler preferences are expressed. It remains the only one of these files with near-universal support: Cloudflare’s April 2026 scan found 78% of 200,000 major domains published one.

Accessibility tree

The structured representation of a page’s meaningful content and controls that browsers expose to assistive technology and, increasingly, to agents. When the accessibility tree and the visual page disagree, a task that looks trivial to a person becomes fragile for an agent, which is why accessibility work and AX work overlap so heavily.

Measuring agent experience

Bare baseline

The same tasks run with no agent extensions loaded, only the harness and the model, used as the comparison point for every change. The term is defined in Microsoft’s “What is Agent Experience (AX)?” (6 October 2026) (developer.microsoft.com). Without it, a team cannot tell whether a skill or an MCP server helped, or whether the model would have done the same alone. See how to measure agent experience.

Lift and drag

Measured against a bare baseline, a change produces lift if outcomes improve and drag if they stay the same or get worse. Microsoft’s Agent Experience series uses the pair from its first post, “The AX stack” (21 May 2026), and its 6 October 2026 primer adds a third verdict: lift that is too expensive to keep. A change that makes an agent call your tool more often is not lift unless the result is better.

Agent profile

The setup a result was measured with: the operating system, the harness and its version, the model and its settings, and the extensions loaded. Microsoft’s 6 October 2026 primer puts the rule plainly, “A result belongs to the profile it was measured with”, and notes that the term is not the same as the agent profile files some tools use to configure custom agents.

Task cost

What it costs to complete one task with a given setup, counting every token at its price rather than only the token count, and reported next to quality every time. The definition is from Microsoft’s 6 October 2026 primer. It matters because a model with cheaper tokens can cost more per task if it needs more steps. This field guide also counts human interventions per completed task as part of the cost.

Propensity

Whether an agent finds and chooses your technology when the task does not name it: for example, which email service it reaches for when asked to add email sending to an app. It is one of the two questions in Microsoft’s 6 October 2026 primer; some evaluation tools call it discovery and selection. It overlaps with GEO, which concerns whether AI search mentions a product at all.

Efficacy

Whether an agent uses your technology correctly once it has chosen it, tested with tasks that do name the product: for example, whether it calls your current API or one you deprecated. It is the second question in Microsoft’s 6 October 2026 primer; some tools call it quality. A good efficacy result says nothing about propensity, and the reverse is also true.

Readiness and discoverability

Agent readiness

A product’s preparedness for agents to do a job for a person, usually expressed as a checklist or score. Several incompatible tools exist. They measure different objects (a site, a docs site, a repository, an organisation), so their scores are not comparable. At launch, Cloudflare’s Agent Readiness score rated four dimensions (discoverability, content, bot access control and capabilities) and checked agentic commerce without scoring it (blog.cloudflare.com, 2026-04-17). This site’s rubric gives a profile per job instead of a score.

Agent-friendly

An informal quality label for a product whose structure, labels, actions, and errors are legible to an agent as well as to a person. In this field guide it resolves to unglamorous things: real semantic HTML, stable controls, decision-critical information stated on the page, and errors that name the next step.

Generative Engine Optimisation (GEO)

GEO is the practice of improving how a page is retrieved and used by generative answer engines. The term comes from a peer-reviewed KDD 2024 paper by Aggarwal et al., which defined it as a framework for improving visibility in generative-engine responses (arxiv.org/abs/2311.09735); it is the only one of the AI-visibility labels with a peer-reviewed origin.

Answer Engine Optimisation (AEO)

A practitioner term for the same territory as GEO, focused on being the source of a direct answer rather than a ranked link. Google treats AEO and GEO as descriptions of work that, from Search’s own perspective, remains SEO (Google Search Central).

LLMO

Marketing shorthand for “LLM optimisation”, used loosely for anything intended to improve visibility inside AI answers. No platform documents it as a category and it has no stable technical definition; treat it as vocabulary rather than method.