A support bot gives outdated answers after a release because it answers from frozen copies of your product — help center, articles, snippets — written before the product changed. The structural fix is not writing docs faster: it's giving the bot access to answers at question time, derived from the real code and re-synced on every deploy.
This article takes the mechanism apart (why it's always right after a release that the bot goes wrong), shows why the usual fixes don't hold, then lays out the repair — along with the two objections that come up every time.
The mechanism: the post-release window
Every support bot answers from the knowledge sources you give it. Those sources share one structural flaw: they are copies of your product, written at a point in time. Your product changes with every deploy — the copy doesn't.
The post-release window: the interval between the moment a version ships and the moment every support knowledge source has been updated. During that window, any answer built on a copy written before the release is structurally suspect.
Here's the paradox: that window is exactly when your customers ask the most questions. A button moved, a behavior changed, an export doesn't look the same — and the bot answers with the previous state of the product. An illustrative example: on Monday morning you ship a change to the CSV export format (a header row appears). Monday afternoon, a customer asks the bot why their import broke. The bot, fed on a help article written last month, confidently describes the old format. The answer isn't just useless: it's wrong while sounding right — which is what makes it expensive.
It's the same mechanism we unpacked in why your AI support agent doesn't know your product: written knowledge starts lying at the precise moment you deploy. The release doesn't break your bot — it reveals that the bot was answering from a snapshot, not from the product.
Why the usual fixes don't hold
"We'll update the docs at every release." That's a race you lose by design: updating docs is planned human work, while deployment is continuous. Every hotfix, every feature flag flipped, every changed default reopens the window. And support docs are rarely the priority on release day.
"We'll add the release notes to the bot's sources." Better than nothing — but release notes are themselves a copy: written by someone, often a version behind, and written at release granularity, not question granularity. "What changed for my case?" asks for more than the bullet point.
"We'll plug the bot into the ticket tracker or the changelog." Those sources describe intent; the deployed code describes reality. The gap between the two is precisely where mystery tickets come from.
An illustrative example: a diligent team keeps a manual changelog. A Friday-evening fix moves the default session timeout from 30 to 60 minutes — three lines of diff, nobody thinks of the changelog. Two weeks of "my session doesn't behave the same anymore" tickets later, the line finally gets added.
"What changed since the last release?"
That's the deciding question. Asked of the bot, it should get a dated, sourced, complete answer — like the whole "what changed?" family of questions: since the last release, for this specific feature, does anything break. A bot built on copies cannot answer it: it doesn't even know a release happened. A source derived from the code can — because the answer lives in the diffs.
Ready to see what your team shipped?
The structural repair: answer at question time
The repair isn't writing copies faster: it's removing the copy. Concretely, give the bot question-time access to an expert on your product — one MCP server per project, plugged into your code — that derives its answers from the real code and the git history (commits + diffs), re-synced on every push. When the customer asks "why did my import break?", the expert reads Monday's change — not last month's article.
In practice, support platforms already allow it: Intercom Fin accepts custom MCP connectors — we published the step-by-step guide to plugging Fin into your code. The same principle holds for HubSpot Breeze, Claude, or any MCP client: one expert, every surface you have.
What this does to the post-release window: it closes itself. The expert's knowledge is rebuilt on every push — Monday afternoon's answer includes Monday morning's deploy, without any human updating a doc.
The DIY objection: "I'll just use the official GitHub MCP server"
It's a real option, and it deserves an honest answer. GitHub's official MCP server lists commits, pull requests, and issues — for a tooled-up developer asking from Claude or Cursor, that's often enough. For the support case, two structural limits:
- Credentials. The official server authenticates with repository credentials. Handing it to your support platform means giving repo access to a third party that talks to your customers. An answers endpoint flips the relationship: the bot receives answers, never repository access.
- Metadata vs. diffs. Listing commits means reading commit messages. If a commit is named "fix", the list tells you neither what changed nor why. Answering "why did this behavior change?" requires reading the diffs — the actual content of the change. That's what a dedicated product expert does: its answers hold up even with badly named commits.
The mirror objection: "but this expert reads my repo itself"
Correct — and here is exactly how. The GitHub connection is read-only. Each project gets its own MCP server: one product's expert sees nothing but that product. Answers are derived from commits and diffs — the expert never returns raw source code to whoever asks. Access is revocable at any time, and the code never leaves your repository: what you share with the bot is the answers, not the code.
That's also what separates this approach from the neighboring tools: Context7 and DeepWiki cover libraries and public repositories; Mintlify generates an MCP server from written docs. The DeployIt expert covers your private product, derived from the code itself, fresh on every deploy.
Mini-FAQ
Does this measure my developers' activity? No. The expert answers questions about the product — what changed, when, why. Never "what did the developers do": it is neither an activity-reporting tool nor a productivity metric.
Do I need to reconfigure the bot at each release? No. The expert's knowledge is rebuilt on every push; the connector itself doesn't change.
What if my docs are already excellent? Keep them — they remain the best surface for guided journeys. The expert complements them on the one thing they structurally can't do: be current within a minute of a deploy.
Which bots can connect? Any MCP client: Intercom Fin (custom MCP connector), HubSpot Breeze, Claude, Cursor…
Close the window for good
The DeployIt MCP server is in early access, as part of a design partner program: if your support bot answers wrong after every release, your use case is exactly the one we're building for — join the design partner program, or connect your repository now: it's free during early access.
Continue reading
How to Connect Intercom Fin to Your Codebase
A step-by-step guide to Fin's custom MCP connector: plug in a product expert derived from your real code — without handing anyone a GitHub token.
Architecture Decision Records from Git: Always Current
ADRs go stale as soon as the code moves on. Derive them from git history so every decision record stays current, traceable and auditable — for humans and AI agents.
What Changed in the Product This Week?
The most useful question you can ask about a product — and why the reliable answer comes from your repo's real diffs, asked through Claude via MCP.