01What is an agent-first design pattern?
A pattern, in the classical Christopher Alexander sense, is a recurring solution to a recurring problem in a recurring context. The eight patterns introduced in the master Agent-First Design guide — activity stream, approval queue, confidence ribbon, escape hatch, permission scope, memory editor, audit trail, intervention point — are the highest-frequency primitives. They show up in every agentic product that earns trust. But they are not the complete vocabulary.
This catalog extends that vocabulary to twenty-four patterns, grouped by the design problem they solve. The patterns are not a style guide and not a component library. They are interface contracts: each one describes a shape the user expects, a behavior the agent must honor, and a failure mode the design prevents. A pattern is correct when an experienced operator can use the product without onboarding, and incorrect when the same operator is surprised, lost, or unable to recover.
Patterns are interface contracts. The agent does its job, the human does theirs, and the pattern is the line that separates them.
02Why a pattern catalog matters now
Three things are true about agent-first design in 2026.
The primitives are converging. After hundreds of agentic products, the same shapes keep appearing under different names. What Linear calls a "queue" and what Notion calls an "inbox" and what Cursor calls a "diff view" are all the same pattern — approval queue. Naming them once, defining them precisely, and reusing them across products is how the discipline matures.
The bad versions are converging too. The same anti-patterns keep appearing: confidence as a raw percentage, escape hatches buried in settings, memory exposed as a chat transcript, autonomy as a global toggle. Naming the failure modes is half the prevention.
Teams are building component libraries before they have patterns. Most product teams jump from copilot to component library — they design "the agent's button" and "the agent's badge" without first defining what the agent's button means. A pattern catalog is the missing layer between behavior and component. Behavior tells you what the agent does. The component tells you what it looks like. The pattern tells you what the user is allowed to expect.
03How to read this catalog
Each pattern is described against five fields: problem (what goes wrong without it), shape (what the user sees), contract (what the agent and the human each owe), failure mode (the most common bad version), and maturity (how settled the pattern is across the industry).
The patterns are grouped into four families:
| Family | What it governs | Patterns |
|---|---|---|
| Trust | Whether the user believes the agent | Confidence ribbon, source citation, reasoning trace, calibration cue, dissent surface, version diff |
| Control | What the agent is allowed to do | Permission scope, autonomy spectrum, escape hatch, kill switch, dry-run mode, budget governor |
| Memory | What the agent knows and remembers | Memory editor, context inspector, identity card, forget control, scope boundary, recall trace |
| Orchestration | How multiple agents and humans coordinate | Activity stream, approval queue, intervention point, audit trail, hand-off, parallel session view |
A mature agent-first product uses most of these. A confused one uses two or three and bolts the rest on at the end.
04The trust family
Trust patterns answer the user's first question of any agent output: why should I believe this? They make the agent's reasoning, sourcing, and uncertainty legible.
Confidence ribbon
A calibrated visual cue attached to every agent output, paired with a one-tap "why." Not a percentage. Three or four levels, color-coded, with a reason behind each one. The user learns the agent's reliability across categories over time.
Source citation
Inline references to the documents, records, conversations, or models the agent drew from. Hover to peek, click to inspect. Citations should survive the session, the export, and the audit.
Reasoning trace
A collapsed-by-default view of the chain the agent followed: what it considered, what it ruled out, where it branched. Designed for the moment after a surprise output, not for steady-state use.
Calibration cue
A signal that tells the user how often the agent has been right at this confidence level on this task. Reframes confidence from "the agent's feeling" to "the agent's track record."
Dissent surface
A place for the agent to say "I would not have made this choice." Used when the human overrides an agent recommendation. Quiet but visible. Prevents the agent from rubber-stamping bad decisions.
Version diff
When the agent edits, the user sees what changed against what existed before. Word-level, field-level, or structural diffs. Without this, the agent's edits are silent — and silent edits are the fastest way to lose trust.
05The control family
Control patterns answer the user's second question of any agentic product: what is the agent allowed to do, and how do I stop it? They define authority, scope, and reversibility.
Permission scope
Granular controls on what the agent can read, write, send, schedule, and spend. Inspectable in one place, revocable in one click. The constitution of the agent.
Autonomy spectrum
A per-responsibility setting that places each agent action somewhere between "human-only" and "autonomous." Documented in the master discipline; the pattern is the visible interface for moving up and down it.
Escape hatch
A persistent, predictable way for the human to take over a single action. Always one click. Always visible. Always unambiguous about what it cancels. Distinct from the kill switch.
Kill switch
The product-wide off. Stops every agent action in flight, unwinds what can be unwound, freezes the rest. Treated as an emergency, designed for clarity under pressure.
Dry-run mode
A way for the agent to do the work without committing it. The output is real, the side effects are not. Lets the user evaluate the agent's behavior on a new task before granting autonomy.
Budget governor
A visible, hard cap on what the agent can spend — money, tokens, API calls, time. Soft alerts before, hard stops at. The kill switch for resources rather than actions.
06The memory family
Memory patterns answer the user's third question: what does the agent know about me, and how do I correct it? They make the agent's context visible and editable.
Memory editor
An inspectable, editable view of what the agent has stored about the user, the work, and the relationships. Without it, the agent is permanently alien. With it, the agent becomes a colleague.
Context inspector
A view of what the agent loaded into context for this specific action. Different from the memory editor: memory is long-term, context is per-task. Both must be visible.
Identity card
A user-facing summary of who the agent thinks the user is — role, preferences, recent work, key relationships. Editable in place. The agent's working model of the person.
Forget control
A specific, predictable way to make the agent forget something. Single fact, conversation, time window, or category. Audit logs survive; the working memory does not.
Scope boundary
A visible line between what the agent remembers across sessions and what it forgets at session end. Without this boundary, users cannot reason about privacy or accuracy.
Recall trace
When the agent acts on a memory, it shows which memory. "I'm prioritizing this because you told me last Tuesday that..." Recall trace makes memory falsifiable.
07The orchestration family
Orchestration patterns answer the user's fourth question: how do I see what the agent — or agents — are doing, and how do I coordinate with them? They govern flow, hand-off, and accountability.
Activity stream
A live, append-only log of what the agent is doing right now. Time-ordered, scannable, pause-able. The replacement for the static dashboard.
Approval queue
A focused inbox of actions waiting for human review. Each item is one decision: approve, reject, edit. Volume is the diagnostic.
Intervention point
A planned moment in the agent's workflow where it stops, surfaces context, and asks the human a question it cannot resolve alone. Designed in advance — not an error state.
Audit trail
An immutable history of decisions, sources, and outcomes. Designed as a surface, not stored as a log file. Survives the session and the user.
Hand-off
The pattern for transferring work between agents, or between an agent and a human. Includes context, state, current confidence, and the reason for the transfer. The most under-designed pattern in multi-agent systems.
Parallel session view
When multiple agents are working at once — or one agent is working on multiple tracks — a view that shows them in parallel rather than collapsed into a single timeline. The mission-control surface.
08Mapping patterns to control modes
Patterns are not optional based on taste. They are required based on where the agent sits on the autonomy spectrum. Every step up the spectrum demands additional patterns.
| Autonomy mode | Required trust patterns | Required control patterns | Required orchestration patterns |
|---|---|---|---|
| Human-only | Confidence ribbon, reasoning trace | Permission scope | Activity stream |
| Approve-each-action | + source citation, version diff | + escape hatch | + approval queue |
| Review-before-act | + dissent surface | + dry-run mode | + intervention point |
| Act-and-notify | + calibration cue | + budget governor | + audit trail |
| Autonomous | All of the above | + kill switch | + hand-off, parallel view |
Read the table as a build order. A product moving an agent up the spectrum does not need new model capabilities — it needs new patterns. Skipping a pattern at a given autonomy level is the most reliable predictor of stalled trust.
09The pattern catalog checklist
Before shipping an agent-first feature, run it through this checklist. Each row is a question the catalog answers — and a question users will ask of the product the first time it surprises them.
- For every agent output, the user can find a confidence cue and a reason.
- For every claim the agent makes, the user can find the source it drew from.
- For every edit the agent makes, the user can see what changed and what existed before.
- For every agent action, the user has a one-click escape hatch.
- The product has one kill switch and the user can find it without searching.
- The agent's memory is editable, scoped, and forgettable.
- Every agent action is in an activity stream or an approval queue — not both, not neither.
- Every multi-agent hand-off has a visible context envelope.
- Every autonomy level has the patterns the table above requires.
- The same word means the same thing on every screen.
10The five most common pattern mistakes
After dozens of catalog reviews, the same five failure patterns keep recurring. They are not failures of any individual pattern — they are failures of pattern discipline.
1. Reinventing every pattern per feature
A team designs the approval queue for the email agent, then designs a different approval queue for the meeting agent, then a third for the support agent. Three patterns now exist where one should. Users have to relearn the product every time they meet a new agent.
2. Skipping the trust family
Teams ship control patterns and orchestration patterns and call it agent-first. Without confidence cues, source citations, and reasoning traces, the product is a remote control for a black box. Trust patterns are not optional.
3. Memory as a chat transcript
Most products expose "memory" by showing the conversation history. That is not memory — that is logs. A real memory editor surfaces the abstractions the agent has formed about the user, not the raw text it has seen.
4. One escape hatch for the whole product
A single global "stop" button cannot tell the user what it stops. A real escape hatch lives next to the action it cancels, names what it will unwind, and survives the agent's denial that it was working on anything important.
5. Patterns without a contract
A pattern is not a component. A component is reusable code; a pattern is a reusable expectation. When teams skip the contract — what the user expects, what the agent must honor — the pattern degrades into decoration and the product loses the trust the pattern was supposed to build.
11When to hire an agent-first design partner
Pattern discipline is the difference between an agentic product that earns trust on first use and one that loses it on first surprise. Teams that have shipped two or three agentic features and feel the inconsistency are in the right moment to systematize. Teams that have not yet shipped are in the right moment to start from the catalog rather than discover it.
auxfirst runs three engagements aligned to pattern work: a Blueprint Sprint for teams designing their first agent-first surfaces and choosing the patterns to commit to, an Agent Experience Audit for teams whose shipped agentic features are inconsistent across the product, and an ongoing Advisory Retainer for teams maintaining a pattern catalog at scale.
Codify your agent-first pattern language in three weeks.
A focused engagement that produces a pattern audit of your shipped surfaces, a custom catalog of the patterns your product needs, a control-to-pattern mapping for each agent responsibility, and a ready-to-build specification for the next surface.