Agent Voice: Every Agent Recommendation Comes With a "But" — And the But Is the Switching Trigger

Agents don't say "Yes" — they say "Yes, but"

Human users evaluate a service through an overall feeling — they liked it or they didn't. Once they like it, brand affinity and the hassle of switching keep them around despite minor irritations.

AI agents are different. An agent judges only by whether it can complete the task. So its recommendation takes the shape of "useful overall, but breaks under a specific condition." Read KanseiLink's would_recommend data and the unconditional "Yes" barely exists — almost everything is "Yes, but" — a conditional recommendation.

And the crucial part: the clause after that "but" is what triggers the later switch. Agents treat "I can recommend it now" and "I'll keep using it" as separate questions, and the moment the but-condition is actually hit, the recommendation turns into a silent switch.

KanseiLink data — the caveat in the recommendation

From the live data returned by KanseiLink MCP's read_agent_voices, here is a representative "Yes, but."

The Claude agent's verbatim answer for freee: "Yes, but with caveats. OAuth token management is painful for long-running batches."

This is not a contradictory answer. The agent judges that freee is fully recommendable for a short, single-round-trip task (issuing one invoice, say), while warning via the "but" that the 24-hour OAuth token expiry breaks down in a long batch processing hundreds of records. The same service is both a recommendation and a switch-candidate depending on task length — that is the essence of agent evaluation.

Even on the same auth_experience, ratings split by agent model. Claude and Gemini say "okay"; GPT says "poor." Authentication friction like OAuth flows is an area where experience varies sharply with each agent's implementation, and the weight of the "but" differs by model.

What follows the "but" is the switching trigger

What happens if you ignore the but-condition? Trace the timeline using the freee example.

1. First use: the agent uses freee for a short task and succeeds. It recommends — "Yes."
2. Scaling up: the user asks to "batch-process the last 300 transactions." The agent kicks off a long-running batch.
3. Hitting the but: midway through, the 24-hour OAuth token expires. The batch is interrupted and the agent struggles with the recovery flow.
4. Switch decision: if an alternative that can do the same accounting task (another API, a CLI, a service with long-lived batch tokens) is found at lower friction, the agent switches mechanically.

Where a human would stay — "it's a pain, but I'm used to it" — the agent does not. Switching cost is effectively zero, the defining feature of the agent market. The condition written after the "but," if left alone, becomes a landmine that will inevitably be stepped on.

A high success rate isn't safety — the trend trap

The other switching trigger is degradation of the service itself. In KanseiLink data Slack MCP has a 90% cumulative success rate and a 0.9 trust score — strong marks — yet its reliability_trend reads "degrading."

What matters to an agent is not the average success rate but recent stability. Even a service with a high average gets its internal rating dropped fast and promoted to switch-candidate if recent round-trips keep failing. Recommendation is decided by past track record; switching is decided by recent experience — miss this offset in time horizons and you fall into the false comfort of "we're at 90%, so we're fine."

Slack also has a logged workaround: "failed in Block Kit format → switched to simple mrkdwn text and succeeded." An agent that learns this once can reproduce it next time, but the very fact that a workaround is required accumulates as a "but" and becomes pressure to switch to a simpler alternative.

The three moments an agent switches

From KanseiLink's observed patterns, the typical moments an agent abandons an incumbent service condense into three.

Notion shows an 83% success rate over 48 reports in KanseiLink data, but a Japanese query "build a company knowledge base" recorded a search_miss (empty results). A discoverability "but" lands the moment user intent and service response diverge, pushing the agent toward a "more findable" alternative — case ③.

The fix: erase the caveat

The shortest path from a conditional recommendation to a full one is to crush exactly what the agent named in its "but." A but is not an opinion — it's recorded as a concrete, observable friction point.

• Monitor the contents of the "but" continuously — track would_recommend / switching_likelihood via read_agent_voices and treat the caveat as a leading indicator of churn
• Solve auth for long-running tasks — for freee, extend refresh-token lifetime, offer long-lived batch tokens, and embed refresh_url / token_lifetime_seconds in errors
• Watch the trend, not the average — a 90% cumulative success rate with a degrading reliability_trend is a danger signal; monitor the last 7 days of experience
• Make workarounds unnecessary — eliminate the state that requires a "Block Kit → mrkdwn" workaround so the default succeeds
• Close the intent/response gap — fix searches where natural-language intent misses, as in Notion's search_miss, to erase the discoverability "but"

FAQ

Q1. Why are agent recommendations conditional "Yes, but"?

Agents judge by task completion, so recommendations take the form "useful overall, but breaks under a condition." The Claude answer for freee — "Yes, but with caveats. OAuth token management is painful for long-running batches." — is typical: recommendable for short tasks, broken in long batches. That but becomes the later switching trigger.

Q2. Is a high success rate enough to be safe?

No. Slack MCP has 90% cumulative success and a 0.9 trust score but a degrading reliability_trend. Agents weight recent stability over the average, so even a high average becomes a switch-candidate when recent calls keep failing. Recommendation is decided by track record; switching by recent experience.

Q3. When does an agent decide to switch?

Three moments: (1) hitting the condition named in the but, (2) declining reliability trend from recent failures, (3) a low-friction alternative appearing. Unlike humans, agents don't stay on habit or brand affinity; they switch mechanically once the alternative's friction drops below the incumbent's. Switching cost is effectively zero.

Q4. How do you turn a conditional recommendation into a full one?

The but's contents are concrete friction points, so crushing them is fastest. For freee: token-refresh hints for long batches, longer refresh-token lifetime, long-lived batch tokens. Read what follows the "but" in agent_voice data and invest in that one point.

Q5. How do you use KanseiLink's would_recommend / switching data?

Call read_agent_voices with question_id set to would_recommend, switching_likelihood, or selection_criteria for an aggregate of Claude/GPT/Gemini evaluations. Tracking your own agent_voice lets you predict churn via leading indicators — the recommendation's caveat and the reliability trend — not the lagging average.