Most teams shipping agentic products in 2026 hit the same wall: the model works, the demo dazzles, the production users churn in three sessions. The reason is rarely the model. It is the design surface around the agent that fails. Planning steps are invisible, tool calls happen off-screen, memory is opaque, errors return silent, and the handoff back to the human feels like an interruption instead of a baton pass.

This playbook is the seven-step process the AY Design team uses when we work on agentic products with founders building on the Vercel AI SDK, LangGraph, Anthropic's Claude SDK, or OpenAI's Agents API. The steps are ordered. Skipping any one of them shows up in retention.

TL;DR, the seven steps are: define the agent's job to be done, design the planning surface, expose tool calls, make memory legible, score every action with confidence, route fallbacks and human handoff explicitly, and instrument trust with a feedback loop.

The 7-step playbook: a brief overview

• Step 1, Define the JTBD: scope the agent to one bounded outcome, not "anything the user wants".

• Step 2, Design the planning surface: render the plan as a visible artifact the user can edit before execution.

• Step 3, Expose tool calls: surface every external action the agent takes with status, inputs, and outputs.

• Step 4, Make memory legible: show what the agent remembers, why, and how to forget it.

• Step 5, Score actions with confidence: attach a confidence signal to risky steps so users know when to verify.

• Step 6, Route fallbacks and handoff: design the path back to a human or a deterministic flow when the agent stalls.

• Step 7, Instrument trust: capture thumbs, edits, and reverts as first-class telemetry, not buried analytics.

Scoring matrix: rate your agent against the seven steps

Use this matrix as a self-assessment. Score each step from 1 (not addressed) to 5 (clearly designed and instrumented). Anything under 3 is a design debt item.

1. Step 1, Define the agent's job to be done

Defining the JTBD is the act of scoping the agent to one bounded outcome that maps to a specific user goal and a specific success metric. Most agentic products fail this step because the team confuses "the model can do anything" with "the product should try to". The model can. The product should not.

Devin is the cleanest example. It is positioned as an AI software engineer that picks up a ticket, opens a PR, and asks for review. That is one job. The UI, the planning step, the tool surface, the handoff back to a human reviewer, all derive from that single sentence. Compare that to a "general AI assistant" surface where the user has to invent the use case every session.

Design moves at this step

• Write the JTBD as a single sentence the team agrees on.

• Pick one primary persona and one secondary. Reject the third.

• Design the empty state around three concrete first-run tasks, not a blank prompt.

• Make the agent refuse out-of-scope requests with a routed suggestion ("this is outside what I do, here is what to use instead").

• Tie one north-star metric to the JTBD (PR merge rate, meeting notes accepted, deal sourced).

Anti-pattern: shipping an open prompt box with no examples and hoping users figure out the use case. They will not. They will compare you to ChatGPT and leave.

2. Step 2, Design the planning surface

A planning surface is a visible artifact, usually a list of steps, that the agent generates before execution and the user can review or edit. The pattern was popularised by Claude Code and Replit Agent and has become the default for any multi-step agent in 2026.

The reason it works: agentic products move from prompt to result in 30 seconds to 20 minutes. Without a visible plan, the user has no checkpoint between intent and outcome. The planning surface is the checkpoint. It lets the user confirm the agent understood the request, catch hallucinated assumptions early, and edit scope before tokens get spent.

Design moves at this step

• Render the plan as a numbered list of discrete steps, not a paragraph.

• Allow inline editing of each step before run.

• Show step status during execution (pending, running, complete, failed, skipped).

• Let the user pause mid-plan and inject a correction.

• Persist the plan as an artifact the user can re-run or fork.

What "good" looks like: Claude Code shows the plan as a checklist, marks each item complete in real time, and lets the user interrupt with a follow-up that gets folded into the active plan. Replit Agent shows the same surface for a different JTBD (build an app instead of edit a repo). Both treat the plan as a first-class UI object, not a debug view.

3. Step 3, Expose tool calls

A tool call is the agent invoking an external function: writing a file, hitting an API, running a query, sending an email. Exposing tool calls means surfacing what was called, with what arguments, what came back, and how long it took. This is non-negotiable for trust.

The classic anti-pattern is the universal spinner. The agent does something for 40 seconds, the user sees a pulse, and the result appears. Users have no idea what just happened, what got mutated, what API got billed, or whether the action is reversible. Cursor and Claude Code both solved this by making the tool log a permanent part of the conversation, not a sidebar.

Design moves at this step

• Render each tool call as a collapsible card with name, arguments, result, and duration.

• Distinguish read tools (search, fetch) from write tools (edit, send, deploy) with color and iconography.

• Require explicit confirmation for write tools above a configurable risk threshold.

• Show a diff preview before file edits land.

• Make every tool call linkable. Users will share them in Slack to debug.

Real reference: Cursor's "Composer" surface shows file edits as inline diffs the user accepts or rejects per chunk. The tool call is the diff, the diff is the tool call. The two are not separated.

4. Step 4, Make memory legible

Memory legibility is the practice of showing the user what the agent remembers about them, why it remembered it, and how to forget it. This is the surface that turns "spooky personalization" into "useful continuity".

ChatGPT's memory panel is the canonical reference. When ChatGPT writes a memory ("you live in Berlin, you prefer brevity"), it surfaces a chip in the conversation that links to a memory list. The user can delete, edit, or pause memory at any time. That single UI moves the feature from creepy to controllable.

Design moves at this step

• Inline notification when a memory is written ("I'll remember that").

• Visible memory list with timestamps, source conversation, and delete control.

• Project-scoped memory separate from global memory.

• Clear differentiation between short-term context (current session) and long-term memory.

• One-click "forget everything from this conversation" exit ramp.

Compliance note: in regulated markets, memory legibility is also how you satisfy GDPR and the EU AI Act's transparency obligations. Designing it now is cheaper than retrofitting it after legal review.

5. Step 5, Score actions with confidence

Confidence scoring is attaching a per-claim or per-action signal that tells the user how sure the agent is. Without it, every answer reads with the same authority, which trains users to either trust everything or trust nothing.

Perplexity's per-sentence citation is the strongest pattern. Each claim ties to a source. Users learn quickly which claims are well sourced and which are stitched together. Granola applies the same idea to meeting notes: action items and decisions cite the timestamp they came from.

Design moves at this step

• Cite sources at the claim level, not the response level.

• Mark low-confidence claims with a distinct visual ("verify this").

• For RAG products, show the retrieved chunks the answer is grounded in.

• For action-taking agents, show pre-flight checks (dry run, simulation) before risky writes.

• Distinguish "the model is uncertain" from "the source is uncertain".

Honest trade-off: too much uncertainty UI erodes confidence in the product itself. Reserve the strongest visual cues for genuinely risky claims, not every sentence.

6. Step 6, Route fallbacks and human handoff

Fallback design is the explicit path the agent takes when it cannot finish the job. Handoff design is the path back to a human or a deterministic system. Most agentic products skip this step and end up with agents that loop, stall, or apologise indefinitely.

Aider, the open-source coding agent, exits cleanly when it cannot apply a patch and returns control to the user with the partial state intact. Cody routes ambiguous questions to a structured search instead of guessing. The common pattern: detect the stall, name it, and offer a concrete next step that is not "try again".

Design moves at this step

• Detect stalls programmatically (repeated tool calls, no progress on plan, hitting a token ceiling).

• Surface the stall to the user with a named reason, not a generic error.

• Offer a routed exit: "switch to manual", "escalate to support", "ask a human teammate".

• Preserve the agent's state when handing off so the human picks up with full context.

• For B2B products, integrate handoff into the existing ticketing or escalation flow (Linear, Zendesk, Slack).

7. Step 7, Instrument trust with a feedback loop

Trust instrumentation is the product analytics that tell you whether the agent is earning trust over time. Token counts and session counts do not. The signals that matter are acceptance, edit distance, and revert rate.

GitHub Copilot popularised the acceptance rate as the headline metric for code suggestions. It is the percentage of suggestions the developer accepts without editing. It correlates with retention better than any other surface metric. Apply the same idea outside code: meeting summary edit rate, draft email accept rate, action item completion rate.

Design moves at this step

• Capture per-action accept, edit, and revert events.

• Compute edit distance between agent output and final user output.

• Surface a thumbs control in context, not in a separate feedback modal.

• Tag negative feedback with a reason taxonomy (wrong, off-tone, too long, hallucinated).

• Feed the telemetry back into prompt iteration weekly, not quarterly.

How to apply this playbook to your roadmap

1) Are you pre-launch or in production?

Pre-launch teams should do steps 1 through 4 before opening a private beta. Production teams should run the scoring matrix on the current build and prioritise any step under 3. Steps 6 and 7 quietly drive retention but are easy to defer, which is exactly why teams that defer them churn.

2) Are you single-agent or multi-agent?

Single-agent products can complete this playbook with one designer and one engineer over a month. Multi-agent products need an additional pass on orchestration UX (sub-agent dispatch, parent agent visibility, cross-agent memory). See our multi-agent system UX design guide for the additional patterns.

3) Are you building on a framework or rolling your own?

If you are on the Vercel AI SDK or LangGraph, steps 2 and 3 are partially solved by the framework's streaming and tool primitives. Use them. If you are building agent infrastructure from scratch, budget twice as long for steps 3 and 6, because the framework abstractions are doing more work than they look like.

4) How much design polish does the agent need before users see it?

An internal agent for a 20-person ops team can ship with utilitarian UI. A consumer or prosumer agent at $20+ per month needs the planning surface, the tool log, and the memory panel to feel like product surfaces, not debug views. The difference between an agent product that converts and one that does not is usually 80% on these three surfaces.

If you have picked your stack but want a design partner to turn the agentic prototype into a profitable, human-grade product, landing pages that convert, plan surfaces that read like product UI, memory panels that pass legal review, that is what AY Design does. We help founders ship agentic SaaS that does not look AI-built. Book a design audit to see what to fix first.

FAQ

What is an agentic AI product?

An agentic AI product is software where an LLM plans and executes multi-step tasks using tools, with limited or no user input between steps. Examples include Devin (autonomous software engineer), Cursor's Composer (multi-file code edits), and Replit Agent (build an app from a prompt). The distinguishing feature is autonomy across multiple steps, not a single prompt-and-response cycle.

How is designing an agentic product different from designing a chatbot?

A chatbot is single-turn or short-turn dialogue with one model output per user message. An agentic product runs across many internal turns, calls tools, mutates state, and may take minutes to complete a task. That difference forces new design surfaces: visible plans, tool call logs, memory panels, confidence scoring, fallback routing, none of which are needed for a vanilla chatbot.

What is a planning surface and why does it matter?

A planning surface is a UI artifact, usually a numbered list of steps, that the agent generates before execution and the user can review or edit. It matters because agentic tasks run for tens of seconds to many minutes, and without a visible plan the user has no checkpoint between intent and result. Claude Code and Replit Agent are the canonical references.

How should I show tool calls in the UI?

Render each tool call as a collapsible card showing the tool name, arguments, return value, and duration. Distinguish read tools from write tools visually, and require explicit confirmation for write tools above a configurable risk threshold. Cursor's diff-based file edits are a strong reference: the diff is the tool call surface, not a hidden side effect.

What is the best way to design agent memory?

Make memory legible by inline-notifying the user whenever a memory is written and providing a memory list with delete, edit, and pause controls. ChatGPT's memory panel is the reference. Separate project memory from global memory, and design a one-click "forget this conversation" path for sensitive sessions.

What metrics should I instrument for an agentic product?

Track per-action accept rate, edit distance between agent output and final user output, revert rate, and tagged negative feedback. GitHub Copilot's accept rate is the headline pattern. Avoid leaning on token counts or session counts as proxies for product success, they are correlated with usage but not with trust.

Should I build my own agent framework or use Vercel AI SDK or LangGraph?

For most teams, use a framework. The Vercel AI SDK and LangGraph both solve streaming, tool calling, and state management in ways that take quarters to rebuild. Build your own only if you have agent-specific constraints (custom orchestration, fine-grained cost control, regulated deployment) that the frameworks cannot meet.

How do I decide when to hand off from agent to human?

Hand off when the agent detects a stall (repeated tool calls with no progress, no plan advancement, hitting a confidence floor) or when the action exceeds the agent's authorised scope. Preserve full context on handoff so the human picks up without rereading the conversation. Aider and Cody both implement clean handoff patterns worth copying.