Agent Design Patterns
Five UI patterns for how an AI agent shows its work, states its confidence, and knows when to stop. Each pattern runs on real code connected to the Claude API.
- Every demo loads a captured response instantly. Click the ‘Run live’ button to call Claude fresh and watch it run again in real time. Confidence badges always include a reason.
Pattern 01 - Reasoning Trace
The agent is working. You are waiting.
A spinner tells you the agent is busy. It does not tell you if the agent understood the task, if it is about to waste four minutes, or where it got stuck. This pattern shows you what each step produced instead of a label saying the step happened. You see the themes it pulled out and how it grouped them, so a wrong turn is easy to spot and cheap to catch.
Failures work the same way. The connector breaks at the step that failed. The message states exactly what stopped and what never ran. Use the toggles below to break a run on purpose and watch it happen.
Reading survey data
15 free-text responses
Identifying patterns
- checkout process speed
- support responsiveness and issue resolution
- app reliability and bugs
- order history and dashboard usability
- pricing transparency
- complaint follow-up handling
- search functionality
- onboarding and setup experience
- refund processing time
- subscription cancellation friction
- proactive customer communication
Drafting summary
- 1. Support and complaint handling issues (6 responses)
- 2. App and technical reliability problems (3 responses)
- 3. Checkout, refunds, and pricing friction (3 responses)
- 4. Positive dashboard and order history experience (2 responses)
- 5. Onboarding experience (1 response)
Complete
Support experience is inconsistent, with complaint escalation and follow-up being a bigger pain point than initial responsiveness, since customers cited repeated issue re-explanation, unresolved complaints, and forced call-ins alongside praise for quick chat resolution and direct messaging.
Medium confidenceBasis: sample volume — 5 of 15 responses touch support/complaints, but they split between positive and negative experiences, suggesting the issue is about handling consistency rather than a uniform failure.Checkout and post-purchase financial flows (pricing clarity, refunds, cancellation) create friction that risks cart abandonment and customer frustration.
High confidenceBasis: sample volume — 4 of 15 responses independently describe distinct pain points across checkout, pricing, refunds, and cancellation, indicating a consistent theme rather than an isolated complaint.Core app reliability issues, particularly crashes during receipt upload and unreliable payment info storage, should be prioritized as they directly block task completion.
Medium confidenceBasis: sample volume — Only 2 responses mention app crashes and payment save failures, but both describe functional failures rather than mere annoyances, warranting elevated concern despite limited volume.Recent dashboard and order history updates are landing well with users and should be preserved or extended in future redesigns.
Medium confidenceBasis: sample volume — 2 of 15 responses independently praise the same dashboard/order history update, a small but consistent positive signal.Search functionality may be an underlying usability gap contributing to broader frustration, though this is based on a single mention.
Low confidenceBasis: sample volume — Only 1 of 15 responses mentions search, so this insight rests on a single data point and needs further validation before action.
Simulate a failure at step
Showing a captured example
Pattern 02 - Confidence Signal
The agent has an answer. Some parts are shakier than others.
When every insight looks equally certain, people trust all of them or none of them. Both are a problem. An insight backed by twelve responses should not look the same as one guessed from two. This pattern keeps two things separate: how sure the model is, and why. “Twelve of fifteen people said this” and “I think this is true but I am not fully sure” are different claims. Folding them into one score hides that difference.
Click any badge to see the reason behind it. If confidence is low, a button sends the item to a person instead. That is where Pattern 05 picks up.
Showing a captured example
Pattern 03 - Confirmation Gate
The next action cannot be undone.
Most confirmation popups do not help. “Are you sure?” does not tell you what you are agreeing to. This one names the exact thing about to happen. You can edit the draft before it sends, so you are not stuck choosing between sending something slightly wrong or scrapping good work.
Discard and Send look the same on purpose. Nothing pushes you toward confirming. Once you send it, you see exactly what went out and when. You never wonder if it worked.
“Nobody followed up after my complaint about the damaged item.”
This reply apologizes for the lack of follow-up and commits to escalating the customer's complaint to the support team for direct outreach, without specifying an order, refund, or employee name.
Showing a captured example
Pattern 04 - Correction & Override
The agent decided. The reviewer disagrees.
If people cannot correct an agent where it made the mistake, they fix it somewhere else and stop telling anyone. You lose the fix and the fact that a fix was needed. Every category here comes from the same fixed list the model uses. No new categories get invented on the fly.
When someone edits a note or a category, the interface says “Captured for improvement,” not “the model has learned this,” because it has not. That distinction is what makes these corrections useful data later instead of an empty promise.
Refund process took over three weeks, way too slow for the amount.
The mobile app crashes every time I try to upload a receipt for a return.
I had to explain my problem three times to three different agents.
Nobody followed up after my complaint about the damaged item.
Cancelling a subscription requires calling in, which feels intentional and frustrating.
Corrections are recorded for review. Nothing here retrains a model, and the interface doesn’t suggest otherwise.
Showing a captured example
Pattern 05 - Escalation & Handoff
The agent has reached the edge of what it can decide alone.
Sometimes the right move is to stop and hand the decision to a person. That works only if the handoff includes enough to act on. A queue that says “escalated” is not helpful. Someone still has to piece together what happened before they can do anything.
Each item here shows the reason it landed in the queue, the original data, and what the agent tried to do. Seeing the wrong answer, not only knowing one exists, is what makes the right call obvious. The buttons reuse the same actions from Patterns 03 and 04. When the queue is empty, it says so clearly instead of showing nothing.
3 items awaiting review
From Confidence Signal
Low confidence, self-assessed — 2 of 15 responses
- Original data
- 9. Search never finds what I'm looking for, I have to scroll through everything. 4. Loved how easy it was to find my order history, very intuitive.
- What the agent produced
- Insight: "Search relevance is the primary discovery blocker." confidence: low · basis: self_assessed Rationale: Only two responses touch discovery and they contradict each other — one praises finding order history, one calls search unusable. Distinguishing "search is broken" from "search is fine but browse is better" needs more data than this sample holds.
From Correction & Override
Category ambiguous — two candidates scored equally
- Original data
- 15. Cancelling a subscription requires calling in, which feels intentional and frustrating.
- What the agent produced
- category: Account Management note: "Cancellation requiring a phone call is an account management process complaint." The response describes a retention pattern the customer reads as deliberate. The agent settled on Account Management without flagging an alternate category here, though earlier draws have named Support Experience as the closer runner-up — the ambiguity is real even when a given draw doesn't spell it out.
From Confirmation Gate
Flagged by reviewer — draft implies compensation not authorised
- Original data
- 8. Nobody followed up after my complaint about the damaged item.
- What the agent produced
- Draft reply: "You reported a damaged item and then heard nothing from us — that follow-up should have happened and it didn't. I've reopened your case and assigned it to a specialist who will contact you within one business day with a resolution." The reviewer stopped this at the gate: "a resolution" reads as a promised refund or replacement, and nobody has approved either.
These three items are seeded rather than generated — a review queue is a handoff surface, not something a model produces, so there is no live run for this pattern.
Showing a captured example
One Lifecycle
An agent shows its work while running (01). It grades its own output honestly when finished (02). It stops before anything irreversible (03). It accepts correction after a mistake (04). It hands off what it should not decide alone (05).
Each pattern produces the input the next one needs. A low-confidence insight from 02 and a draft stopped at the gate in 03 both turn up in 05’s queue, carrying the reason they arrived.
Every pattern earns trust the same way: by staying clear about its limits. Each one is a place where the interface could hide something and shows it instead: a step, a shaky inference, a consequence, a mistake, an edge case. The same logic runs the note that tells you whether a result is cached or live.
A longer written case study on building these will follow. It is not part of this page yet.