# A framework is a place to put what you find. > A named framework for Agent Experience work: a five-part field map (orient, discover, act, collaborate, learn), a four-step method, and a job-level readiness rubric. Published: 2026-09-25 Updated: 2026-09-26 Changelog: 2026-09-26: Updated for the Open Agent-Readiness Rubric v0.2: the rubric now gives a profile of one job across six tracks, with stoppers first and no total, instead of an inventory of declared surfaces scored out of 100. Rewrote the rubric section, the component table, the diagram label and the FAQ answer to match. Canonical: https://agentexperience.tech/insights/agent-experience-framework/ Tags: agent experience, foundations, framework, method, evaluation **Summary** 1. The Agent Experience (AX) framework on this site has three connected pieces: a five-part field map, a four-step method and the Open Agent-Readiness Rubric. 2. The field map follows an agent through orient, discover, act, collaborate and learn, and it is ordered by dependency, so a failure to orient can show up as a failure to act. 3. The method picks one real workflow, maps its agent-facing surface, finds the decisive moments and ends in a product change rather than a document. 4. The rubric checks one real job across six tracks and gives a profile, not a score, and it predicts nothing about agent success. 5. The framework is not a standard, not a benchmark and not Ax, the unrelated open-source LLM framework for TypeScript. 6. Start small: walk one workflow through the map until a part visibly breaks, make one change, then check that job with the rubric. The AX framework is three connected tools for finding where AI agents get stuck in your product: a five-part map, a four-step method, and a rubric that gives one job a profile across six tracks, each rated at one of four levels. 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 framework is three pieces: a five-part [field map](/research/) of where agent work breaks, a four-step [method](/method/) for using it on one real workflow, and the [Open Agent-Readiness Rubric](/insights/agent-readiness-rubric/) for checking how ready one job is. The map says where to look, the method says how to look, and the rubric says which parts of one job are ready. All three pieces already exist on this site. This page puts them side by side and says how they connect and what they do not do. Looking for Ax, the open-source TypeScript library for building with language models? That is a different project. See the [short section about it below](#is-this-the-ax-framework-on-github). ## What is a framework for, in AX work? A framework here predicts nothing. It does one modest thing: it gives a team a shared place to put what they find. The typical failure in early AX work comes after a team has observed 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): there is no structure that says which of those is the same kind of problem as which. So findings stay anecdotes, argued about and then forgotten. The three components below are chosen for that job. Each answers a different question, and the answers fit together: | 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 without trying to fix everything at once? | One workflow, walked end to end | | **[The rubric](/insights/agent-readiness-rubric/)** | Can an agent do this job, and can the person trust it? | A profile of six levels for one job | None of the three is a score of how well an agent will do, as [its own section](#what-this-framework-does-not-claim) explains. ## 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. Its 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? [legible documentation for agents](/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 an agent can act on](/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 locations, not a maturity ladder: nobody graduates from orientation. Find the one where your workflow is currently failing and go there. Two properties make the map usable. **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.** 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 it deliberately 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 is finished when it ends in an edited tool description, an added approval step, a narrowed permission, or a new recovery route, and not when it ends in a document. The method and the map work together: the method picks the workflow and walks it, and 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. The rubric turns one workflow you have walked into a clear record of how ready it is. [The Open Agent-Readiness Rubric](/insights/agent-readiness-rubric/) checks one job across six tracks: Find, Read, Act, Recover, Hand back and Boundaries. Each track gets one of four levels, from Not yet to Shown, by a fixed rule. Anything that should stop you, such as a payment that can be charged twice, is reported first. There is no total score. The rubric fits the method in two places. The job it checks is the workflow you chose in step one. Its top level, Shown, needs the same repeated runs you use to watch that workflow. It predicts nothing about agent success. It shows which parts of one job are ready, and what to fix first. ![The AX framework in use, as four method steps from top to bottom, from a job people already want to delegate to one product change. 1. Choose a real workflow. 2. Map the agent-facing surface, where the rubric rates each part of the job. 3. Find the decisive moments, where the field map names the part: orient, discover, act, collaborate or learn. 4. Turn the learning into product work, highlighted as the step teams skip, which ends in one product change filed next to the part it fixes.](https://agentexperience.tech/diagrams/framework-in-use.svg) *Figure: The method walks one workflow; the rubric and the field map sit beside the steps where they help.* 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, while this rubric looks at one job and has no number to convert. This page does not rank them. ## Is this the Ax framework on GitHub? No. The name is worth clearing up, 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 are not competitors, and not really in the same category either: 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. For all five senses of the phrase side by side, including the real-estate and insurance uses, see [what agent experience means in each field](/insights/meanings-of-agent-experience/). ## What this framework does not claim - **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 has no total score on purpose. - **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, record that it does not fit. What it does claim is narrower: that a team walking one workflow through five named parts, with a method that ends in a product change and a rubric that profiles one job, 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 check that job with [the rubric](/insights/agent-readiness-rubric/), to see which parts are ready and what to fix first. 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. If you are deciding whether this could be a job in its own right, [what an AX engineer does](/insights/what-does-an-ax-engineer-do/) reads the public job postings and team pages for the role. ## 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, which gives a profile of one job: can an agent do it, and can the person trust what happened? The map says where to look, the method says how to look, and the rubric says how ready one job is. **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. **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. The framework promises nothing about outcomes. It gives a team a shared place to put what it learns, so the next person can find it.