We opened early access to Quack in January 2026 and spent the next six months watching what happened when the product hit real support queues at B2B SaaS companies. We did not do this quietly. We asked every team to break things, to send us tickets where Quack gave the wrong answer, and to tell us when the experience felt worse than before. Not everyone took us up on that offer, but the teams that did gave us a clear picture of where trainable AI agents actually fail in production.
This is not a victory lap. We got a lot right, but we also found three categories of failure we had not fully anticipated, and they shaped most of the product work we have done since February. If you are evaluating AI support tools, or running your own pilot, these patterns are worth knowing before you commit.
The failure mode we expected: coverage gaps
Every team that onboarded expected the AI to struggle with edge cases. That is the standard concern: customers ask unusual questions, the documentation does not cover them, and the AI either hallucinates an answer or escalates everything. We expected to spend a lot of time here.
Coverage gaps were real, but they were not the most painful failure mode. In practice, when Quack did not have enough information to answer with high confidence, it escalated to a human with the conversation thread and a note explaining that it was not sure. Support leads found that acceptable. A ticket that goes straight to a human is not a failure. It is what you have been doing all along, just faster to arrive at the right desk.
The teams that struggled most were not the ones with sparse documentation. They were the ones with documentation that was technically present but structured in ways that made it nearly unusable for answering direct customer questions. That was a different problem entirely, and it surprised us.
The failure mode we did not expect: documentation structure
One team had a comprehensive help center with over 400 articles. They had been maintaining it for three years. When we ingested it, Quack's answer quality on their product was noticeably worse than on teams with half as many documents. We spent two weeks figuring out why.
The issue was that most of their articles were organized around feature names rather than customer tasks. A customer asking "how do I export my data?" would get an answer referencing a feature called the Data Export Module, but the article about that module was written as a reference document for a feature, not as a procedure for a task. The gap between how customers phrase questions and how documentation is structured is a real signal problem, even for a well-maintained knowledge base.
We built better heuristics for matching task-oriented queries against reference-oriented documentation, but the underlying advice we give teams now is to treat documentation cleanup as part of Quack setup, not a nice-to-have. This is not a criticism of your help center: it is an honest acknowledgment that most help centers were written to answer the question "what does this feature do?" not "what should I do when X happens?"
The failure mode that cost the most trust: overconfident responses on edge cases
The most damaging failures were not wrong escalations or knowledge gaps. They were the cases where Quack gave an answer with high apparent confidence, and that answer was subtly incorrect. Not wildly wrong. Subtly wrong: a step in the right direction but missing a prerequisite, or an answer that was accurate for an older version of the product and had not been updated in the documentation.
We call this the confidence calibration problem. When a customer receives a confident-sounding answer that turns out to be incomplete, they do not conclude that the AI is imperfect. They conclude that the support team does not know what it is doing. The failure is attributed to the company, not the tool.
The fix here was not to lower confidence thresholds across the board, which would just route more tickets to humans and eliminate the deflection benefit. It was to build tighter correlation between documentation freshness and confidence scoring, so that answers sourced from older or less-linked articles receive a lower confidence weight even if the semantic match is strong. This is still an area we are actively improving.
What worked better than we expected: ticket volume absorption during spikes
Some of our early-access teams went through product launches or major feature releases during the early period. In each case, inbound ticket volume jumped significantly in the first 48 hours after launch. What we observed was that Quack's deflection rate on those spike days was higher than on typical days, not lower. The reason was that launch-related tickets clustered heavily around the new feature, and the new documentation had just been added to Quack's knowledge base as part of launch prep. The AI was answering the most common question of the day from fresh, accurate source material.
This contradicted the intuition that AI support would break down during high-volume events. It turns out that volume spikes are concentrated around predictable topics, and a well-prepared AI is better positioned to handle concentrated volume than a human team that is already stretched across the full queue.
The onboarding factor: setup quality predicts performance
After six months, the clearest predictor of Quack performance was not the size of the help center, the age of the company, or the technical sophistication of the support team. It was how much effort went into the initial knowledge setup. Teams that spent time during onboarding reviewing Quack's first answers and correcting the ones that were off saw substantially better deflection quality at the 90-day mark than teams that set it up and walked away.
We are not saying you need to babysit the AI every day. The improvement curve flattens after the initial calibration period. But treating the first few weeks as a configuration exercise rather than a hands-off deployment made a substantial difference. The teams that invested in early calibration converged to stable, high-quality performance significantly faster.
The honest counterpoint
Not every team found early access smooth. Two teams had product areas that relied heavily on knowledge that lived in internal Slack channels and engineers' heads rather than any formal documentation. For those teams, Quack's coverage of that knowledge was thin by design. We can only learn from what we can read, and if your best support answers exist as tribal knowledge passed between people on calls, we cannot surface them.
We are not saying those teams should not use Quack. We are saying they need to document that knowledge first, and that documentation work is valuable regardless of whether they ever deploy an AI agent. The AI is a forcing function for the documentation problem you already have. That is a real benefit, but it is not zero effort.
What we built was worth building. What we learned in these six months made it sharper. We are applying every one of these findings directly to the product you would use today if you signed up for early access.
