Nobody's AI Assistant Fails Because of the Model It fails because of the documents. And the escal...Nobody's AI Assistant Fails Because of the Model It fails because of the documents. And the escal...
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Nobody's AI Assistant Fails Because of the Model
It fails because of the documents. And the escalation log is the fix nobody looks at.

Every conversation I have about building an AI support assistant starts in the same place. Which model. Which framework. How to write the prompt.
Those are real questions. They're also not where these projects go wrong.
I've built one of these into a live product, on WhatsApp, and the thing that decided whether it was any good had almost nothing to do with the model. It was whether the answer existed anywhere in writing in the first place.
Retrieval is only as good as what's behind it
The architecture everyone draws is the same. Question comes in, you search your documents, you pass what you found to the model, it writes an answer grounded in that.
The diagram is fine. The problem is what's actually in the box labelled "your documents."
In most companies it's some product docs written eighteen months ago, an FAQ page nobody has touched since launch, and a support inbox where the real answers live — scattered across thousands of individual replies, in nobody's head but the three people who've been there longest.
You can put the best model in the world on top of that. If the answer to "does my plan cover international numbers" was never written down, retrieval returns nothing useful and the model has two options: say it doesn't know, or invent something.
We spend enormous effort making sure it picks the first one. But that's damage control, not a solution. The actual solution is that the answer should have been there.
The metric everyone reads backwards
Here's the part I find genuinely useful, and I almost never see anyone talk about it.
When you build this properly, the bot escalates whatever it isn't confident about. Every escalation gets logged with the question, the intent it detected, and what retrieval did or didn't return.
Most teams look at that number as a failure rate. Escalations went up, the bot is doing badly, someone should fix the prompt.
That's backwards. The escalation log is the single most valuable output of the whole system. It is a ranked list, generated by real customers, of every question your company cannot currently answer in writing — ordered by how often people ask it.
You could not commission better research than that. Companies pay agencies for worse.
What to actually do with it
Read the escalations weekly. Group them. The clusters are your writing queue.
Someone writes the missing answer — properly, once. It goes into the knowledge base, gets embedded and indexed, and the next customer who asks gets an immediate grounded answer instead of a wait for a human.
That's the loop. Question, retrieval, escalation, documentation, back into the index. Every turn of it makes the assistant better without anyone touching the model, the prompt, or the framework.
And the second-order effect is the one clients don't expect: the documentation gets better for humans too. New support hires ramp faster. The website FAQ stops being fiction. You didn't just build a chatbot, you built a forcing function for writing things down — which is a thing every company knows it should do and none of them prioritize.
The uncomfortable conversation
This does mean the honest answer to "can you build us an AI support agent" is sometimes: not yet, usefully.
If there's no real documentation and no archive of resolved tickets, there's nothing to ground answers in. Building the assistant first means shipping something that escalates almost everything, and everyone concludes the technology doesn't work.
I'd rather have that conversation in week one than in month three. Usually it turns into a smaller first scope — pick the twenty questions that make up most of the volume, write those properly, launch narrow, then widen using the escalation log.
Narrow and correct beats broad and confidently wrong. That's true of the launch and it's true of every week afterwards.
What this means about the work
The engineering here isn't hard in the way people expect. Retrieval, a queue, some Lambdas, a confidence threshold, an escalation path — I've written about the architecture before and none of it is exotic.
The hard part is organizational. It's convincing a support team that the bot saying "I don't know" fifty times a week is a gift rather than an embarrassment, and getting someone to act on the list.
The model is not your bottleneck. It hasn't been for a while. Your bottleneck is that nobody wrote it down.

If you're running one of these — are you reading your escalation log? I'd genuinely like to know how many teams have that as a weekly habit versus a dashboard nobody opens.
Post image
Back to feed
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started