I’ve been building agentic applications for the past year, and I keep coming back to one idea: AI-native apps are fundamentally about control transfer.
Not “does this app have AI features?” but “how does control flow between the user and the AI?” That’s the question that separates an AI-native app from one with AI bolted on.
We’ve seen this kind of shift before
Remember MapQuest? Click on a direction arrow, wait for the page to reload, get a new static image of the map. Then Google Maps arrived. Drag, zoom, tiles loading seamlessly. Same underlying technologies: HTTP requests, JavaScript, images served from a server. Completely different experience.
One was a website that showed maps. The other was an application for exploring geography.
We’re in a similar moment now. The question isn’t whether an app uses AI. It’s whether the app is built around AI from the start.
AI-assisted versus AI-native
AI-assisted is a summarize button on an article. A “draft reply” option in your email. AI bolted onto an existing interface. The user still does the work; the AI just speeds up a step.
AI-native is different. The AI is the interface, or at least the starting point. You don’t navigate to a feature and invoke AI. You start with a conversation, and the interface emerges from what you’re trying to do.
Two patterns, one insight
As I’ve built and used these tools, two dominant UX patterns have emerged:
Chat-dominant with artifact sidebar. Claude and ChatGPT Canvas work this way. The conversation is primary; artifacts appear alongside as outputs.
App-dominant with AI sidebar. Cursor started this way, with the familiar IDE as primary. Though it’s worth noting that Cursor has since moved toward chat-dominant with their Agents view. Even app-dominant tools are converging on conversation as the starting point.
Both patterns work. But the best experiences aren’t stuck in one mode. They transition. That’s the real insight.
Control transfer is the real pattern
Here’s what I’ve come to believe: AI-native apps are about progressively transferring control between user and agent.
You start with high-level intent. The agent takes control, does work, asks clarifying questions, produces drafts. Then it progressively hands control back as the output gets closer to done.
The interface should match where you are in that transfer.
Phase 1: Conversation (0 → plan). You’re exploring, qualifying, strategizing. The agent asks questions, you provide context, together you arrive at a plan. Chat-dominant makes sense here. The output is understanding and direction, not artifacts.
Phase 2: Drafting (plan → 80%). The agent executes. First draft appears. You review, give feedback, iterate. The conversation continues, but now artifacts are emerging: a canvas, a preview, a document. This is the hybrid state.
Phase 3: Polish (80% → done). You take over. You’re in the artifact, the editor, the app view. The agent steps back but remains available. App-dominant. You have control; the agent assists on demand.
The 80% moment is when planning becomes execution. The structure is clear, the direction is set, and now it’s about producing and refining the output. It’s like finishing a good planning meeting: you walked in with a goal, you’re walking out with an execution plan.
Transitions should be explicit, not agent-prompted
One thing I’ve learned building these flows: the agent shouldn’t prompt the transition. “I think we’re ready for you to take over” feels like the agent giving up.
The transition should be available as an explicit action. A button on the artifact: “Open in editor.” The user decides when they’re ready to take control. The agent should only prompt when it genuinely can’t proceed: can’t publish, can’t access something, needs credentials.
User agency matters. The control transfer should feel like the user claiming control, not the agent abandoning it.
Not every task needs all three phases
The full sequence is Conversation → Artifact → App. But depending on the task, you might stop early.
Creative work like writing, code, and slide decks usually needs the full sequence: conversation to plan, drafting to get to 80%, polish in an editor. But a marketing email might never leave the artifact view. If you can preview, tweak copy, and hit send right there, why would you? Tax preparation might skip straight from conversation to submission once the agent has organized your documents.
Simple tasks stay in conversation. Medium complexity stops at artifact. High complexity or high user agency goes all the way to app.
Where each pattern fails
The chat-dominant pattern fails when it can’t render output well. Even Claude and ChatGPT struggle with this today. The agent produces something, but the chat interface can’t show it properly. You’re squinting at markdown tables or code blocks that would be clearer in a real preview. The agent knows what it wants to convey but the medium limits it. This is the problem that MCP-UI and ChatGPT’s Apps SDK are trying to solve with inline widgets. And if you’re building on Slack or Discord, the constraints are even tighter: BlockKit only goes so far.
The app-dominant pattern fails when users ignore the agent. They fall back to old habits. It’s like having a kettle but still boiling water on the stove. The AI becomes a sidebar they never open. This happens when the UX is too passive, when AI features are shown subtly instead of prominently, or when the familiar interface is so comfortable that users default to doing things manually.
The worst AI integration either never takes control or never gives it back. The summarize button is an example of the first failure: the user still does all the work, AI just assists a step. A fully autonomous agent with no intervention points is an example of the second. Both miss the point.
So what makes an app AI-native?
Here’s my working definition:
An AI-native app is conversational by default, produces tangible output on your behalf, and makes it easy for you to take control when you’re ready.
This means designing for two users: the human and the agent. Traditional apps optimize for one user navigating menus, clicking buttons, filling forms. AI-native apps need to serve both a person expressing intent and an agent executing on that intent.
Chat is a natural starting point because it’s already a multi-party interface. But as these apps mature, I expect we’ll see more collaborative patterns emerge: presence indicators showing where the agent is focused, shared state that both human and AI can manipulate, clear visual signals for who has control. The same patterns Figma pioneered for human collaboration, adapted for human-AI collaboration.
We’re still early in figuring this out. But if the Web 2.0 era taught us anything, it’s that the new paradigm won’t just add features to the old one. It’ll change what we expect an app to be.