Most products add an AI feature and skip the most important question.
Not “what should the AI do?” Not “which model are we using?” Not “how do we handle hallucinations?”
The question they skip is: what type of AI experience does this actually need?
There are three types. They are not interchangeable. And picking the wrong one is probably the single biggest reason AI features get built, shipped, and then quietly ignored.
Why This Decision Gets Missed
Here is what usually happens. A product team decides they need to add AI. They spend weeks debating the use case, the model, the data pipeline. Then someone puts together a design and defaults to a familiar pattern — usually a chat panel or a floating button — because it is what they have seen before.
Nobody stops to ask whether that pattern fits the task they are designing for. The pattern gets built. The feature ships. Usage numbers disappoint. The team blames the AI.
The AI is not the problem. The experience type is.
The 3 Types of AI Experience
Type 1 — Immersive
What it is: Full screen. The entire canvas dedicated to the AI experience. Nothing else competing for attention.
The example that gets it right: Microsoft Copilot for Security.
When a security analyst is investigating a threat, they are not doing it on the side. They are reading through logs, correlating signals across multiple data sources, building a timeline of what happened and how. That task requires full cognitive focus. A side panel would fracture it.
The immersive experience exists because some problems are too heavy for anything smaller. The user needs to go deep, and the interface needs to support that depth, not fight against it. Everything on screen is there to help with one thing.
When to use it: Complex, knowledge-intensive tasks where the AI is the core of the workflow, not a helper at the edge of it. Analytics platforms, security operations tools, research environments, anything where the user opened the product specifically to let the AI work through something difficult.
The principle is simple: the more important the task, the more real estate it deserves. If the task is the main event, the AI should be too.
Type 2 — Assistive
What it is: A side panel that lives inside an application the user is already working in. The AI does not take over. It shows up beside the workflow and supports it.
The examples that get it right:
GitHub Copilot in VS Code. The developer is writing code. The AI suggests the next line in context, inside the editor they already have open. They do not need to switch tools. They do not need to open a new tab. The suggestion appears where the work is happening.
Grammarly in the browser. The writer is drafting an email. Suggestions appear inline, in the document, without pulling the user away from what they were doing. The writing continues. The AI assists.
Notion AI in the sidebar. You are building a page. The AI is there when you need it, out of the way when you do not.
What these have in common is that the AI never makes itself the main event. It earns its place by being useful without disrupting what was already going on.
When to use it: Tools where users have an established workflow and the AI’s job is to support that workflow, not replace it. The user has a task. The AI helps them do it better. The user stays in control and in context throughout.
This is the most underbuilt type in most product categories today. Teams are scared of taking up screen real estate, so they shrink the AI into a pop-up or hide it behind a button. Then they cannot understand why nobody uses it.
The issue is not the space. It is relevance. When the AI is in the right place, at the right moment, users use it.
Type 3 — Embedded
What it is: A single, contextual entry point. A pop-up triggered by a specific action. An inline suggestion. A button that appears when you highlight text. The AI is not always visible. It shows up when context invites it.
The examples that get it right:
Gmail’s Smart Compose. You start typing an email and a suggestion appears for how to finish the sentence. You accept it with a tab key or you ignore it and keep typing. The AI is embedded into the action itself, not layered on top of it.
Figma’s AI rename. You have a set of layers with messy names after a long design session. You select them, trigger the AI, it renames them in one go. You move on. The interaction is over in seconds.
These are small moments of AI help inside a larger task. The AI does not need to be prominent because the task it is helping with is not prominent. It is occasional, specific, and triggered by context, not by the user consciously deciding to use AI.
The problem: Embedded has become the default.
When a team does not know what type of experience to build, they build Embedded. It feels safe. It feels non-intrusive. It will not upset anyone. And for the right use case, it works well.
But for a task that actually needs the AI to be useful, Embedded is too small, too hidden, too easy to miss. Teams spend months building an AI feature and bury it in a contextual pop-up that users never find. The adoption numbers come back flat. The post-mortem blames onboarding, prompting, discoverability.
The real issue is that the task needed an Assistive or Immersive experience, and the team built Embedded because it was the path of least resistance.
The Rule That Ties It Together
The more important the task, the more real estate the AI needs.
That is it. That is the whole framework. It sounds obvious. It almost never gets applied before the first wireframe goes up.
If a user comes to your product specifically to do a complex, high-stakes task and the AI is central to that task: Immersive.
If a user comes to your product to do their regular work and the AI can make that work better without interrupting it: Assistive.
If the AI is helping with a small, specific, occasional moment inside a larger task: Embedded.
Three Questions to Ask Before You Build
If you are about to design an AI feature, run through these before committing to a pattern:
1. How important is this task to the user? If it is their primary reason for opening the product, the AI should be prominent. If it is a supporting action, the AI should be proportionally smaller.
2. Does the user need to stay in their existing workflow, or is the AI experience itself the workflow? Staying in the flow means Assistive. The AI being the whole point means Immersive.
3. Will users engage with this constantly or occasionally? Constant, recurring use calls for integration into the workflow. Occasional, triggered use calls for embedding. A feature that users need once a week does not need to occupy permanent screen real estate.
The Decision Comes First
The type of AI experience is an architecture decision. It shapes everything that follows: where the AI lives in the interface, how users discover it, what interaction patterns make sense, how much space it earns.
Most teams make this choice last. Or they do not make it at all — it just happens, by default, by whatever pattern felt familiar.
Start with the task. How much does it matter? How complex is it? How often does the user need AI for it? Answer those questions and the type becomes obvious.
Then build. Not before.
The AI does not fail because it is bad. It fails because it is in the wrong place.