Use this playbook when you are auditing or shipping an agent run in a real product—not when you need the full framework thesis. Scope one flow, walk the lifecycle, log gaps, then spec the highest-risk pattern using the gallery.
Start from a symptom
Pick the symptom closest to what you are seeing in your product, then open the linked patterns before you run a full audit.
Users are surprised by what the agent didBefore the agent acts
Open these patterns in the gallery, then continue to the agent-flow audit below.
A scoped review of one representative run—modeled on heuristic evaluation: prepare, walk the flow twice, then prioritize.
1. Prepare
Narrow scope before you open every pattern page. One representative agent run is enough for a useful first audit.
Pick one user task (e.g. research report, multi-file refactor, support resolution).
Note stakes: reversible edits vs send/deploy/purchase.
Note autonomy: suggestions only, plan-then-run, or auto-run with gates.
Note duration: seconds vs minutes vs background work while away.
Copy the issue card template below when you log gaps.
2. Walk the run
Move through the product twice—first to learn the flow, then to audit against the lifecycle checklist in the next section.
Pass 1 (15–30 min): complete the happy path as a new user; do not score yet.
Pass 2 (45–90 min): repeat with edge cases—cancel, edit plan mid-run, deny permission, failure, return after background work.
For each gap, record where in the run it appears and which lifecycle phase it belongs to.
3. Prioritize and pick one pattern
Cluster similar gaps, then ship one pattern at a time starting with the highest-risk trust or safety gap.
Critical — blocks task completion or causes irreversible harm without recovery.
Major — erodes trust or causes repeated rework; users hesitate to delegate again.
Minor — friction or confusion, but users can still succeed with effort.
Cosmetic — polish; defer until core lifecycle gaps are addressed.
Open the linked pattern page for your top gap and use it as the spec for design and eng.
Issue card template
Copy into your doc, FigJam, or ticket when you log a gap.
Agent-flow finding
Flow: [e.g. Deep research from composer]
Phase: [Before | While | After]
Location: [screen / step where the gap appears]
What happened: [what the user saw or could not see]
Expected pattern: [e.g. Intent Preview, Progress Ledger]
Severity: [Critical | Major | Minor | Cosmetic]
Evidence: [screenshot, clip, or quote]
Lifecycle checklist
During pass 2 of your audit, answer these questions. If the answer is no, open the linked pattern.
Before the agent acts
Before compute-heavy or irreversible work, can users see a scannable plan they can approve or edit?
When the goal is ambiguous, does the agent ask a small number of structured questions—not an open-ended interview?
Is the current autonomy mode visible, and are new scopes or tools gated with a clear allow/deny?
Do users know what will run automatically vs what still needs their start action?
For high-stakes changes, is there a preview environment before anything goes live?
While the agent works
During long runs, is there a live step list (not only a spinner) with links to artifacts?
Can users expand why the agent made a key choice, tied to named inputs or sources?
When the agent generates fit-for-task UI (forms, charts, controls), is it accessible, labeled, and predictable?
Can users stop, edit the plan, or correct course without abandoning the run?
For potentially destructive work, is the agent operating in a sandbox the user can preview before promoting?
When stakes rise mid-run, can the agent pause and offer human help with context?
After the agent acts
Is there a chronological record of what the agent changed, with who/when?
Can users undo or restore to a checkpoint for the changes that matter most?
Before confirming irreversible actions, is undo or a time-limited cancel offered?
On edge cases or policy limits, does the agent escalate with transcript and fields—not loop forever?
After external side effects, is it clear what cannot be undone and what support path exists?
When users return after time away, is there a briefing that surfaces what ran, what needs approval, and what failed?
From audit to shipped UI
Turn findings into UI
Each pattern page is a small implementation spec. Use anatomy and Do/Avoid as acceptance criteria; use the interactive mockup and production screenshots as evidence for design reviews and eng handoff.
Definition — what the pattern is
When to use — user problem and a concrete scenario
Anatomy — checklist of UI pieces to include
Guidance — Do and Avoid lists
Example UI — interactive mockup you can adapt
In production — annotated screenshots with designer critique
Ship one pattern at a time
Borrow the iterative adoption mindset from large design systems: prove value in one flow before re-platforming the whole agent experience.
Start with the highest-severity gap from your audit—not the easiest pattern to build.
Prototype one pattern in isolation (one screen or one run segment) before refactoring the whole agent shell.
Compare your draft to the production examples on the pattern page; note what you are intentionally not shipping yet.
Document limitations from the pattern page in your PRD so PM and eng know known tradeoffs.
Each pattern ships as a self-contained `.txt` file under `/llms/patterns/`. Point your agent at the index or specific patterns before implementing agent UI—so anatomy, limitations, and anti-patterns land in the spec instead of being reinvented.
Deployed prompt
Before implementing agent UI for [feature], read the Agentic UX pattern guidance:
1. Index: https://agentic-ux.com/llms.txt
2. Pattern file: https://agentic-ux.com/llms/patterns/[pattern-id].txt
Use the pattern definition, anatomy, limitations, do/avoid, and production examples
when designing and building. Prefer lifecycle patterns from the index over inventing
new interaction models.
Llms.txt
`llms.txt` is the machine-readable index of every pattern—titles, lifecycle phase, and links to full `.txt` specs. Open it in the browser to browse, or paste the index URL (and a `/llms/patterns/{id}.txt` URL for the pattern you are building) into your coding agent so anatomy, limitations, and anti-patterns land in the implementation spec.