Why "Just Add an Agent" Fails as a Product Strategy
Usage goes curious, then low, then the feature sits there — and the team upgrades the model, which doesn't help, because capability was never the problem.
A product adds a chat interface with agent capabilities because competitors have one. Usage is initially curious, then low, then the feature sits there. This happens often enough to be predictable, and the reason is that "add an agent" isn't a product decision — it's an implementation decision made in place of one.
What the decision skipped
Which user problem this solves. Not "users could ask questions" — which specific job someone is trying to do, that's currently hard, that this makes easier. Agent features added without that answer produce interfaces where users don't know what to type, which is the most common observed failure.
Why conversation is the right interface. Chat is a poor interface for most things. It's slow, it has no discoverability, and it requires the user to know what to ask. ⚠️ For anything with a bounded set of actions, buttons are better — and a large share of agent features would be better as one well-placed button that does the thing.
What happens when it's wrong. A wrong answer in a product is a product failure, attributed to you. Without an answer for this, the feature either gets hedged into uselessness or ships a liability.
Who maintains it. Prompts, tools, evals, cost, quality drift. An agent feature is an ongoing commitment, and it's usually funded as a project.
The failure sequence
Recognizable enough to write down:
- Ships with a chat box and an empty state suggesting three example prompts.
- Users try the examples, then something of their own, which works less well.
- Usage drops. The team concludes the model isn't good enough.
- The model gets upgraded. Usage doesn't move, because the problem was never capability.
- The feature stays, unmaintained, degrading quietly.
→ Step 3 is where the misdiagnosis happens. The problem was that nobody identified a job the feature does better than the existing interface.
✅ What works instead
Agent capability behind existing interfaces. The user clicks a button that already existed; an agent does the work behind it. No new interaction to learn, no empty state, no discoverability problem. This is where most successful agent features live and it's invisible to users, which is why it doesn't get copied.
Solving a job that was previously impossible. Not making an existing task conversational, but enabling something users couldn't do before — the long-tail request that never justified building a feature.
Removing a step users hate. Filling in the form, finding the right record, drafting the first version. Bounded, valuable, and the failure mode is that the user edits it.
Where conversation is genuinely right: when the space of things a user might want is genuinely unbounded and they know what they want but not where it is. Rare, and real when it happens.
💡 The test before building
Answer four questions in writing:
- What job does this do that our current interface does badly?
- Why is this interaction shape better than a button?
- What happens when it's wrong, and who notices?
- Who owns its quality in six months?
If question one has no clear answer, the feature is a competitive response rather than a product decision. That's occasionally a legitimate reason to ship something — but it should be an explicit choice rather than a confusion, because it changes what success looks like and how much to invest.
The takeaway
"Add an agent" substitutes an implementation for a product decision, and the resulting feature fails for interface reasons that get misdiagnosed as model quality. Put the capability behind interfaces users already understand, target jobs that were previously impossible rather than making existing ones conversational, and answer what happens when it's wrong before shipping. And if the honest answer is that a competitor has one — decide that deliberately, and scope the investment accordingly.