The strongest case for keeping AI ticket answers and a voting board separate belongs to a competitor: Fider's own writing puts it as "Your tickets describe the product you have," while a voting board describes what nobody has built yet. Tickets show how often something comes up; votes show how many people actually want it built. That split sets up the real question here: what can an AI answer safely, and what can it not?
This page is one part of a larger loop. For the whole thing end to end, see running support with a coding agent.
What is Fider's argument, and why start with theirs rather than our own?
Because it is the best-argued version of this point that any competitor has published, and building on it plainly is more useful to a reader than re-deriving the same idea and pretending it arrived first. Fider's case is that a support ticket and a feature vote answer different questions about a product: one describes what already exists and is not working as expected, the other describes demand for something that has not been built at all. A ticket count tells you how often the existing product falls short. A vote count tells you how many people would actually choose the alternative, rather than merely having mentioned it once in passing.
Your tickets describe the product you have. A feature voting board describes the product you haven't built yet.
Fider, Feature voting board vs AI support tickets
That distinction is about which signal a business should trust when deciding what to build. It is not, on its own, a claim about what an AI can safely say to a customer, which is the narrower and more practical question the rest of this page tries to answer.
What can an AI actually answer well?
Anything already written down. If the answer exists in your own documentation, in a past reply to the same question, or in your own changelog, matching a question to that existing text is close to the safest thing an AI does anywhere in this category: the answer was authored, checked and published by a person before the AI ever touched it. Its job there is retrieval and phrasing, not invention.
What can it not answer at all?
Four things, worth naming as a flat list rather than a spectrum: anything requiring a decision nobody has made yet, anything about the future, anything about money, and anything where being wrong costs more than being slow. A refund amount, a ship date, a promise about what next quarter looks like: none of these exist as a fact anywhere for the AI to retrieve, because nobody has decided them yet, and an AI asked for one regardless will produce something that sounds like a fact rather than say so.
| Can answer well | Cannot answer |
|---|---|
| A question with a documented answer already written somewhere | A decision nobody has made yet |
| What a past reply already said, word for word | Anything about the future, including a vague one like "soon" |
| What the changelog already shows has shipped | Anything involving money: refunds, credits, pricing exceptions |
| A fact that exists in a single, named source of truth | Anything where a wrong answer costs more than a slow one |
How does that carry over to answering customers directly?
The same logic that separates a ticket from a vote separates what an AI can answer from what it cannot. A ticket exists because the product already does something a certain way, which is exactly the kind of settled fact an AI can retrieve and restate. A vote exists because nobody has built the thing yet, which is exactly the kind of open question an AI has no source to draw from, however plausible an invented answer might sound. Tickets against votes is about which signal a business should trust. This is about which questions an AI should be trusted to answer directly. Both rest on the same underlying distinction: whether the fact is already settled, or still open.
Letting an agent answer without letting it invent covers the mechanisms that stop an agent guessing once the source runs dry, and an AGENTS.md for your support centre is where the sanctioned source and these boundaries actually get written down, rather than assumed and reinvented on every reply.
One payment, no subscription, unlimited products.
What is the hardest case, and why isn't it a factual error?
The part most articles on this miss entirely. An AI can produce an answer that is technically correct and still be the wrong thing to send: correct on the facts, and tone-deaf to a customer who is angry, or closing off a conversation that customer actually needed to have with a person. Being right is not the same as being the right thing to say to this particular person, right now, and an AI optimising for factual accuracy has no mechanism for noticing the difference between the two. The hardest cases in this category were never the ones where the AI got a fact wrong. They are the ones where it got every fact right and still should not have sent the reply as written.
Frequently asked questions
Is an AI allowed to answer anything not already written down somewhere?
No, not safely. If the fact does not exist in a documented source, the honest answer is to say so and hand it to a person, rather than produce something plausible in its place.
Why can't an AI make a judgement call the way a person can?
Because a judgement call, by definition, is a decision nobody has made yet, and there is nothing for the AI to retrieve. It can restate what is already settled; it cannot settle something new on your behalf.
What is the difference between a hard question and a dangerous one?
A hard question is one an AI genuinely cannot find the answer to, and the honest response is to say so. A dangerous one is a question it can answer correctly and still get wrong to send, because the correct fact was not what the customer actually needed in that moment.
Does citing a competitor's argument weaken this page?
No. Fider's framing of tickets against votes is the clearest existing account of why the two answer different questions, and building on it openly is more useful to a reader than re-deriving the same point from scratch and presenting it as new.
Should a factually correct reply always be sent exactly as written?
Not automatically. A technically accurate answer can still be the wrong thing to send if it ignores the tone of the conversation or closes off something the customer needed a person for, which is why review before sending matters even once the facts have already been checked.