What the Best Agent Products Actually Look Like

Estimated reading time: 6 min

A few months ago, Publigent published a catalog of agent UX patterns: ambient, structured output, embedded, and notification-driven. The response was telling. People nodded at the pattern names, but what they actually asked for was different. They wanted to see what each pattern looks like in a real product. The specific design decisions. The edge cases. The moments where the pattern either clicked or fell apart.

This is that piece. No pattern names as headings. No abstract frameworks. Just four products, studied closely, each representing a distinct approach to the agent interface question.

---

Case study 1: The agent that works while you do something else

Copilot is the product anyone building agent UX should study first, not because it is the most sophisticated, but because it solved the interface problem before anyone else did.

The core design decision is that Copilot never asks you to do anything. You are typing. A gray suggestion appears. You press Tab to accept it or keep typing to reject it. There is no separate window. No notification. No "would you like me to suggest something?" It sits beneath your attention until you need it, then disappears when you do not. The interaction takes zero seconds if you ignore it and fractions of a second if you act on it.

This is the ambient pattern at its purest. The agent works constantly, generating suggestions and ranking them by likelihood, but it surfaces nothing unless there is something to surface. The mental model is background process, not conversation partner.

The second design decision worth noting is how Copilot handles context. It reads the open file, the surrounding imports, the recent edits. It uses this context implicitly, without asking you to describe the problem. You never have to write "write a function that takes a list and returns the average." You just start writing the function name, and the suggestion appears. The context gathering is invisible. The result is that Copilot feels smart even when the suggestions are wrong, because the intelligence is in the timing, not just the output.

Copilot also introduced inline suggestions as an interaction mode that is now the standard for embedded agents. The suggestion appears in-place, where you are already working. You accept, reject, or modify. The feedback loop is immediate and costs nothing. Compare this to a chat interface, where you must switch contexts, read a response, evaluate it, and copy-paste the result back into your working environment. The inline suggestion removes every step between the agent's output and the user's workflow.

The feature that gets the least attention but matters most is the Copilot status indicator. A small icon in the status bar shows whether Copilot is active, processing, or unavailable. That single pixel of awareness is the difference between trusting the agent and wondering whether it is working. Copilot users develop a feel for when suggestions will appear and when they will not, because the status indicator trains their expectations.

Case study 2: The agent that delivers artifacts

Gamma is a presentation tool that replaced its slide editor with an AI-driven generation flow. The interface is simple: you describe what you want, and Gamma produces a deck with text, layout, and imagery. You can edit the output, but the starting point is a generated artifact rather than a blank canvas.

The design decision that makes Gamma different from a chat-wrapped model is that the output is the interface. You do not get a paragraph describing what the presentation could look like. You get the presentation. The agent's work is visible, navigable, and immediately usable. The friction point in most AI products is the translation from model output to useful work: copying text, formatting it, placing it in the right tool. Gamma eliminates that translation entirely.

Structured output products like Gamma share a common pattern: they generate in the user's existing format, not in a text box. An agent that writes Jira tickets generates into the ticket fields, not into a paragraph. An agent that drafts blog posts generates into the CMS editor, not into a chat window. The artifact is the deliverable. The agent's reasoning is accessible but secondary.

This matters for trust. When an agent outputs a paragraph describing what it would produce, the user must evaluate both the description and the imagined output. When the agent produces the actual artifact, evaluation is immediate. Is this slide right? Does this ticket capture the requirements? The user can judge the work directly rather than judging a plan for the work.

The tension in Gamma's approach is that the artifact also sets expectations. A draft presentation with placeholder images and generic text sometimes feels worse than a blank slide, because the user must undo before they can do. The product handles this by making regeneration cheap (one click, a new draft), which shifts the user's relationship from editing a single output to curating a set of options.

Case study 3: The agent that lives where you already work

Notion AI is the clearest example of the embedded agent pattern. It is not a separate product or a chat overlay. It lives in the same interface you use to write documents, manage projects, and organize databases. When you highlight text and press space, a menu appears with AI options. When you type in a database property, AI suggests completions. When you open an empty page, AI offers to draft the content.

The design principle at work is that the agent inherits the interface it lives inside. Notion AI does not have its own design language. It uses Notion's menus, Notion's typography, Notion's interaction patterns. The user never feels like they left their workspace to visit a different product. This is harder than it sounds. Most embedded agents end up fighting the host interface's conventions rather than adopting them.

The detail in Notion AI worth examining is the progressive disclosure. When you first use it, you see a small set of options: summarize, translate, fix spelling, make longer, make shorter. These are safe, predictable actions. The user learns what the agent can do without being overwhelmed. As you use it more, the options expand. You can ask custom questions, generate from properties, create database formulas. The capability surface grows with the user.

Contrast this with products that show the full capability set on day one. The user sees 30 prompts, 20 templates, 7 agent types, and immediately feels behind. Notion AI shows five options in a dropdown that feels like a feature of the text editor, not a separate AI product. The threshold for deciding to use it is zero seconds. You are already typing. You highlight. You press space. The option is there.

The undo question in Notion AI is worth studying. Every AI action in Notion is undoable with Cmd+Z, the same undo you use for typing. This is deceptively hard to implement. Agent actions are not equivalent to single character insertions, but it is essential for trust. Users experiment with AI features precisely because they know they can undo the result. Products that require navigating to a separate undo interface or confirming a rollback get less experimentation and therefore less adoption.

Case study 4: The agent that comes to you

Slack is not an agent product, but it is the infrastructure layer for notification-driven agents. The pattern works like this: an agent runs in the background, monitoring data or processing requests. When it has something worth saying, it posts a message to a Slack channel, a DM, or a thread. The user reads it, acts on it, or ignores it. The interaction is asynchronous. The agent initiates when it has value to add, not when the user asks for an update.

The design decisions Slack has made for AI integration show a clear priority. Slack AI surfaces conversation summaries, thread digests, and search results within the existing Slack interface. It uses the same message format, the same thread structure, the same notification system. An AI summary looks like a message from a channel member. It is formatted the same way, appears in the same timeline, and can be responded to in the same thread.

This is a choice. Slack could have created a separate AI panel, a floating widget, or a dedicated bot interface. Instead, it chose to make AI output indistinguishable from human output within the platform. The benefit is frictionless consumption. The user processes AI messages the same way they process human messages: by scanning, assessing, and responding as needed. The cost is ambiguity. Users sometimes cannot tell whether an AI summary is complete, whether it represents the full conversation, or whether it missed something important.

The notification-driven pattern works best when the agent's output is deterministic and bounded. A daily sales summary agent reports on closed deals, pipeline changes, and at-risk accounts. The user knows what to expect and can scan the update in seconds. An open-ended research agent that surfaces "interesting findings" in Slack gets ignored after the second week, because the user cannot predict what the notifications will contain or whether they are worth their attention.

The products getting the notification-driven pattern right are the ones that let the user set the trigger conditions explicitly. "Tell me when a deal moves past stage 3" is a concrete boundary. "Send me weekly analysis" is a concrete cadence. "Notify me about anything unusual" is the fast path to archive folder.

What all four share

Across these four approaches, a handful of design principles appear consistently.

Progressive capability matters most. Every case study product limits what the user sees on day one. Copilot shows gray suggestions. Notion AI shows five menu items. Gamma starts with a prompt, not a feature browser. Slack AI sends one message per request. The agent's full capability is accessible but not visible. The user discovers it through use, not through documentation.

Low-cost rejection is the second thing. Every product makes it cheap to say no. Copilot only asks you to keep typing. Notion AI lets you hit Cmd+Z. Gamma gives you a regenerate button. Slack invites you to scroll past. Rejection that costs time or cognitive effort discourages experimentation. The best agent products assume the user will reject most suggestions and design for that reality.

Context as the interface is the third. The best agents do not ask for context. They already have it. Copilot reads the open file. Notion AI reads the document. Slack AI reads the channel history. The user provides context by being where they already are, not by typing a description.

And output in the user's format, not the model's format, is the fourth. Copilot outputs code in the editor. Gamma outputs slides in the slide editor. Notion AI outputs text in the document. Slack AI outputs messages in the channel. The agent adapts to the user's tools, not the other way around.

What is missing

The products that exist today each work within a single pattern. Copilot is ambient. Gamma is structured output. Notion AI is embedded. Slack AI is notification-driven. The next generation of agent products will need to combine patterns: an agent that is embedded in your CRM, but also surfaces notifications in Slack, and delivers weekly reports as structured documents.

The products that combine patterns will face a harder design problem than the single-pattern products do. How do you keep ambient awareness from becoming notification noise? How do you prevent the embedded agent from competing with the notification-driven agent for the same user attention? How do you make a combined pattern feel coherent rather than like three separate products bolted together?

There is also a gap in team-scale agent UX. Most agent products ship for individual users. Ambient suggestions in a single IDE. Notifications to a single Slack user. Structured artifacts for a single report. The design problems change when an agent serves a team of ten people, each with different information needs, attention patterns, and trust thresholds. No product has fully solved that yet.

The design question that will define the next phase of agent UX: can a product make an agent invisible in the individual moment and visible at the team scale?

---

This article deepens the UX pattern catalog from our earlier piece on agent interface patterns. It is the fifth article in Publigent's June 2026 series, following our analysis of multi-modal agents and screen-reading capabilities.