Running support with a coding agent means the agent doing the editing itself: triaging a request, drafting a reply, merging a duplicate, updating a roadmap file, writing a changelog line, each as a change to a file a person can read before it goes anywhere. A vendor's built-in AI reads what arrives. This is an agent that does the work.
What does the whole loop actually look like?
Feedback runs through the same loop whether a person or an agent is doing the work: it arrives, gets triaged, gets checked against everything already open in case it is a duplicate, gets answered if the answer already exists, gets grouped into something worth building if it does not, ships, and becomes a line in a changelog. An agent can touch every stage of that loop. It should not own all of them.
| Stage | What an agent does well | What it should never do alone |
|---|---|---|
| Triage | Read, tag and sort a new request by type and severity | Decide which category matters most to the business right now |
| Deduplication | Flag two requests that plausibly mean the same thing | Merge them without a person checking the reasoning |
| Answering | Draft a reply from a single written source of truth | Publish the reply, or answer anything the source does not cover |
| Roadmap | Group related requests into a candidate roadmap item | Decide what actually ships, and when |
| Shipping | Turn a range of commits into a changelog draft | Judge which change is the one customers were actually waiting for |
How does deduplication fit in, and why is it the hardest part?
It looks like the safest job to hand an agent, matching text is exactly what a language model is built to notice, and it is the one that goes wrong with the most confidence. Two people can use the same words for different problems, or different words for the same one, and only a person catching the second case ever finds out it happened. Nothing about the agent's tone changes between a correct merge and a wrong one, which is exactly why the decision to merge cannot be the agent's alone. Deduplicating requests: what an agent gets confidently wrong covers the failure modes in full, and the method that catches them before a merge does damage.
Who decides what the agent is actually allowed to say?
Not the agent. An AGENTS.md for your support centre is where the tone, the boundaries and the list of things that always wait for a person get written down once, so an agent is not guessing at them fresh on every reply. Letting an agent answer without letting it invent is what stops a fluent wrong answer looking identical to a right one, which is the actual risk once an agent is drafting replies at any volume. What an AI can and cannot answer for your customers draws the line between what is genuinely safe to automate and what still needs a human conversation.
What happens once a reply is actually drafted?
It sits as a change nobody has approved yet, the same as any other change to a tracked file. The support inbox as a git repository is the shape that makes review the default state of a change rather than a feature someone has to build for it: a draft reply is a diff, read before it is merged, exactly like a code change waits for one.
How does a request turn into something that ships, and get told to customers?
Grouping related requests into a candidate roadmap item is reading and sorting, and an agent is fast at both. Deciding which item is actually worth building is a business call nobody has delegated to it. Once something ships, the same pattern repeats on the way out the door: writing changelogs from commits without a subscription covers what an agent is good at here, grouping, deduplicating and rewriting a commit log into sentences a customer would recognise, and what it still gets wrong, judging which change is the one people were actually waiting for.
Why doesn't this need an MCP server, and what's actually different about it?
Every hosted vendor in this category has added AI to the product it already sells, mostly to summarise and triage what arrives: reading support conversations, drafting a changelog line from a completed item, spotting a likely duplicate as someone types. Seven of them have gone a step further and shipped an MCP server, a defined bridge that lets an outside assistant reach into their database and read, and sometimes write, a record: UserJot, Featurebase, Canny.io, Quackback, Sleekplan, Upvoty and Nolt.io. An eighth, Frill.co, markets one on two separate pages without matching developer documentation for it. An MCP server, or the files already in your repo covers what that bridge actually does, and why it is not needed here.
Connect in one line. Or one config file. No SDK to install. No OAuth flow. No self-hosting.
Frill.co, on its own MCP product page
That is real engineering, and it solves a real problem: the vendor's AI can now reach data trapped inside the vendor's own database. It is a different problem from the one an agent solves when the feedback is already files in a repository it has open. There is no database to bridge to, because there is no boundary between the agent and the data to begin with. It can read the request, draft the reply, merge the duplicate, open the pull request and write the changelog line, all in the same place. Their AI reads your feedback. Your agent does the work.
What is this shape actually bad at?
Three things, honestly, and the rest of this guide does not hide them.
A colleague who is not technical cannot open a pull request, and "just use git" is not an onboarding plan. Anyone answering customers who thinks of a terminal as somebody else's tool needs an interface built on top of this before it is usable at all.
Permissions on a folder are weaker than permissions on a server. A well-built MCP server can expose exactly one action, drafting a changelog entry, say, without handing over write access to everything else. A repository checkout an agent has open is usually broader than that by default, so the fences have to be drawn as a convention the agent is expected to follow, not a wall it structurally cannot get past.
And none of it removes the need for a person to actually read what goes out. A file that is easy to review is not the same as a file that gets reviewed. This workflow makes review the default state of a change. It does not make anyone look. That gap is where the discipline in the rest of this guide actually earns its keep: an AGENTS.md file, a rule against merging without review, a source of truth an agent may not step outside of. None of it replaces a person deciding to look. All of it makes the moment they look worth more.
One payment, no subscription, unlimited products.
Where to go next
This page is the overview. Each stage of the loop has a page of its own.
- How the inbox itself works. The support inbox as a git repository is the shape a reply takes once review is the default rather than a feature bolted on afterwards.
- Telling it what it may do. An AGENTS.md for your support centre sets the tone and the boundaries, and letting an agent answer without letting it invent is the discipline that stops a confident answer from being a wrong one.
- Getting duplicates right, and knowing what to say. Deduplicating requests: what an agent gets confidently wrong covers where "the same request" breaks down, and what an AI can and cannot answer for your customers draws the line this page only gestures at.
- Shipping it and telling people. Writing changelogs from commits without a subscription covers the translation from a raw commit log into something a customer would recognise.
- Why there is less plumbing than it looks. An MCP server, or the files already in your repo covers what a vendor's bridge does, and why a repository does not need one.
- What it actually costs. What it costs to run support through an AI provider works through the token arithmetic.
- How much of the work to hand over. Giving a coding agent write access to your request board is the permission decision, and triaging a feature request backlog with a coding agent is the method for the pile that has already built up.
- Keeping it going. The one-person support department proposes a shape for the week, and what to track in the first year of a support centre covers what to capture from day one so the numbers exist when you want them.
Frequently asked questions
Does a coding agent publish a reply on its own?
No, 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 waits in a pull request until it is approved.
What is actually different between this and a hosted tool's built-in AI?
Their AI reads your feedback: it summarises, triages and sometimes drafts inside a product you do not control the internals of. An agent with your repository open does the work itself: reading the request, drafting the reply, merging the duplicate, opening the pull request, writing the changelog line, all as changes to files it can already see.
Do I need an MCP server to run support this way?
No, not if the feedback already lives as files in a repository the agent has open. An MCP server bridges an agent to data trapped inside somebody else's database. There is nothing to bridge once the data was never trapped in the first place.
What should never be left to the agent alone?
Publishing a reply, merging a duplicate, deciding what ships, and anything involving a date, a refund, or another customer's account. All of these are judgement calls or business decisions, not facts an agent can retrieve and restate.
Does this suit a support team of any size?
Not as it stands. It fits a small technical team that already lives in diffs and pull requests. A larger team with non-technical colleagues answering customers day to day needs an interface built on top of this before anyone but a developer can actually use it.