There's an AI feature in many SaaS products right now that looked incredible in the all-hands demo.
It's got a button. Maybe even a loading spinner. And, probably, it spits out a summary of something: an email, a ticket, a spreadsheet. The demo kills, so it ships as a feature. What follows is six months of near-zero usage.
It wasn't a bad idea. It wasn't bad UX. And it wasn't bad timing. It was a Rung 1 product, a single LLM call dressed up as a feature, and users found its ceiling in about thirty seconds. The fix is not a better prompt. The fix is an agent-native architecture.
There's a ladder that every AI product climbs. Three rungs. But most teams stop one rung too early, if that.
Here's the ladder:
This is the anti-pattern.
A text box sends a prompt. The AI returns a string. You display it. Maybe with a loading spinner, maybe with a "copy" button if you're feeling fancy. There's no way for the user to course-correct. No way for the AI to take action. No way to see what happened or why.
You see this everywhere. The "Summarize" button bolted onto a CRM. The "Generate description" field in an e-commerce admin. The "Draft reply" widget in a support tool. They look impressive in a demo, but they break the moment reality gets messy. An edge case the model wasn't expecting. An output that's close but wrong. Users who need to iterate or are left with no options.
And they often break invisibly. The user doesn't get an error. They get a bad string, shrug, and go back to doing it manually. Then they stop clicking the button entirely.
Three months later, the team schedules a meeting to "improve the prompts." They adjust temperature settings. They rewrite the system message. They get the output from 65% good to 75% good, but that's still not reliable enough to replace the manual workflow. Another sprint, another tweak, another flat usage graph. Eventually, it gets cut in a cleanup ticket. Nobody files a bug. Nobody notices it's gone.
Teams ship products like this because it's fast. It clears the "AI feature" box on the roadmap. It demos clean to a non-technical stakeholder who's never actually used it for real work. It's the path of least resistance from "we should add AI" to "we shipped AI."
That's not a product. That's a toy.
The tell: if removing the AI feature would barely change how users do their job, it's Rung 1.
Rung 2 is a real improvement.
Now the AI has tools (draft email, search contacts, run query, create ticket) and a chat interface where it works in front of you, showing tool calls and results as it goes. You can watch it reason. You can push back. You can see why it did what it did. This is what Claude, ChatGPT, and Cursor look like under the hood as a chat interface with tools.
For general-purpose assistants, Rung 2 is the product. Claude is a chat interface with tools. That's not a limitation; that's the point.
But for a domain-specific app (a project management tool, a customer support platform, a dev workflow product), Rung 2 is a ceiling.
Here's why. There's still no real UI. No dashboards. No lists. No forms. No keyboard shortcuts. No team collaboration features. If the AI gets confused, the user's only recourse is to retype the request differently and hope for a better result. Non-developers especially struggle here; when the interface is a blank text box, and the AI is your only affordance, you're one ambiguous output away from being stuck.
There's also a subtler problem. The AI has no real context. It sees what's in the conversation thread, but it doesn't know what you're looking at in the app. It doesn't know what you've selected or what you just did. It's reasoning about your work from the outside.
Rung 2 is a great chatbot. It's a mediocre app.
The tell: if your "AI feature" is a chat panel that floats over the rest of your product and never touches the same state the rest of your product reads from, you're on Rung 2.
Rung 3 is what agent-native means: every action the agent can take is also a button in the UI, and every button the user clicks runs the same logic the agent uses. Your app becomes truly agent-native.
You build a full-featured app around the agent. And crucially, every action the agent can take is also a UI button, and every button the user clicks runs the same logic the agent uses. One implementation. Two ways in.
Here's what that looks like in practice. Imagine you're building a customer support tool. A ticket comes in. A human agent clicks "Suggest reply" and gets a draft: one button, one action. The AI handling the overnight queue calls the same action to draft and send replies autonomously. The logic is identical. The difference is who invoked it.
That's the agent-native architecture. Not a chat panel bolted onto an app. Not an app with AI sprinkled in. One system where humans and agents are both first-class operators.
That single design decision changes three things:
You stopped adding buttons to a chatbot. You added an agent to an app.
The quality bar on both sides goes up. The UI is a real UI, full-featured, fast, familiar to users who don't want to type. The agent is a real agent. It can take every action in the product, not just the ones you wired up to a chat panel. Neither side is a watered-down version of the other.
The agent has real context.
It sees what you're looking at. It knows what you've selected, what you've recently done. It writes to the same database the UI reads from, so when it creates a record or updates a status, that change shows up immediately in the interface, not in a separate "AI output" box, but in the actual app. The agent isn't advising you from the outside anymore. It's working inside the same product you are.
External agents can use it too.
This is the one most teams don't anticipate. Because the app's actions are first-class objects, not prompt hacks, and not one-off API endpoints, they can be projected into any surface a host understands. Claude Code, Cursor, ChatGPT custom apps, and other MCP hosts can drive your app as an MCP server. Other agent-native apps can call yours over A2A. You build the domain operation once; the framework handles MCP tools, A2A endpoints, HTTP actions, deep links, and CLI entry points from the same definition.
You don't become a protocol expert. You just build the action.
This is also why agent-native apps handle so many protocols without making developers' lives more complicated: the architecture is a single-action model with multiple entry points, not a separate integration per surface. One implementation, many ways in. For users, for your own agent, and for the agents of every other app in the ecosystem.
That's Rung 3.
Most developers know the honest answer. The question is whether staying on Rung 1 or Rung 2 is a deliberate choice or just the path of least resistance.
Agent-native means an app where every domain action is a first-class object that humans (via UI), the in-app agent, and external agents (via MCP or A2A) can all invoke through the same single implementation. It's Rung 3 of the ladder: not a chat panel bolted onto a product, but one system where humans and agents are equal operators.
Rung 1 is fast to ship and easy to kill. Rung 2 is a real product for the right use case. Rung 3 takes more architecture up front. But it's the only rung where the AI feature is indistinguishable from the product itself, where users who don't want to chat can still benefit from everything the agent can do, and where the rest of the agent ecosystem can find you and use you.
One rung at a time is fine. Just don't stop climbing because the demo killed in the all-hands.