Add a prompt box is not a design decision, it is the absence of one. Where prompts live, inline, in a panel, behind a slash command, or invisible inside a background agent, drives adoption, latency, and error rates more than the model does. This is a map of the four prompt surfaces, the trade-off each one makes, and how to pick the surface that fits the task in front of the user. One team lifted adoption from 14 to 61 percent by moving the same feature to a better surface.
"Add a prompt box" is not a UX strategy
When a team decides to add AI to a product, the default instinct is a chat box in the corner. It feels safe because it is flexible: the user can ask anything. But maximum flexibility is often the worst fit for a specific task. A blank box forces the user to invent the prompt from scratch, remember what the tool can and cannot do, and context-switch out of their work to type it. The result is a feature that demos well and sits unused, because the prompt lives in the wrong place. A blank box is not a neutral choice; it is a decision to push all the effort of framing the request onto the user, on every single use.
Where a prompt lives is a real design decision with measurable consequences. It sets how far the user has to travel from their task, how much they have to type, how long they wait for a result, and how likely they are to make an error along the way. There are four recurring surfaces, inline, panel, slash command, and background agent, and each one trades flexibility against friction differently. The skill is matching the surface to the task, not defaulting to the box. Get the surface right and a mediocre model feels helpful because it meets the user exactly where the work is; get it wrong and a state-of-the-art model gathers dust behind a button nobody thinks to click.
Four surfaces, four trade-offs
Each surface sits at a different point on the flexibility-versus-friction curve. Inline is fast but narrow. A background agent has zero friction but zero user control. The panel and the slash command sit in between, one favoring depth and rationale, the other favoring speed for people who already know precisely what they want. The table below shows where each fits, with representative latency budgets and the error mode each surface is prone to. Notice that latency and control move in opposite directions across the table: the surfaces that ask the least of the user also give the user the least say, so the choice is always a deliberate trade, never a free win.
| Surface | Best for | User effort | Latency budget | Typical error mode |
|---|---|---|---|---|
| Inline | Small, in-context edits (rewrite, fix, extend) | Very low, one tap | Under 800ms | Wrong scope, edits too much |
| Panel | Exploration with rationale and evidence | Medium, read and choose | 1 to 3 seconds | Ignored, panel stays collapsed |
| Slash command | Known, repeatable actions by power users | Low once learned | Under 1.5 seconds | Undiscoverable, users never learn it |
| Background agent | Event-triggered drafts, no prompt UI | None, it proposes | Seconds to minutes | Acts unasked, erodes trust |
A worked example makes the trade-off concrete. A support tool first shipped its reply-drafting feature as a chat panel: agents had to open it, describe the ticket, and read the suggestion, so only 14 percent used it. The team moved the same capability to a background agent that drafts a reply the moment a ticket opens, shown inline above the compose box with a one-tap accept. Adoption jumped to 61 percent and median handle time fell by 22 percent, because the prompt no longer lived somewhere the agent had to travel to. Same model, same output quality, different surface. The lesson generalizes past this one team: the surface change was worth more than any model upgrade on their roadmap, and it shipped in a fraction of the time and cost. When a promising AI feature is not being used, the first question is rarely "is the model good enough" and almost always "does the prompt live where the work already happens".
Place the prompt where it cuts friction
Choosing a surface is a design act, not a default. Walk the decision from the task backward to the placement, in this order.
- Start from the task, not the technology. Ask whether the user needs a small edit, an exploration, a known action, or nothing at all, then pick the surface that matches.
- For high-frequency, in-context work, prefer inline over a panel. Every extra click halves the odds the feature gets used on a busy day.
- Reserve the panel for cases where the user genuinely needs to see rationale and evidence before choosing, and make it earn its space.
- If you ship a slash command, ship discovery with it: a visible hint, an autocomplete, an onboarding nudge, or it stays invisible.
- Use a background agent only when the trigger is unambiguous and the user can always decline. Propose, never auto-apply, until trust is earned.
Where prompt placement goes wrong
Most placement failures share a root cause: the team optimized for what the tool could do rather than for how little the user should have to do. Watch for these five.
- Defaulting to a chat box. Maximum flexibility is maximum friction for a specific task. Fix: choose the narrowest surface that covers the real job.
- Inline that edits too much. A small ask rewrites the whole paragraph. Fix: scope the edit to the selection and show a clear diff.
- Panels nobody opens. Rationale hidden behind a collapse users never expand. Fix: surface the one insight inline and keep the panel for depth.
- Undiscoverable slash commands. A great feature only power users find. Fix: add autocomplete and a first-run hint so discovery is not luck.
- Background agents that act unasked. One unwanted auto-action and users disable the feature. Fix: always propose and require a tap to apply.
Before you ship the prompt box
Five checks that catch the most common placement mistakes before they reach users and quietly kill adoption.
- Name the specific task the prompt serves before you choose a surface.
- Set a latency budget per surface and test against it on real load.
- Move your highest-frequency AI action inline and measure the adoption change.
- Add discovery affordances to every slash command you ship.
- Make every background agent propose, not apply, and track the accept rate.