# A framework is a place to put what you find.

> A named, practical framework for Agent Experience work with AI agents: a five-part field map (orient, discover, act, collaborate, learn), a four-step method for applying it, and a rubric for taking inventory of what a product has declared.

Published: 2026-09-02  
Updated: 2026-09-02  
Canonical: https://agentexperience.tech/insights/agent-experience-framework/  
Tags: agent experience, foundations, framework, method, evaluation

AX work goes wrong in a predictable way: a team collects observations about an agent failing, and has nowhere to put them. A framework is the shelf.

**The AX framework on this site is three connected pieces: a five-part [field map](/research/) of where agent work breaks, a four-step [method](/method/) for applying it to one real workflow, and the [Open Agent-Readiness Rubric](/insights/agent-readiness-rubric/) as an inventory of what a product has already declared.** The map says where to look. The method says how to look. The rubric says what is on the record.

This page is a synthesis, not a new proposal. Every component below already exists on this site and has for some time; what has been missing is one page that names them together, says how they connect, and says what they do not do.

A note before any of it, because the acronym is crowded: if you arrived here looking for **Ax, the open-source DSPy-style LLM framework for TypeScript**, that is a different thing entirely, and there is a [short section about it below](#is-this-the-ax-framework-on-github).

## What is a framework for, in AX work?

Not prediction. A framework here does one modest thing: it gives a team a shared place to put what they find.

The characteristic failure of early AX work is not that teams observe nothing. It is that they observe plenty — the agent picked the wrong tool, the docs were fine but the agent never reached them, the approval screen was answered without being read — and then have no structure that says which of those is the same kind of problem as which. Findings arrive as anecdotes, get argued about as anecdotes, and are forgotten as anecdotes.

The three components below are chosen for that job. Each answers a different question, and the answers compose:

| Component | The question it answers | What it produces |
|---|---|---|
| **[The field map](/research/)** | Where in the agent's path does this break? | A named part of the system to inspect |
| **[The method](/method/)** | How do we look at it without boiling the ocean? | One workflow, walked end to end |
| **[The rubric](/insights/agent-readiness-rubric/)** | What have we actually declared? | An inventory of inspectable surfaces |

None of the three is a score of how well an agent will do. That distinction matters enough that it gets [its own section](#what-this-framework-does-not-claim).

## What are the five parts of the field map?

The map follows an agent from a person's goal to a next attempt that is better than the last. Five parts, in the order work moves through them:

1. **Orient** — goal, context, and boundaries. Can the agent tell what it is trying to do, what information is trustworthy, and where a capability begins and ends? This is where an under-specified task and an over-broad permission both live.
2. **Discover** — paths, docs, and capabilities. Can the agent find the right page, the right documentation, the right route? [Make documentation legible](/insights/make-documentation-legible/) and [build websites agents can understand](/insights/agent-friendly-websites/) sit here, as does the whole question of which discovery files are worth publishing.
3. **Act** — tools, workflows, and state. Can the agent connect an intention to a capability without guesswork? This is the home of [tool descriptions as product surfaces](/insights/tool-descriptions/) and of catalogues small enough to choose from well.
4. **Collaborate** — handoffs, approval, and recovery. Does the system know when to act, ask, pause, or return control? [Approval as a workflow](/insights/approval-is-a-workflow/), [context preserved through handoffs](/insights/preserve-context-through-handoffs/), and [recovery designed in](/insights/design-for-recovery/) are the three surfaces here.
5. **Learn** — evaluation and product improvement. Can the team see the decisions that shaped a result, not only the result? This is where [evaluating decisions rather than answers](/insights/evaluating-agent-workflows/) and [measuring agent experience](/insights/measure-agent-experience/) belong.

The parts are not a maturity ladder. Nobody graduates from orientation. They are locations, and the useful move is to find the one where your workflow is currently failing and go there.

Two properties of the map are worth stating explicitly, because they are what make it usable rather than decorative.

**It is ordered by dependency, not by importance.** A failure in *orient* will present as a failure in *act* — the agent picks a wrong tool because it never understood the job. Walking the parts in order is a way of catching that: if the first three parts are genuinely clean and the workflow still breaks, the problem is where it appears to be.

**Every part has a design move, not just a diagnosis.** A map that only tells you where you are is a map of a maze. The field-map page pairs each part with the specific product change that addresses it — give surfaces a clear purpose and next step, treat descriptions as decision surfaces, design around the moments where context goes missing, make approval and scope part of the workflow, connect each evaluation to a concrete change.

## How do you apply it to one workflow?

The [method](/method/) is four steps, and its main contribution is what it refuses to do. It does not start with an autonomy target.

1. **Choose a real workflow.** A task people already want to delegate, with a decision in it that needs to improve. Reconcile an account, research a vendor, prepare a brief, resolve a support ticket.
2. **Map the agent-facing surface.** The context, documentation, tools, interfaces, permissions, and handoffs the workflow actually depends on — which is usually a shorter and stranger list than the team expects.
3. **Find the decisive moments.** Selection, execution, recovery, and the points where uncertainty ought to change the path. These are the places where a small change moves the whole run.
4. **Turn the learning into product work.** Leave with a prioritised change, a testable question, and a way to keep learning as the system evolves.

Step four is the one teams skip, and skipping it is how AX work turns into a document nobody reads. The [AX review](/insights/run-an-ax-review/) is the method run as a single scoped exercise, and it takes the same position: a review that ends in a document has not finished; a review that ends in an edited tool description, an added approval step, a narrowed permission, or a new recovery route has.

The method and the map are meant to be used together in a specific way. The method picks the workflow and walks it; the map names what you hit. "The agent kept retrying the export" becomes "this is a *collaborate* failure — recovery is not designed, so retry is the only route" — and now it is filed next to every other recovery finding, and the team can see that it has four of them.

## Where does the rubric fit?

The map and the method are diagnostic. They tell you what is happening. Neither tells you what your product has already put on the record, and that is a separate and much more mechanical question.

[The Open Agent-Readiness Rubric](/insights/agent-readiness-rubric/) is the inventory layer: 36 checks across six dimensions — discovery, structure and semantics, machine-readable content, action safety, recovery, and policy signals — each with a concrete request or inspection that settles it, and a published weight. It can be run by hand with a browser and `curl`.

The rubric answers "what have we declared?" It does not answer "does it work?" A site can score well and still confuse an agent through unclear copy, and a site can score poorly and be perfectly usable by a capable model. The rubric's own framing is that a score describes declared, inspectable surfaces and predicts nothing about agent success — which is exactly why it composes cleanly with the map rather than competing with it. The map finds the break; the rubric tells you whether the relevant surface was ever declared in the first place.

Public readiness tooling exists alongside it and measures different objects. Cloudflare's Agent Readiness score, announced 17 April 2026, checks edge-observable signals — `robots.txt`, `sitemap.xml`, `Link` headers, Markdown content negotiation, bot rules, Content Signals, an MCP server card, an API catalogue — and publishes them through `isitagentready.com` and, from 12 May 2026, the URL Scanner in the Cloudflare dashboard. That is a scan of a live domain. This rubric is a self-assessment you can run against a staging environment. Neither number converts into the other, and there is no version of this page that ranks them.

## Is this the Ax framework on GitHub?

No. This is the collision worth clearing up in plain terms, because "ax framework" as a search string returns at least four unrelated things.

**Ax (`ax-llm/ax`, [axllm.dev](https://axllm.dev/))** is an open-source, Apache-2.0 framework for building LLM applications, built by the developer `@dosco` and described by the project as "the pretty much 'official' DSPy framework for TypeScript". Its central idea is the typed signature: you declare inputs and outputs on one line, and the framework generates the prompt, the parser, the validators, and the retry loop. It is TypeScript-first, ships as `@ax-llm/ax`, and mirrors the same signatures and agents into generated Python, Java, C++, Go and Rust libraries. It is a thing you `npm install`.

The other claimants to the name are further afield still: `attacksurge/ax` is a distributed scanning framework for penetration testers; `ax-framework.com` is a PHP/JavaScript application framework; and there is at least one independently published "AX Framework" for designing trustworthy AI in a UX tradition.

The AX framework on this page is none of those. It is a *design* framework for Agent Experience — a way of organising product decisions about the surfaces an AI agent works through on someone's behalf. There is nothing to install and no code to import. The two AXes are not competitors, and they are not even really in the same category: you could perfectly well build an agent with Ax the library and then use this framework to find out why the documentation it reads is unusable.

If you want the library, the link above is the right one. Nothing further on this site is about it.

The same care applies to the acronym itself. "AX" also means Agent Experience in a contact-centre sense — the experience of the human agent handling a customer — and inside developer-tooling companies it often means the experience a *coding* agent has inside a repository. [AX compared with UX, DX, and GEO](/insights/ax-vs-ux-dx-geo/) works through those meanings without collapsing them.

## What this framework does not claim

Stated plainly, so it does not have to be inferred:

- **It is not a standard.** No standards body is behind any of it. The map, the method and the rubric are this site's judgement calls, published so they can be argued with.
- **It is not a benchmark.** Nothing here produces a number comparable to anyone else's number, and the rubric says so about its own score.
- **It does not predict agent success.** Every component describes surfaces, decisions, and declarations. None of them models what a given model will do on a given day.
- **It is not exhaustive.** Five parts is a working decomposition, not a proof that agent work has exactly five parts. Where a finding does not fit, the honest move is to record that it does not fit.

What it does claim is narrower and more useful: that a team walking one workflow through five named parts, with a method that ends in a product change and a rubric that inventories what has been declared, will end up with findings that accumulate instead of scattering.

## Where to start

If you have never done this before, do the smallest version. Pick one workflow. Walk [the map](/research/) until you hit the part that visibly breaks. Stop there, make one change, and see whether the next run is better. Then run [the rubric](/insights/agent-readiness-rubric/) once, at leisure, to find out what you never declared.

If you want the whole thing as a single scoped exercise, [run an AX review](/insights/run-an-ax-review/) — that page is the method with the edges filled in.

## Frequently asked questions

**What is the AX framework?**
Three connected pieces: a five-part field map of where agent work breaks — orient, discover, act, collaborate, learn — a four-step method for applying it to one real workflow, and the Open Agent-Readiness Rubric as an inventory of what a product has actually declared. The map says where to look, the method says how to look, and the rubric says what is already on the record.

**Is this the Ax framework on GitHub?**
No. Ax (`ax-llm/ax`, axllm.dev) is an unrelated open-source project — an Apache-2.0 DSPy-style framework for building LLM applications from typed signatures, TypeScript-first, built by `@dosco`. It is software you install. The AX framework described here is a design framework for Agent Experience, with nothing to install. The letters collide; the subjects do not.

**How is an AX framework different from an agent framework?**
An agent framework is code that builds an agent — orchestration, tool calling, retries, state. An AX framework is a lens on the product the agent has to work through: the documentation it reads, the tool descriptions it chooses from, the approval it hits, the recovery route it needs. You can build an excellent agent on a good agent framework and still ship poor Agent Experience, because those failures live in surfaces the agent framework does not own.

**Where should a team start?**
With one workflow people already want to delegate, not with the whole map. Walk the five parts in order until you reach the one that visibly breaks, and stop there. The point is to leave with one product change, not with a completed matrix.

A framework is not a promise about outcomes. It is a shared place to put what you learn, so the next person can find it.