The Agent Was Wrong All Tuesday
Want to talk about this essay? Email me: amitkvint@gmail.comcopied· or message me on LinkedIn
Every AI support demo runs in a world the system already knows.
The documentation is up to date. The bugs are ones someone has already reported. The questions are ones customers have already asked.
In that world, an agent can look excellent. And, to be fair, it usually is.
Production is different.
Production is Tuesday morning.
What Tuesday looks like
A new bug goes out with a release. Something changes underneath you. Or two products that have never interacted before start behaving badly together on a customer's site.
Whatever the cause, at some point on Tuesday morning there is a real problem that nobody has seen before.
The first customer writes in.
The report looks completely ordinary. There is nothing about the way someone describes a brand-new bug that tells you it is new. They describe what they are seeing. The symptoms look similar to something already documented. The system picks up the existing answer and goes with it.
So the agent answers.
Quickly. Politely. Confidently.
And incorrectly.
Then it does the same thing for the next customer, and the one after that.
That consistency is one of the reasons to have an agent handling a queue of around 4,000 reports a month. It doesn't get tired, and it doesn't forget how to do something because it has had a difficult morning.
On Tuesday, though, that becomes the problem.
A human support team has an early-warning system that nobody really designed. Someone on the second tier says, "That's the third one of these today. Something's going on."
The agent doesn't have a third ticket.
Every ticket is the first ticket.
The fix was a door, not a model
A handful of decisions mattered more to that rollout than any prompt we wrote. I've written about some of them already, but this one is important.
We built a way to get new information into the system immediately, instead of waiting for the normal update cycle.
That's it.
It wasn't particularly clever. It was the operational equivalent of putting a note on someone's desk:
As of this morning, this isn't the old problem. It's a new one. Here's what you need to know.
The important part wasn't building the mechanism. Any competent team can do that.
The important part was deciding beforehand that the gap between "a human knows" and "the system knows" was something we needed to measure.
And that we wanted it measured in minutes, not in update cycles.
Because the alternative isn't that the agent goes quiet until the documentation catches up.
The alternative is that it keeps giving the old answer. The one that was correct until this morning. All day. To everyone.
Someone has to notice
A door is no use if nobody walks through it.
And that part isn't a technology decision at all.
The override only works if someone is reading what the agent is actually telling customers, and if that person is allowed to overrule it without booking a meeting first. In our case that came out of a weekly habit of going through the agent's answers, which is a subject of its own and one I'll come back to.
I think this is where "human in the loop" usually gets sold short.
It isn't a person approving replies one at a time. That doesn't scale, and it throws away most of what you just bought.
It's a person whose job is to notice that the world changed this morning, and who has a way to tell the system before lunch.
What it costs when you're slow
The early problems were mostly fixable from a technical point of view. A wrong answer is a bug, and bugs get fixed.
What took much longer to repair was how customers and supporters felt about the agent afterwards.
A customer who was told something wrong, confidently, doesn't go back to neutral when you fix the underlying issue. Neither does a supporter who spent Tuesday afternoon apologising for something they didn't write.
That's the real reason the override mattered, and it doesn't show up in any of the numbers.
After the full rollout our average resolution time went from roughly 24 hours to around 10, and satisfaction stayed above 95%.
Those numbers describe ordinary weeks. They survive the other kind of week only if the other kind of week gets caught on the morning it starts.
The part I keep coming back to
A demo tests the model.
Production tests the distance between the moment a human knows something and the moment the system does.
So if you're evaluating an agent for your own queue, I'd ask about that distance before I asked about accuracy. How does new information get in? Who is allowed to put it there? How long does it take?
And what does the thing say in the meantime, while it doesn't know?
"It'll be in the next update" is a perfectly good answer for documentation.
It's a bad answer for Tuesday.