The Two AI Failure Modes Nobody Wants to Talk About

Hey Wranglers,

I've spent the last few months talking to IT leads and HR managers about AI. Not the theoretical version - the actual version. What they're trying, where it breaks, and why so many of these projects stall out after a promising start.

A pattern has emerged, and it maps pretty cleanly onto the two teams we work with most.

Key Takeaways

Overconfidence kills AI projects just as often as fear does. IT teams that move fast without building a visibility layer first are setting themselves up for a trust collapse the first time the AI gets something wrong.
HR's hesitation is not a maturity problem. It's a reasonable response to being asked to trust a system they can't see. The answer is transparency, not pressure to move faster.
The transparency layer is not optional. If your agents can't see what the AI is saying to employees, you don't have an AI-assisted help desk. You have a black box with your name on it.
Trust has to be earned before control is handed off. The teams that get the most out of AI deflection are the ones who spent time in copilot mode first, watching the outputs, catching the misses, and building confidence in what the system does well.

Real Talk: Solving the IT vs HR debate in AI implementation

IT teams are overconfident. HR teams are scared. And both assumptions are causing problems.

What I see happen: an IT team runs a quick test, decides they're ready, and turns on deflection before building any visibility into what the AI is actually saying. Then an employee gets a wrong answer. Nobody caught it, so confidence tanks, and the project stalls.

HR goes the other direction. They're scared of AI and will tell you so. Some of that is about the answers it might give. HR handles sensitive stuff. Handing it off to a bot feels like a liability.

Here's the thing though. HR's instinct is actually correct.

The part that nobody talks about enough is visibility. Your agents and HR managers are being asked to trust a system where an employee asks a question, the AI answers, and the human responsible for that answer never sees what was said.

That's uncomfortable, and it should be.

❝

The solution isn't to slow down. It's to make the outputs visible.

Every AI response surfaced somewhere your team can see it. Every answer rateable. The transparency layer isn't optional. It's what makes the whole thing trustworthy over time.

From the Trenches: Legacy platforms and their AI promises

I've been on the road a lot lately. A few things I keep hearing:

The large legacy platforms are all making AI promises right now. Big marketing budgets, big announcements, ambitious roadmaps. What I'm not hearing is a lot of confidence in the outcomes. You have companies that have been running the same core software since the early 2000s trying to layer AI on top of it. It's a bolt-on. The architecture wasn't built for it, and the teams using it can tell.
I'm also seeing more companies come to us after trying to build something themselves. Someone on the team convinced leadership that they could vibe code a solution into existence. A few months later, they couldn't support it, or it failed, or the person who built it left. Then they come to us. And those are actually some of our best customers, because they've already learned what they didn't know.

The noise in this space is real. But so is the gap between what's being promised and what's being delivered.

The Setup: Where do you actually start with AI for your help desk?

I get this question a lot, and here's the exact sequence we recommend:

Step one: Get ticketing working first.
Before any AI, you need to be capturing requests consistently. If your real ticketing system is still a mix of Slack DMs and shoulder taps, AI has nothing to work with. Get one team routing requests through a single channel. Get your agents comfortable triaging and closing tickets.

This part sounds boring, but it's the foundation for everything else.

Step two: Start with copilot, not deflection.
Once ticketing is running, the first AI capability to turn on is suggested replies, not full deflection. Your agents are still in the loop. The AI drafts a response based on your knowledge base and past tickets. The agent reviews it, edits if needed, and sends it.

Three things happen: you catch bad answers before they reach employees, your team starts to trust the outputs when they're good, and you start to build a real knowledge base for AI to work from.

Step three: Earn your way to deflection.
Full AI ticket deflection, where the system responds directly without a human reviewing it first, should come after you've seen enough suggested replies to trust the quality.

A few weeks of copilot mode is usually enough. By then, you know what the AI is good at and where it still needs help. You turn on deflection in those specific areas first, then expand.

The companies that skip step two and go straight to deflection are the ones whose projects stall out. The technology works, but nobody built the trust layer first.

Inside Wrangle: How our Microsoft Teams expedition is going

We launched in Microsoft Teams earlier this year, and it's been one of the more interesting product challenges we've taken on.

The most interesting part has been learning how differently people behave in the two platforms.

Slack users are channel-native, but Teams users behave differently. They use it more for meetings and video, less for async communication. They're not as channel-based. The way a request gets made, the way people ask questions, even the knowledge bases they pull from, it's all a bit different.

So we're not just extending Wrangle into a new platform. We're figuring out where the natural entry points are for a Teams user specifically: Where do they want to create a ticket that's different from where a Slack user would? What does AI deflection look like when the conversation patterns are different?

We're early in that work. But the signal so far is that the problem is just as real in Teams as it is in Slack. Requests going untracked, agents overwhelmed, no visibility into volume or performance. Same problem, different surface.