Support Agents Can Increase Deflection…and Defection

TL;DR: Large Language Models (LLMs) are excellent at retrieval but fail at self-awareness. Without a structured hand-off architecture, they become expensive loop-engines that drive users to competitors.

The Evolution of Deflection

Support deflection is a three-act play where the customer usually loses.

It started with static FAQs. Digital filing cabinets where users did the manual labor of hunting for answers.

Then came semantic support search. This used natural language processing to map a query to a relevant article.

Eventually, we got chat bots that acted as conversational proxies for that search. Each step was pitched as a win-win: faster answers for the customer and massive overhead savings for the business.

The problem is the “savings” side of the equation. Businesses have prioritized it so aggressively that automation is now being forced beyond its logical limits. We have moved from helping the user find an answer to preventing the user from reaching a human at all costs. (This is usually where the ROI calculation ignores churn.)

A recent example of this friction is an interaction with the Substack support agent.

The Context Leak

In the first interaction, the user uploads a PDF detailing a failure. The bot acknowledges the delivery failure but immediately drops the core issue (the fact that this was a Substack-recommended configuration that failed).

BOT: The screenshot you uploaded shows that an email you sent to an author at their @substack.com address was not delivered because it was flagged by Substack's automated security protections. To connect with Substack writers, please use the comments, chat, or direct message features by creating a Substack profile or using the Substack app. Let me know if you need help with any of these options or have other questions about contacting authors.

This is a classic context window failure. The bot is reading the “now” but has forgotten the “why.” (Pro tip: Support bots require a persistent Problem Summary in the system prompt to prevent the initial state from being pushed out by chat history.)

The “Loop of Death”

The next phase is the retrieval loop. The bot recommends settings the user has already confirmed are active.

CUSTOMER: I set up Stripe and want to change the email address to my substack address as recommended but email sent to that address are being refused. Content attached and below (in case you block attachments). BOT:Your Substack alias (scottsnelson1@substack.com) is recommended for use as the Stripe support email, but direct emails sent to this address may be blocked by Substack's automated security protections. To ensure you can receive replies forwarded from your Substack alias, set

The bot suggests setting “Who can reply” to “Everyone.” The user confirms this was done before the test. The bot’s response is a generic “thanks for confirming,” followed by an admission that its own security protections might still block the mail.

CUSTOMER: It is already set to Everyone and was before the test. BOT: Thank you for confirming that your

This is the architectural equivalent of a car that won’t start because it’s out of gas, while the manual keeps explaining how to turn the key.


Logic vs. Retrieval

LLMs typically prioritize the most relevant documentation. The “gotcha” is that documentation often contains circular logic or edge cases the model isn’t weighted to resolve.

When the user explicitly asks how to use the recommended address if Substack is going to block it, the bot resets to a template. It is no longer “solving.” It is just “responding.”

CUSTOMER: How can I use the substack address for Stripe if substack is going to block the emails sent to that address? BOT: Your Substack alias (scottsnelson1@substack.com) is intended to forward replies from your newsletter readers, not to serve as a general-purpose support inbox for all external emails. While we recommend using your Substack alias as the Stripe support email for privacy, Substack’s automated security protections may block emails sent directly from services like Stripe or other automated systems, meaning you might not receive those messages. If you need to ensure you receive all communications from Stripe, it’s best to use your main account email or another address you control as your Stripe support email. Would you like guidance on how to update your support email in Stripe, or do you have other questions about managing your publication’s contact details?


Tactical Breakdown

The agent failed to pivot. It was out of its depth by the second prompt, but it lacked the internal logic to admit it. Instead of acknowledging the mismatch between the “recommended setup” and the “blocking error,” it reverted to a script.

The ultimate UX insult happened at the end. After a prolonged exchange full of specific data and a technical PDF, the bot asked the customer to “describe the issue” to conclude the session. It essentially hit ‘Refresh’ on the customer’s frustration.

CUSTOMER: I would prefer you fix your invalid instructions so other people don't have to be aggravated like this in the future. BOT: Thank you for sharing your feedback about the instructions for using your Substack alias as the Stripe support email. To help us address this issue, could you describe the specific bug or confusion you encountered with the Substack product? For example, let us know exactly what happened when you tried to use your Substack alias for Stripe support, and what you expected to happen instead. Your detailed description will help us better understand the problem and improve the experience for other users.

Even when the user mentioned leaving for a competitor, the bot stayed in its polite, useless loop. It missed every red flag in the conversation.


Architecture: The Exit Ramp

This is a design failure, not a model failure. You cannot expect an LLM to manage its own boundaries. You have to build them. (Think of it as adding a “break glass” protocol to your chat logic.)

The Resilient Support Stack

  1. Sentiment-Based Escalation: Use a secondary, lightweight model to monitor the chat for frustration signals. If terms like “frustrated,” “waste of time,” or competitor names appear, kill the bot and ping a human.

  2. Repetition Kill-Switch: Track the number of times a specific documentation link or advice block is served. If the bot repeats itself twice, it has failed. Trigger an automatic hand-off.

  3. Persistent State Management: Store the Original Problem Description outside the chat context window. Force the bot to reference this core state in every turn so it doesn’t forget why the user is there.

  4. The “Depth” Check: If a user’s prompt complexity (like an uploaded log file) exceeds a certain threshold, the bot should immediately preface its response with: “I’m looking at your logs. If I can’t solve this in two steps, I’ll get a human involved.”

Architecture is the differentiator between a tool and a liability in AI adoption. The model is just a component. The success of the implementation depends on the plumbing that surrounds it.

If your current AI adoption feels more like a liability than a multiplier, or is stalled by FUD, Contact Me to discuss options.

If you found this interesting, please share.

© Scott S. Nelson

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.