Native app teams are being told to build agent tools, but they’re risking shipping faster horses instead of cars.
Here’s what I’m seeing at enterprise scale: 📊 Teams think: “How do we make our existing user flows work with agents?” Instead of: “How do we design agent-first interactions?”
The faster horse trap: 🐎 Agent calls local tool → Tool shows familiar dialog → User interacts like always → Tool returns result
The car approach: 🚗 Agent calls tool → Tool returns declarative UI → Agent renders UI → User interacts within agent context
Why teams fall into this trap: ⚠️ When your team’s KPIs depend on preserving existing user engagement patterns, you unconsciously design AI integrations that maintain those flows. App teams want to stay in control of the pixels the user interacts with.
Three patterns breaking local agent experiences: 🔍 The Flow Preservation: Adapting existing user workflows instead of designing agent-native interactions 🔍 The Engagement Protection: Keeping your tool’s UI because your metrics depend on it 🔍 The Context Break: UI appearing outside the agent conversation flow
Better approach for native app teams: ✅ → Tool: Windowless API that returns declarative UI specifications (see e.g. mcp-ui and MCP elicitation) → Agent: Shell that renders tool-provided UI within the conversation → User: Single interaction surface (the agent interface)
Remote tools figured this out because they can’t pop desktop UI anyway. Native app teams need to stop thinking like app teams. 🔄 Most won’t make this shift because it requires abandoning familiar user interaction patterns AND rethinking success metrics. The teams that do will create seamless agent experiences instead of bolted-on AI features. ⚡ What existing user flows are you trying to preserve that should be redesigned for agents? 👇