"What changed in the product this week?" The reliable answer doesn't live in anyone's memory or in a hand-maintained changelog: it lives in your git history — the commits and, above all, their diffs. Plug a product expert into your repository via MCP, and this becomes a question your support team, your PM, or your AI agents ask Claude directly — and the answer comes back sourced, dated, and verified in the code.
This page is the answer page for that question: why it is structurally hard even though the answer exists somewhere, what a real answer looks like when you ask Claude, and how the two obvious alternatives hold up — connecting the repo directly, or using the official GitHub MCP server.
Why the question goes unanswered (even though the answer exists)
Everything that changed in your product is written down somewhere, to the character. Every fix, every new default, every modified behavior left an exact trace: a diff, dated, tied to an intention (the commit message, the pull request).
A diff is the exact, line-by-line description of what changed in the code between two versions. Everything else — changelogs, release notes, team memory — is a rewrite, and rewrites can be incomplete, late, or wrong.
So the problem isn't missing information: it's that the information is unreadable for almost everyone. Reading diffs requires repository access, technical context, and time. The result: support interrupts a developer, the PM re-reads a changelog from the previous release, customer success answers from memory — and AI agents answer from a frozen copy of your documentation. It's the mechanism we describe in why your AI support agent doesn't know your product: frozen knowledge starts lying at the exact moment you deploy.
The same question, declined: an entire family
"What changed this week?" is only the most common form of a family of questions that varies along four axes:
- The window: this week, since the last release, since v2.3, between two dates, since a customer's last visit.
- The object: the whole product, one feature, the API (any breaking changes?), a specific behavior, a default value.
- The mode: what changed? when exactly? why — what was the intention? does anything break? new vs. fixed vs. deprecated?
- Who's asking: support ("did this ticket come from a release?"), the PM, customer success ("what's new for my account?"), the integrator ("did the API change this week?") — and, increasingly, the agents themselves, which need to know what moved before they answer on your behalf.
An illustrative example: a ticket lands on Monday morning — "the CSV export no longer includes the tax-inclusive amounts column." The right first question isn't "who's free to look at this?" — it's "what changed in the export since Friday?". If that question gets an answer in thirty seconds, the ticket is qualified — release or regression, you know which direction to dig — without interrupting anyone.
What the answer looks like, asked through Claude
With DeployIt's per-project MCP server connected, the scene is mundane (illustrative example — the details depend on your repository):
You: What changed in the product this week?
Claude, through the product expert: Three customer-visible changes this week: (1) webhook validation now rejects expired signatures — Wednesday's diff on webhook verification; the commit's intent was to close a replay case; (2) the CSV export format changed — the amounts column was renamed and moved, Thursday's diff; (3) a new default caps attachment size. None of these touch the public API.
And the family follows naturally: "since v2.3, what touched billing?", "why did the export behavior change?", "does anything break for my integrations?" — every answer cites the relevant diff and the commit's intent, not a recollection. Note the grammatical subject: the question is always about the product. The expert answers "what changed" — never "what did the developers do." This is not a reporting tool and not an activity metric.
Ready to see what your team shipped?
"Can't I just connect my repo to Claude?"
It's the natural objection, and it deserves a precise answer rather than a slogan.
Claude's native GitHub connector syncs the repository's files — and only that. The official documentation is explicit (re-verified on August 17, 2026): "Only files (names and contents) in a repo on a specific branch are synced. We do not retrieve commit history, PRs, or other metadata." Claude sees the current state of the code, not the change: asked "what changed this week?", it can only answer by inference or from memory. We wrote a full guide to the native GitHub connector — and what it can't see.
The official GitHub MCP server does expose commits and pull requests, and a well-equipped developer gets real value from it. Two structural limits remain. First, it reads metadata: commit titles, PR lists. If your commit messages are approximate — they are, on every team — the answers are too; and "why did this behavior change?" requires reading the diff itself, not its title. Second, it requires repository credentials per requester: your support team, your agency's clients, Intercom Fin, or HubSpot Breeze don't have any — and handing them a GitHub token is precisely what you're trying to avoid.
That's the gap a dedicated product expert fills: answers derived from the real diffs — they hold up even with badly named commits, and they can answer "why" — served to requesters without repo credentials.
"But DeployIt reads my repo itself"
Yes — 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 your support team, your clients, or your agents is the answers, not the code. And the knowledge is re-synced on every push — Monday's answer includes Monday's deploy.
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 what my developers do? No. The expert answers questions about the product — what changed, when, why, what breaks. It is neither an activity-reporting tool nor an individual productivity metric.
Is the answer current after a deploy? Yes: the knowledge is rebuilt on every push. That's the structural difference with a written knowledge base, which starts drifting at the very next release.
Which agents can ask these questions? Any MCP client: Claude (the app or the API), Cursor, and agent platforms that accept a custom connector, such as Intercom Fin or HubSpot Breeze.
What exactly does the expert see? The connected repository, read-only: the code, the commits, and their diffs. It uses them to formulate answers — it changes nothing and redistributes no source.
Ask your product the question
The DeployIt MCP server is in early access, as part of a design partner program. If you want "what changed this week?" to finally have an answer on your team — for humans and agents alike — join the design partner program or connect your repository now: it's free during early access.
Continue reading
Architecture Decision Records from Git: Always Current
Learn how architecture decision records git workflows keep ADRs always current, traceable, and auditable across teams using branches, PRs, and tags.
Why Doesn't Your AI Support Agent Know Your Product?
AI support agents answer from a frozen copy of your product, not from what you just shipped. Why that is structural — and how to ground them in your real code.
What Is an MCP Server? A Plain-Language Explanation
An MCP server is a standard socket between your data sources and AI agents. A plain definition, how it works, use cases — and the private-product gap.