I'm not going to dress this up as one clean story. It's the same shape every time. A support integration passes the demo on a Tuesday, everyone claps, and by the second week it's confidently telling a customer about a refund policy that does not exist. No specific war story survives anonymization here, so I'm writing from the pattern, not from one company. The pattern is what matters.
Why did the integration look done in the demo?
The demo looked done because a demo only tests the happy path. You feed the model the input you already know it handles. The record is complete. The API responds in 200 milliseconds. The customer asks the question you rehearsed. Nothing is null, nothing times out, nobody goes off-script. Under those conditions the model looks brilliant, because you built the conditions.
I have sat in that room. The screen shows a clean exchange. The bot answers, the answer is right, and the person paying for it decides the hard part is over. It isn't over. The demo was the easy 20 percent wearing the costume of the whole thing.
The wiring was never the hard part. Connecting the model to the CRM, the ticket system, the knowledge base — that's a weekend of plumbing. I used to think the plumbing was the project. It's the part that shows up in the demo precisely because it's the part that's finished.
What actually broke in week two?
In week two the real inputs arrive, and real inputs are ugly. A customer record comes back with a null field the demo never had. An upstream API times out and the retry logic doesn't exist yet. A malformed record slips through. And a customer asks something nobody scripted, and the model answers anyway — confidently, fluently, and wrong. That last one is the expensive failure.
Here is the thing about a language model that people building their first integration underestimate. It does not know when it doesn't know. Feed it a question outside the knowledge base and it will not say "I don't have that." It will invent a plausible answer in the same confident tone it used for the correct ones. In a demo you never see this, because you never ask the off-script question. In production, someone asks it in the first 48 hours.
The hallucinated policy is the one that churns customers. Not the timeout. A timeout is annoying and the user retries. A confident wrong answer about a refund, a cancellation window, a data-deletion promise — that's the one where the customer acts on it, gets burned, and leaves. And they don't just leave. They tell people the bot lied to them.
Why does a demo hide all of this?
A demo hides production failure because a demo is a controlled sample of one, and production is an uncontrolled sample of thousands. The demo shows you the model on the inputs you chose. Production shows you the model on the inputs your customers choose, and your customers will find the edges you never imagined within a week. The gap between those two is where pilots die.
This is the trap people call pilot purgatory. The thing impresses in the room and then confuses the operators who have to run it. The operator sees the bot answer a question and can't tell if the answer is real or invented, because both look identical on screen. So they stop trusting it. Once the operator stops trusting it, it's dead, no matter how good the demo was.
What do I wish I'd known before I started?
I wish I'd known to budget most of the work for after "it works." The demo is maybe 20 percent of the effort. The other 80 percent is the retry logic, the timeout handling, the null-field guards, and the confidence problem — teaching the system to say "I don't know, let me get a human" instead of inventing an answer. That 80 percent is invisible in the demo and it's the entire reason the thing survives week two.
When I scope an integration now, I plan the schedule backwards. The date it "works" in a demo is not the finish line. It's roughly the one-fifth mark. The remaining four-fifths is the unglamorous work nobody wants to pay for because they already saw it work.
Concretely, here's what I now build before I call anything done:
- A hard rule that the model must ground every factual claim in a retrieved source, and refuse when it can't.
- Retry and timeout handling on every external call, with a defined fallback when the retry also fails.
- Null and malformed-record guards, because at least one field will be empty that never was in testing.
- A confidence threshold that routes off-script questions to a human instead of guessing.
- A log of every answer the bot gave, so an operator can audit what it actually said in week two.
What actually paid off?
What paid off was making the system refuse. The single highest-value change I make to any AI integration is teaching it to say "I don't have that information" and hand off. It feels like a downgrade. It reads as the bot being less capable. It is the opposite. A bot that refuses 15 percent of the time and is never confidently wrong beats a bot that answers 100 percent of the time and lies 5 percent of the time. The second one loses customers. The first one keeps them.
The other thing that paid off was watching real logs in week two instead of running more demos. The demo tells you what you built. The logs tell you what your customers did. Those are different questions, and only one of them predicts whether the integration lives.
If you're staring at a demo that just went well, good. Now assume it's one-fifth done. The integration wiring was never the hard part. The second week is.