Agent Product Surface
The agent product surface is the user-facing layer where a human supervises autonomous work: intent, progress, tool calls, approvals, artifacts, errors, cost, pause/resume, and final proof.
Why this is a concept
Many pages already describe pieces of agent UI: AI-Native Design Patterns, Agent Machines, Loop, Browser Agent Console, Agent Trajectory Evaluation, and Latency Budgets for Agents. The missing concept was the product boundary: what a user must see and control for agent work to feel usable instead of spooky.
An agent product surface is not just chat. Chat is the intent channel. The product surface is the whole operating room.
Required surfaces
| Surface | User question it answers |
|---|---|
| Intent | What did I ask this agent to do, and can I revise it? |
| Plan/state | What phase is it in now? |
| Tool activity | What is it reading, running, changing, or calling? |
| Approvals | What side effect needs my consent, and what happens if I say yes/no? |
| Artifacts | What did it produce: diff, file, screenshot, report, deployment, message? |
| Provenance | Which sources, logs, traces, and commands support the result? |
| Control | Can I stop, pause, resume, retry, fork, or cancel honestly? |
| Cost/latency | How long is this taking and what is it spending? |
| Memory | What will persist after the run? |
Vercel's AI SDK and AI Elements ecosystem is useful IRL evidence that these are becoming reusable product primitives: chat transport, message parts, tool states, citations, reasoning, branch controls, prompts, and conversation components are becoming component surfaces rather than bespoke UI each app reinvents. Source: Vercel AI SDK docs, https://ai-sdk.dev/docs, 2026-06-19; Vercel AI Elements docs, https://ai-sdk.dev/elements, 2026-06-19
The durable user-facing contract splits into four concept pages:
| Concept | Surface implication |
|---|---|
| Human-in-the-Loop Control | Approval cards need approve/edit/reject/respond/cancel semantics, not a generic "continue." |
| State Resumability | Runs need visible state, resume/cancel/retry behavior, and stale-run handling. |
| Proof-Carrying Work | Final artifacts need sources, traces, commands, validations, and unresolved risks. |
| Agent Unit Economics | Expensive or long-running work needs cost, budget, and value visibility. |
Product states
If the UI only supports "generating..." and "done," the product has no honest model of agent work.
Design rules
- Progress should be factual: "Reading 7 files" beats "thinking."
- Stop must be honest. If cancellation is best-effort, say what will still finish.
- Approval cards should show inputs, diff/preview, affected system, and rollback/cancel path.
- Tool results should have compact and expanded forms.
- Artifacts should be copyable, downloadable, linkable, and attributable to a run.
- Long-running work should survive refresh, navigation, and device changes.
- Errors should explain the failed invariant and the next viable action.
- The surface should expose the trajectory without making users read raw logs.
Recent Product Evidence
The 2026-06-30 bookmark review added three concrete surface patterns:
| Source | Product-surface lesson |
|---|---|
| Copilot Design System | Multi-surface AI products need a visible focus-transfer protocol: global memory, local canvas execution, contextual entry point, and handoff state. |
| Clicky | Screen-aware assistants can point, speak, and respond to the current desktop context; this is a different surface from a transcript-only chat. |
| Agent Operations Skills | Agent-assisted project updates should draft from recent product activity and Slack context, but the user still verifies, edits, and posts. |
| Nous Portal | Model/agent products need team-level budget and usage controls, not only model-prompt UX. |
Source: X bookmark artifact audit, 2026-06-30
The 2026-07-02 Clicky workflow demo sharpens the screen-aware row: the agent surface can be a compact desktop control panel beside the user's current app, with Home/Agents navigation, explicit voice/control affordances, cursor controls, app integrations, and an unlock/permission path. The surface lesson is not "agent speaks"; it is that voice needs visible control state and app context so proactive nudges remain inspectable. Source: X/@FarzaTV, 2026-05-16; Source: local video contact sheet, 2026-07-02
Product-Owned Agent Substrate
Rhys Sullivan's self-thread adds a product-surface rule for apps that expose agents: build the in-app agent on the same public skills and MCP surface that power users can bring to their own agents. The X article links were inaccessible through anonymous fetches, but the self-thread states the durable thesis clearly: the product should support users who want the built-in agent and power users who want their own agent, without splitting the underlying capability substrate. Source: X/@RhysSullivan self-thread, 2026-06-27
The practical implication is that product UI and external agent API should share one capability contract: skills, MCP servers, resources, and state boundaries. Otherwise the built-in assistant becomes a proprietary wrapper while external agents get a weaker or differently named tool surface. That divergence makes evaluation, docs, permissions, and support worse.
Agent As Direct User
Simon Last's AGI-era product sketch adds the customer-shape version of the same rule: the direct product user may be an agent acting for a human. The reviewed image stack-ranks the work as: define the goal/problem, design general and well-engineered primitives, design the ideal agent interface, then design the human interface around talking to the agent plus direct access to low-level primitives. Source: X/@simonlast and local image review, 2026-07-04
The implication is not "hide the UI behind chat." The product still needs primitive-level affordances so the human can inspect, correct, and operate below the agent layer. Chat becomes the primary intent channel, while the rest of the surface shows the primitives, state, and evidence the agent is using.
Ivan Zhao's "APIs first, UI last" note is the short version of the product order. Define the primitive operations and agent-facing API before designing the human screen. Then keep the UI dumb: expose the primitive, show state, and let the agent/human compose it without burying core behavior inside a clever interface. Source: X/@ivanhzhao, 2026-06-26
Dylan Mikus' reply adds the pre-AI reason this rule was already good product design: an API lets users invent uses the product designer did not hard-code into the UI. Agents make that constraint more visible, because the direct user increasingly composes primitives through an API rather than a hand-authored screen. Source: X/@dbmikus, 2026-06-26
App-Layer Differentiation
Ivan Burazin's app-layer thesis is the negative product-surface test: many AI apps are "nice UI + a harness that gets models to the data + a sales team." That can close deals, but it is not defensible unless the surface encodes a differentiated workflow, state model, domain data boundary, evaluation loop, or distribution wedge. The product surface is where that differentiation must become visible: what the user can supervise, reuse, verify, and trust that a generic harness cannot provide. Source: X/@ivanburazin, 2026-06-24
Kevin project implications
| Project | Product-surface implication |
|---|---|
| Agent Machines | Needs fleet/run views where machines, sessions, traces, approvals, artifacts, and cost are one inspectable surface. |
| Loop | Refreshes need version history, diff, source traces, and review controls, not only a regenerated output. |
| Ariadne | Operator surfaces must expose event state and intervention paths because real guests are affected. |
| Sigil UI | Agent-authored UI should be constrained by tokens and components so generated surfaces stay coherent. |
| wiki UI | Search and graph surfaces should show source, freshness, and backlink context rather than only page hits. |
Anti-patterns
- Chat transcript as the only history.
- Spinners with no last real event.
- Tool calls hidden until failure.
- Approval prompts with no diff or rollback story.
- A "cancel" button that only hides the UI.
- Cost/latency discovered after the invoice.
- Generated UI that bypasses the design system.
Timeline
- 2026-06-19 | Created to bridge design, projects, agent runtime, observability, and AI SDK UI primitives into one product concept. Source: whole-wiki concept review, 2026-06-19
- 2026-06-19 | Added explicit control, state, proof, and economics concept links as the durable user-facing contracts for agent products. Source: whole-wiki concept review, 2026-06-19
- 2026-06-30 | Added concrete evidence from Copilot Design System, Clicky, Agent Operations Skills, and Nous Portal: focus handoff, screen-aware agents, verified agent drafts, and team spend controls are product-surface requirements. Source: X bookmark artifact audit, 2026-06-30
- 2026-07-02 | Added Farza's newer Clicky workflow demo as desktop companion evidence: voice-first interaction still needs visible control state, app integrations, cursor controls, and permission/unlock affordances. Source: X/@FarzaTV, 2026-05-16; Source: local video contact sheet, 2026-07-02
- 2026-07-03 | Added the product-owned agent substrate rule from Rhys Sullivan's self-thread: an app's built-in agent and users' external agents should share public skills/MCP capability contracts where possible. Source: X/@RhysSullivan, 2026-06-27
- 2026-07-04 | Added Simon Last's "agent as direct user" product sketch: build strong primitives and an agent interface first, then give humans chat plus direct primitive access for supervision. Source: X/@simonlast and local image review, 2026-07-04
- 2026-07-04 | Added Ivan Zhao's API-first/UI-last rule as the terse product-order version of the agent-as-direct-user surface: primitives and agent-facing APIs come before the human UI. Source: X/@ivanhzhao, 2026-06-26
- 2026-07-04 | Added Dylan Mikus' API-first reply: APIs let users and agents invent product usage beyond the designer's first UI path. Source: X/@dbmikus, 2026-06-26
- 2026-07-04 | Added Ivan Burazin's app-layer critique: UI plus a model/data harness plus sales is not durable product differentiation unless the surface carries workflow, state, data, eval, or distribution advantage. Source: X/@ivanburazin, 2026-06-24