# AX Workflow Review brief

Use this brief to review one agent workflow. It is a working template, not a scorecard and not a prediction that a product will rank, be cited, or succeed with every agent.

**How to use it:** fill it out for one task, attach only shareable artifacts, and turn the highest-friction finding into one product change plus one follow-up test.

## 1. Workflow scope

| Field | Notes |
| --- | --- |
| Workflow name |  |
| Person delegating the work | Role or audience, not a real customer name. |
| User goal | What the person wants done. |
| Agent starting context | What the agent receives before it begins. |
| Success criteria | Observable end state. What would make the run acceptable? |
| Stop / ask condition | When should the agent pause, ask, or return control? |
| Out of scope | What this review will not inspect. |

## 2. Surfaces the agent depends on

List only the surfaces this workflow touches.

| Surface | Artifact or URL | Owner | What the agent needs from it | Current risk |
| --- | --- | --- | --- | --- |
| Discovery | Sitemap, docs index, search result, ARD, llms.txt, README, app navigation |  | Can find the right path without guessing. |  |
| Retrieval | Docs page, Markdown twin, help article, API reference, schema, example |  | Can pull the needed context in a usable form. |  |
| Tool execution | MCP tool, function, endpoint, CLI command, form, API operation |  | Can choose the right action and supply valid inputs. |  |
| Approval | Permission gate, confirmation step, policy check, plan review |  | Knows what is allowed and what needs human consent. |  |
| Recovery | Error message, retry route, fallback tool, escalation path, run history |  | Can make a different next attempt or stop usefully. |  |
| Handoff | Summary, artifact, ticket, audit log, next decision, owner |  | Returns work in a form a person or system can trust. |  |

## 3. Run record to collect

Do not include credentials, customer data, private traces, or confidential operational detail in a public copy of this brief.

- Task ID or scenario name:
- Model / agent / harness version if relevant:
- Date of run:
- Starting prompt or user request summary:
- Tool calls in order, with inputs redacted if needed:
- Human interventions and why they happened:
- Retries, including what changed between attempts:
- Terminal state: success, partial progress, refused, unsafe, or blocked:
- Evidence attached: screenshots, logs, docs links, diffs, or transcript excerpts that are safe to share internally:

## 4. Failure map

Mark the first visible failure, then mark downstream effects separately. Avoid collapsing every issue into “the model failed.”

| Stage | Diagnostic question | Observed failure | Evidence | Severity | Candidate owner |
| --- | --- | --- | --- | --- | --- |
| Discovery | Could the agent find the right path or capability? |  |  | Low / Medium / High |  |
| Retrieval | Did the agent retrieve the context it needed? |  |  | Low / Medium / High |  |
| Tool choice | Did it choose the right tool or action? |  |  | Low / Medium / High |  |
| Tool inputs | Were required fields, constraints, and side effects clear? |  |  | Low / Medium / High |  |
| Approval | Was permission scoped, enforced, and auditable? |  |  | Low / Medium / High |  |
| Recovery | Did the failure response support a better second attempt? |  |  | Low / Medium / High |  |
| Handoff | Could a person trust and continue from the returned work? |  |  | Low / Medium / High |  |

## 5. Prioritized change / test record

Choose the smallest change that addresses the highest-friction decision point. Treat the next run as a learning check, not proof of universal improvement.

| Priority | Finding | Product change | What should change in the next run | How to test | Owner | Status |
| --- | --- | --- | --- | --- | --- | --- |
| 1 |  |  |  |  |  |  |
| 2 |  |  |  |  |  |  |
| 3 |  |  |  |  |  |  |

## 6. Review notes

- What did the agent do that surprised the team?
- Which surface was clearer than expected?
- Which surface was present but not useful?
- Which ambiguity should become documentation, schema, UI copy, permission logic, or an eval case?
- What should not be generalized from this one review?

## 7. Next action

- One change to make now:
- One regression or replay case to keep:
- One open question to resolve before expanding scope:
- Date to re-run the workflow:

Related Agent Experience references:

- AX review method: https://agentexperience.tech/insights/run-an-ax-review/
- Measurement guide: https://agentexperience.tech/insights/measure-agent-experience/
- Open Agent-Readiness Rubric: https://agentexperience.tech/insights/agent-readiness-rubric/
- Machine-readable rubric JSON: https://agentexperience.tech/agent-readiness-rubric.json