A support inbox stored as a git repository turns a reply into a diff: read before it is sent, approved or rejected by the same process a code change goes through. Search, blame and revert already exist for it. What is lost is a live interface a non-technical colleague can just open.
This page is one part of a larger guide. For the whole subject in one place, see running support with a coding agent.
What actually changes when feedback becomes files?
A row in somebody else's database is a fact you can update. A file in a repository is a fact with a history and a mechanism for proposing a change to it before the change happens. Nothing about that sounds dramatic until an agent is the one drafting the reply, at which point it becomes the whole question: does the reply reach the customer the moment it is written, or does it pass through something first?
Git already answers that, because the answer is what git is for. A change to a tracked file is a diff. A diff can sit unmerged, read, edited, or thrown away, and none of that requires building a review feature, because review is the default state of a change in a repository, not an accessory to it.
Why does review become the workflow rather than a feature?
Because a diff is inert until it is merged, and merging is a deliberate act. An AI system that posts directly to a support platform has one path from draft to published: generate, then send. A reply drafted as a file change has two states with a gap between them, and the gap is where a human looks at it.
That is a genuinely different safety model, not a stricter version of the same one: the difference between a system that can be wrong in front of a customer and one that can only be wrong in front of a colleague first. Letting an agent answer without letting it invent covers the other half of that problem, what the agent should and should not be trusted to draft in the first place. This page is only about what happens to a draft once it exists.
What does free history actually buy you?
Every edit to every reply is recorded with who made it and when, because that is what a commit already is. Nobody wrote an audit log feature for it, and nobody decided to retain it for ninety days, because a repository does not expire history by policy, it just keeps it.
| Gets better | Gets worse |
|---|---|
| Every edit to every reply is recorded, free, forever | No live view; two people can edit the same thing and conflict |
| A reply is a diff, reviewable before it sends | A repository is not a queue; priority and assignment need convention, not a feature |
| Drafting and comparing many replies costs nothing, and deleting them costs nothing | Non-technical colleagues cannot participate without an interface |
| Search, blame, diff and revert are already built and already familiar to a technical team | Deletion is not deletion; a removed line is still in history |
That last row matters enough that it has its own page: git history is permanent covers what "removed" means once something has been committed.
What does branching let you do that a normal inbox cannot?
Draft twenty replies to the same bug report, compare them side by side, and throw nineteen away. In most support tools a draft is a slot: one box, one version, overwritten every time you change your mind. In a repository, a draft is a branch or an unmerged file, and having several of them costs nothing until one is chosen. That is a small thing for a single reply and a real thing for a batch: an agent generating candidate replies to review together is doing something closer to how a team reviews a set of code changes than how a team answers an inbox, with the same tooling underneath either way.
What is actually worse, and who does this not suit?
Four things, honestly, and none of them are edge cases.
A support person who is not technical cannot open a pull request. "Just use git" is not an onboarding plan, it is a wall. If the team answering customers includes anyone who thinks of a terminal as somebody else's tool, this shape needs an interface layered on top before it is usable at all.
Deletion is not deletion. Removing a line from a file leaves it in every earlier commit, clone and fork. That is the subject of git history is permanent, a standing fact about the medium rather than a bug to route around.
There is no live view. A support platform holds one copy of the truth and locks or merges edits for you. A repository does not; two edits to the same file are a merge conflict, resolved by a person, after the fact.
A repository is not a queue. "What needs answering today, in order" is a feature every support tool ships by default, and a directory of files has no opinion about order at all. Priority, assignment and "who is working on this" have to be invented as a convention the team follows, not a button anyone can click.
One payment, no subscription, unlimited products.
Does this suit a support desk of ten people?
Not as it stands, and the honest answer is to say so rather than oversell it. A repository-backed inbox suits a small technical team that already lives in diffs and pull requests, where review is not new friction but the same friction applied to a code change every day. A support desk of ten non-technical people, working a queue and needing a live view of what is open, is being asked to adopt a workflow built for a different kind of team, and no amount of tooling changes that.
Where the fit is genuinely good is exactly where the review property matters most: a small team letting an agent draft replies, where the value of the diff is that nothing reaches a customer without a human choosing to merge it. That is a narrow fit. It is also a real one, and it is the fit this approach is built for rather than a compromise it settles for.
What replaces the missing queue and dashboard?
Convention, deliberately, rather than a feature nobody built. A file naming pattern that sorts by date or status, a status field the file itself carries, a habit of checking a directory before starting work: none of this is automatic, and all of it depends on the team keeping to it. That cost is worth naming, because a convention nobody enforces decays exactly as fast as any other unenforced rule.
Frequently asked questions
Is a support reply drafted by an agent published automatically?
Not in this shape. A drafted reply is a change to a file, sitting unmerged until a person reads it and decides to publish it, the same way a code change sits in a pull request until it is approved.
What happens when a reply is edited after it goes out?
The edit is a new commit. The version before it is not overwritten, it stays in history alongside the new one, recorded with who made the change and when, without any audit feature having been built for it.
Can two people work on the same reply at once?
Not smoothly. There is no live view the way a support platform provides one, so two people editing the same file at the same time produce a merge conflict that a person has to resolve, rather than a system that locks the file automatically.
Does deleting a reply remove it from the repository?
No. Removing content from the current version leaves it in every earlier commit and every existing clone or fork. Git history is permanent covers what that actually means in practice.
Is this a good fit for a large support team?
Generally not for a team of non-technical people working a queue day to day. It suits a small technical team drafting and reviewing replies the way they already review code, not a support desk that needs a live dashboard, assignment, and a queue built in.