You’ve probably been there. You’re building an AI agent. Version 1 is beautifully simple: it reads files, writes code, and runs commands. But then users ask for more. So, you add Plan Mode, sub-agents, long-term memory, background tasks, and permission pop-ups. Every iteration has a logical reason. Your feature list starts looking like a mature, enterprise-ready product.
But the users aren’t happier. They’re terrified.
“What step is it on right now?” “Why didn’t it follow the plan we just approved?” “Who authorized this action?” “It failed—do I start over or resume from the middle?”
Your product has more capabilities than ever, yet the user has entirely lost their grip on the process. This is the dark side of the AI agent revolution: teams are obsessed with designing what the agent can do, while completely ignoring how the user understands, intervenes, and revokes its decision rights.
Functionality determines how far an agent can go; control determines if the user will ever let it walk.
We’ve been trained to think that more features equal a better product. For traditional software, that’s true. You click a button, the system executes, and the cause-and-effect is obvious. But AI agents are different. You give them a goal, and they autonomously break down tasks, select tools, read data, and alter environments based on intermediate results. Every time you give the agent a new autonomous capability, you are handing it a new class of decisions it can make on the user’s behalf. When those decisions aren’t made transparent, the product becomes a black box.
Look at the recently hyped Pi Agent framework. Instead of bloating its core, Pi stripped it down to just four default tools: read, write, edit, and bash. It pushed complex capabilities like sub-agents, MCP, and Plan Mode out to the configuration and extension layers. Why? Because a product’s completeness isn’t about how many features you cram into the core. It’s about how well you allocate decision rights between the system and the user.
A bloated interface isn’t a sign of a mature product; it’s a graveyard of default rules fighting each other.
If you want to build an agent that actually gets adopted in real work scenarios, stop asking what features you’re missing. Start asking who makes the decisions. High-frequency, stable, high-stakes decisions that require a unified experience belong in the product core. User-specific preferences—like model selection or approval nodes—belong in the configuration layer. Niche, fast-changing capabilities belong in the extensions.
This isn’t just technical layering; it’s product governance. If every time a new edge case appears you add a new UI entry point, you end up with a heavy interface and a tangled web of default rules. You have to let the core remain minimal and stable, while opening up the extension interfaces so users can tailor the agent to their own workflows.
But here’s the part most teams miss: real control isn’t just a permission popup. It’s context management. If your user can’t manage what the agent sees, they don’t control the agent. They’re just a hostage to its output.
When an agent only answers a single question, visibility features feel like overkill. But when it starts working continuously for 15 minutes across multiple systems, process visibility, interruption, and failure recovery aren’t auxiliary features—they are the core interface. Users need to see what the agent has done, pause it when it drifts, and branch off from a trusted node if it fails, rather than starting from scratch.
Autonomy without transparency isn’t intelligence. It’s just chaos running in the background.
Next time you review your agent’s roadmap, stop arguing about where to place the buttons. Ask yourself: Does the user know what it’s doing? Can they take it back? Because if they can’t, your “smart” agent is just a rogue process waiting to happen.
FAQ
Q: Isn't a minimal core just an excuse for a lazy product team?
A: No, it's a deliberate architectural choice. A minimal core forces you to build stable, open extension interfaces rather than patching every user need with a bloated default rule that breaks the moment a new edge case appears.
Q: What's the practical implication for PMs?
A: Stop tracking feature count and dialogue turns. Start tracking first-task success time, human intervention rate, and failure recovery rate. Those metrics tell you if the user actually trusts the agent enough to let it work.
Q: What's the contrarian take?
A: Most people think AI agents need to be more autonomous to be useful. The truth is, they need to be more interruptible. Autonomy without user control doesn't scale in real-world work environments.