Most AI support vendors optimize for deflection rates. They celebrate getting to "40% automation" by having their AI attempt to answer 100% of tickets, succeed on 40%...and fail on 60%.

This isn't just bad for customers—it makes for fundamentally worse products. When you optimize for coverage instead of quality, you end up building chatbots, not agents. The prevalent per-conversation pricing models in the market make this worse: vendors are paid for every ticket they attempt, so they are naturally drawn to attempt to answer more tickets!

Recently I wrote why CX teams shouldn’t focus on deflection as a key metric. In this post I’ll explain why similar deflection-focused thinking by vendors leads to worse AI products:

• Product architecture reflects different values - chatbots maximize engagement, agents know their limits

• Self-awareness is a real technical challenge - most vendors avoid the hard engineering work

• Bad metrics create bad feedback loops - you can't improve what you can't measure properly

• Testing tools get built around the wrong goals - celebrating coverage instead of quality

• Workflow design suffers - optimizing for engagement over effectiveness

Product architecture reflects values

The difference between a chatbot and an AI agent isn't just marketing. It's a fundamental design philosophy that shapes every part of the product.

Chatbots are designed for maximum engagement. They attempt to answer every ticket because vendors get paid per conversation, not per resolution. The AI tries to help with everything from password resets to complex billing disputes to medical emergencies. These are called ‘agents’ but chatbot is a better term – it’s like the over-eager kid in class who can’t help but shout out the answer to the teacher’s question, right or wrong. It’s not true intelligence.

AI agents are designed to know their limits. They understand when they can actually help versus when they should immediately hand off to a human. Self-awareness is a core capability, not an afterthought.

This architectural difference creates completely different user experiences. One traps customers in endless loops. The other gets them to the right help quickly.

The self-awareness problem is technical

Making AI "know what it doesn't know" requires solving real technical challenges. Large language models are pre-trained to be helpful – they want to attempt answers even when they lack the knowledge or capability to be useful.

We spoke to a company that makes software for doctors. Their current chatbot sometimes gets support tickets from patients looking for their doctor, often in crisis situations. The AI tries to answer these with confused, off-topic responses that could be harmful.

Lorikeet's agent instantly recognizes these as outside its scope and escalates immediately. In high-risk environments, this kind of self-awareness isn't just nice to have. It's critical for safety and compliance.

Most vendors take the path of least resistance: let the AI try everything and call the failures "learning opportunities." We invested significant engineering effort in building agents that can recognize their own limitations.

Bad metrics create bad feedback loops

When you optimize for deflection, you lose the signal you need to actually improve.

If your AI attempts 1,000 tickets and "successfully deflects" 400 of them, what does that tell you? Maybe those 400 were genuinely resolved. Or maybe customers gave up in frustration and found another way to solve their problems. You have no idea which, because you're measuring the wrong thing.

Lorikeet's approach is different. We only engage when confident, which gives us much cleaner feedback about what's actually working. When our agent handles a ticket, we know it was equipped to solve that specific type of problem. When it escalates, we know exactly what training gaps to address.

This creates a virtuous cycle. Better feedback leads to better training. Better training leads to higher confidence thresholds. Higher confidence thresholds lead to better customer experiences.

Testing tools built around the wrong goal

Products optimized for deflection have weak evaluation frameworks. They celebrate any interaction that doesn't immediately escalate, regardless of whether the customer was actually helped.

We built our testing and evaluation tools around quality assessment. Our customers can run hundreds of test conversations to validate that the AI will handle specific scenarios correctly before going live. They can audit every decision the agent makes to ensure it aligns with their brand and policies.

You can't build this kind of rigorous evaluation when your goal is just "attempt more tickets." The incentives are all wrong.

Workflow design matters

Deflection-focused products guide customers into AI interactions regardless of complexity. They are more likely to use dark patterns to prevent escalation and keep customers trapped in automated flows.

Lorikeet's workflows are designed around a simple question: can the AI actually solve this specific type of problem? If yes, it takes the ticket. If not, it immediately connects the customer with a human who can help.

This requires building more sophisticated routing logic and being honest about limitations. But it results in products that customers actually trust and enjoy using.

The bottom line

Optimizing for deflection makes vendors more money in the short term but creates worse products for everyone. It leads to design choices that prioritize engagement over effectiveness.

Great AI agents know when not to engage. They're built by teams that care more about solving customer problems than hitting coverage metrics. They use evaluation frameworks that measure quality, not just quantity.

If your current AI support tool celebrates "30% automation" while customers complain about being stuck in bot loops, you're dealing with a chatbot built for deflection, not an agent built for results.