Nobody Wants Your In-App AI Assistant

01The short answer

Stop building a general-purpose assistant inside your own product and start making your product callable from the assistant your customer already uses. The sidebar bot assumes the user is sitting in your app when they have the question. For a growing share of technical and operator buyers that assumption is simply false. They are in an agent, one agent, with their own context loaded, and the thing they want from you is access, not another conversation partner.

The consequence is uncomfortable but not complicated. If a customer cannot invoke your core capability from where they already work, they will pick the competitor whose interface is easier to hook into, or they will script the narrow slice of your product they actually need and stop paying you for the rest. That is not a hypothetical failure mode. It is the ordinary behaviour of a buyer who can now write working code by describing it.

There is a real counterargument, and it is the best thing written on the subject: the UI does not disappear, it changes job. Section six steelmans it, because a version of this argument that pretends the web app goes away is a version you should not act on.

02The request changed shape

The question buyers ask has moved from “do you have an API” to “does it work with my agent,” and it moved fast enough that most roadmaps have not caught up. This is observable in the places founders talk to each other rather than to analysts.

The clearest statement of the shift came from an r/SaaS post that drew 162 upvotes, and it is worth quoting at length because it describes the industry behaviour and the buyer behaviour in the same breath:

A founder running a much smaller business described the same thing from the demand side. At roughly 1.1k MRR across 40 customers, small enough that nothing about it is enterprise theatre, the reported change was: “Then the requests changed shape. People stopped asking ‘can I call your API’ and started asking ‘can my agent use your product.’ Claude Code, Cursor, custom agents. They didn't want more UI. They wanted their tools to have the same access they have.” (via r/SaaS). The same founder noted that a paying customer had already built a community integration on top of the public API and published it on GitHub, which is a customer doing your roadmap prioritisation for you by shipping the thing.

The most concrete data point in this cluster comes from a founder who ran a structured beta with 81 users and published the post-mortem. Fifteen percent converted to paid. Roughly fifteen percent activated and then never opened anything again. And the single most requested feature was not a feature of the product at all:

Read those three together and the pattern is not that people hate AI in software. It is that they have already chosen where their AI lives, and it is not inside your product. Support queues show the same rotation. One founder described tickets moving from requests for API docs to “why is my agent getting rate limited”, from users who “don't even know what endpoints the agent is calling under the hood, they just know their workflow stopped” (via r/SaaS). That is a customer whose relationship with your product is now mediated entirely by something you did not build.

03Why the sidebar bot gets dismissed

The in-app assistant is not being rejected because it is bad AI. It is being rejected because it occupies the exact screen position, and asks the exact opening question, of a decade of things users learned to close. Position is destiny for a bottom-right widget.

An r/UXDesign thread asked the honest version of the question directly: is adding an AI assistant to a product just lazy design? The post came from a software engineer who had shipped one, could give it tools to perform real actions, and then talked himself into doubt about whether it was a band-aid for bad navigation. The top reply, and the most useful sentence in the whole thread, was about pattern inheritance:

A UX researcher in the same thread went further and described exactly the behaviour this article is about: “People want the LLM to process on the back end and continue to use their preferred chat tool.” (via r/UXDesign). Note what that is not. It is not a rejection of language models in software. It is a preference about where the conversation happens, and the user has already decided.

The mechanical failure of the retrieval chatbot has been described more brutally elsewhere, and the description is accurate enough that it is worth keeping in front of any team about to build one:

That is the whole indictment in four sentences. The assistant adds a translation step in both directions. The user translates their problem into a question, the bot translates your documentation into prose, and the user then translates the prose back into which button to press. Three translations added to a flow whose actual defect was that the button was hard to find. As one commenter in the same r/UXDesign thread put it, using AI to automate a bad process does not make it a good process, it makes it a bad process that has been automated and is now harder to remove.

Underneath the UX objection sits a commercial one. The label has stopped working. In a 99-comment r/startups thread asking whether the industry is overestimating how much users want AI features, the top reply at 53 upvotes was that users want problems solved and do not care whether it is AI 99% of the time. Several founders in that thread were explicit that the demand is coming from investors rather than customers: one wrote that products with a random, useless AI chatbot slapped in have one look because that is exactly what happened. Another reported that being the only non-AI product in a pitch meeting initially hurt and then started to help as investor fatigue set in. A practitioner in r/ProductivityApps named the organisational mechanism precisely: “poor top down leadership pushing AI adoption is creating an ai feature slop factory, rather than anything genuinely useful.”

04The tab math

The per-product assistant does not scale in the one dimension that matters: the number of products a person uses. A single sidebar bot is a reasonable thing to build. Fifteen of them, one per vendor, each behind its own login, each with its own idea of what context it has, is not a workflow anybody will adopt.

This is the arithmetic every vendor does from inside their own product and gets wrong. From the vendor's seat there is one assistant and it is clearly an improvement. From the buyer's seat there are now fifteen, none of which know what the other fourteen know, and the cost of using any one of them is a context switch plus a re-explanation of a situation the user has already explained to their own agent that morning.

The audience vocabulary for this is unusually consistent, which is a reliable sign that a real thing is being described rather than a trend being narrated. Practitioners call it “the Death of the Dashboard” and describe the preference as tools that work in the background rather than another complex UI to manage (via r/SaaS). The pitch that lands in r/mcp is three fragments long: “No new dashboard. No extra tab. Just ask Claude.” Another framed the alternative as avoiding “the 15-tab BI dashboard” in favour of asking a plain question. A finance practitioner described the win as avoiding “the full ‘logging in to a financial portal’ drama when a client asks a finance question.”

There is a second, quieter cost that only shows up in daily use. The central agent accumulates context: the repo, the account, the campaign, the argument you had with the data yesterday. Your in-app assistant starts every conversation from zero and can never be told the parts that live in other systems. Even when your bot is technically better at answering questions about your product, it is worse at answering the question the user actually has, because the user's question almost always spans more than one product.

05What happens when you are not callable

A buyer who cannot reach your capability from their agent does not file a feature request. They build the 20% of your product they actually need, and the remaining 80% stops being worth paying for. This is the part of the argument with teeth, and it is new. Five years ago the build-versus-buy calculation protected incumbents because building was expensive. It is now cheap enough that the calculation runs differently for any capability that is mostly plumbing.

The r/SaaS post that framed this shift stated the consequence directly: if a customer cannot invoke your core capability through their existing agent or workflow, they will pick a competitor whose interface is easier to hook into, or simply script a lightweight internal tool themselves. The quieter version of the same event, reported by a founder in the same community, is the one that actually shows up in a pipeline review: “Had one warm lead go cold after their eng team built an internal tool before I could close.”

Notice that this loss is invisible in a competitive analysis. Nobody logs it as a loss to a named vendor. It appears as a deal that stalled, an account that went quiet, a champion who stopped replying. The replacement is a hundred lines of the buyer's own code running on a schedule they control, and it will never appear in your win-loss data because there was no competitor to record. If you are formalising that analysis, our guide to build versus buy for competitive intelligence walks through the same calculation from the buyer's side, which is the side you now have to argue against.

The support-side version of the same dynamic was described by a founder who started building an autonomous in-product support agent and abandoned it mid-flight:

The same founder added the observation that makes this urgent rather than interesting: “I see people in support communities building DIY versions of this with Claude Code and MCP servers every week.” Every week that your capability is only reachable through your own UI is a week in which someone competent enough to be your best customer is evaluating whether to stop being one.

Be honest about the size of this cohort, though, because the hype overstates it. One founder who shipped an integration reported that maybe five to ten percent of users ask for it and use it, describing it as “a bet on the future” (via r/SaaS). Another noted that agent access comes up from the technical buyer and not the economic buyer, and that the VP of Ops or the CFO still does not know what the protocol is. Both are true. The cohort is small, and it is the cohort that writes the evaluation criteria, builds the internal alternative, and tells the rest of the company what to buy. A third practitioner put a clock on it: when IT is looped into an evaluation and already runs an agent stack, agent compatibility becomes a shortlist filter rather than a nice to have, and if you are not hearing it in your pipeline yet, you probably will within two quarters.

06The counterargument, steelmanned

The strongest objection to everything above is also the most useful thing in this article: the UI does not disappear, it changes job. The agent gets the repetitive path. The UI keeps the judgment path. Any vendor who reads the agent-native argument as permission to stop investing in their product surface has misread it.

The operational version of this appeared as the highest-voted reply on the very post that argued product UI is becoming secondary, which is the best evidence that the community holds both ideas at once: “I get the appeal of never opening another SaaS dashboard, but I'd still want somewhere to check permissions, failed actions, and what the agent changed. MCP can be the front door, but removing the UI completely sounds like something we'll regret the first time an agent quietly gets it wrong.” (via r/SaaS). That is not a hedge. It is a specification. Permissions, failed actions, and a diff of what changed are three concrete screens, and most agent-facing products do not have any of them.

The design objection is equally fair. A mature SaaS interface encodes years of decisions: shortcuts, defaults, a learning curve deliberately shaped for the person who uses it forty hours a week. As one practitioner put it, “replacing all that with an agent clicking behind the user's back feels like throwing the baby out with the bathwater” (via r/B2BSaaS). Chat is a bad interface for anything with more than a few parameters, for anything spatial, and for anything where the user needs to see ten things at once and compare them.

And there is a real case for the in-app assistant that the argument above does not touch. A builder in the r/UXDesign thread described a product holding roughly 100,000 minutes of video content and made the obvious point that a chat interface is a good way to find a needle in a haystack that size. Another described shipping one as a fallback for when the UI does not communicate clearly enough what to do, and framed it as “easy to access documentation”, treated the way you would treat documentation rather than the way you would treat a feature. Both of those are legitimate. Both are narrower than what most teams are actually building.

Where this leaves us is not “UI bad, agent good.” It is a split of labour with a clear seam. Work that is repetitive, scriptable, and cheap to get wrong once belongs on the agent side. Work that is consequential, comparative, or needs a name attached to the decision belongs in the UI. The failure mode of the last two years is that vendors put a chat box on the judgment side and left the repetitive side locked behind a login.

07The three surfaces the UI keeps

Applied honestly, the judgment-path rule leaves three surfaces in the web app, and everything else is a candidate to move. This is a design constraint rather than a prediction, and it is worth writing on a whiteboard before your next roadmap argument.

Everything outside those three is fair game. Running a query, pulling a list, checking a status, comparing two things, exporting a slice, re-running last week's analysis with a different date range: all of it is repetitive-path work, all of it is better initiated from wherever the user already is, and none of it needs a screen you designed.

Notice that this framing also tells you what your in-app AI should have been. Not a general chat box. A better approval queue, with the agent's proposed change rendered as a diff and the evidence for it attached. That is an AI feature nobody rolls their eyes at, because it is doing judgment work in the place judgment work belongs.

08The callable-product test

Being callable is not the same as having an API. The test is whether a competent user, with an agent and no help from you, can get your core outcome in one session. Most products with excellent REST documentation fail this, because the core outcome is assembled across six endpoints and three pieces of undocumented sequencing that live in a support engineer's head.

Six checks, in the order they usually break:

1. 1

   One call gets the outcome, not the raw rows

   Expose one tool per real user intent, not one per underlying endpoint. If getting the answer requires chaining four calls in a specific order, the agent will get the order wrong and you will get a support ticket about rate limits.

2. 2

   Authentication survives a machine

   A long-lived key pasted into a config file is a credential you cannot revoke centrally and cannot audit. An OAuth grant is one connection to add and one to revoke. This matters more, not less, when the caller is an agent running unattended.

3. 3

   The permission model survives higher call frequency

   The gating rule practitioners converge on: prioritise agent access when users already have API-shaped workflows and your existing permission model can survive being called by an agent at much higher frequency. If either is false, agent access turns into support debt fast.

4. 4

   The agent surface cannot drift from the API

   The pattern that holds up is a dumb wrapper: every agent-facing tool calls the same endpoints under the same key, so rate limits and permissions are identical to what a user gets. Zero new business logic, which also means zero opportunity to drift.

5. 5

   Errors are written for the model, not the log

   A structured, plain-language reason (this record does not exist, versus this action is not permitted for your role) measurably reduces the agent retrying the same failing call in a loop. Your worst failure is a 200 with a garbage payload, because nothing looks broken.

6. 6

   It ships with the feature, not after it

   Every new capability exposes its agent-facing tool in the same change as the capability. A feature that exists only in the web app is a feature the customers who matter most will never reach.

One warning on the other side of this ledger, because the corrective to assistant fatigue should not be connector fatigue. Every tool you expose consumes context in the client on every request, and a bloated tool set degrades the model's ability to pick the right one. Practitioners measuring this report that a handful of common servers can consume tens of thousands of tokens before the user types anything. Ship few tools, each mapped to something a person actually wants. We wrote the demand-side version of that argument in the MCP-first GTM stack, and it applies to your own surface as much as to the ones you connect.

09Leading indicators to check this week

You do not need a strategy offsite to find out whether this is happening to you. Four signals are already sitting in systems you own. None of them requires a new tool to read.

There is a fifth signal that lives outside your systems, which is what buyers say about you in the places they talk to each other rather than to your sales team. Complaints about a competitor's missing integration, threads asking whether anyone has scripted around a vendor, a review that says the product is fine but locked in its own UI: those are switching signals with a specific cause attached. Finding them systematically is what competitor intelligence is for, and running that search from an agent rather than a dashboard is, fittingly, the point of this entire article. We covered the mechanics of doing it that way in running competitive intelligence with AI agents.

Worth admitting what we do not know. Nobody has a credible public number for what share of B2B software revenue is currently influenced by agent compatibility, and anybody who quotes one is guessing. The evidence in this article is practitioner testimony and community voting behaviour, which is good for direction and bad for magnitude. The honest position is that the direction is clear, the timing is not, and the cost of being callable is low enough that you do not need the magnitude to justify the work.

10What we built, and what we refused

We build in this category, so the honest thing is to show our own work against the argument rather than exempt ourselves from it.

Linkeddit is demand and competitor intelligence: measuring where AI answer engines recommend competitors instead of you, tracking what those competitors ship and what their users complain about, and turning that signal into pipeline and content. The rule we hold ourselves to is that if the capability is something a frontier model already does well once it has our data, we do not build it. We ship the measurement and the evidence. The customer's agent does the writing.

The corollary is a shipping rule rather than a philosophy: every new integration exposes its agent-facing tool in the same change as the integration, not in a later phase. Practically, that means the whole product is reachable from a single connector rather than five, with one OAuth grant to add and one to revoke, and answer engine optimization work happens in whichever assistant the customer already has open. If you want the concrete version, the connector setup walkthrough is a URL, a client id, and one browser sign-in.

None of which is a claim that we got the balance right. The web app still holds surfaces that could move, and we still have to decide, feature by feature, which side of the seam a thing belongs on. But the default has flipped. The question is no longer “what should the assistant in our app do,” it is “what can the customer's agent do once it can reach us,” and the second question produces a much shorter roadmap and a much better product.

Frequently asked questions

Sources

• The single biggest shift coming to SaaS (via r/SaaS, 162 upvotes)
• Is adding an AI assistant/chatbot to a product just lazy design? (via r/UXDesign)
• Are we overestimating how much users actually want AI features? (via r/startups)
• Ran an 80 person beta: had the price wrong by half and the customer wrong entirely (via r/SaaS)
• Nobody Cares About Your AI Features (Launchera, July 2026)
• AI fatigue is real and nobody talks about it (Siddhant Khare, February 2026)

Community quotes are attributed to the platform they were published on and never to individual accounts. Upvote counts and comment counts are quoted as of the date this article was researched and will have moved since. Quotes drawn from r/B2BSaaS, r/mcp, r/ProductivityApps and r/sales were collected in the same research pass and are attributed to their community inline; where no permalink is listed above, the quote was gathered through community search rather than from a single canonical thread.