An AI agent should refuse to answer whatever the code and its history cannot prove: what is planned, what is not published, and what the company has promised. Everything else, including what shipped, when, and how it behaves today, it should answer from evidence. The refusal is not a gap in the agent. It is the half of the job that keeps the other half trustworthy.
This article is about the scope of answers, the line between what an agent may state and what it must hand to a person. Giving an agent safe access to the source is a separate question, covered in giving AI agents access to your code safely. The failure when it states something false is covered in why agents invent product features.
Three kinds of question
A product question falls into one of three bins. The test is one question: what would prove the answer?
- Provable now. A commit, a diff or the current code settles it. "Does export support CSV?" "Did the API change this week?" Answer, with the source.
- Provable as of a date. The code settles it, but the answer will expire. "Is single sign-on available?" Answer, with the date of the evidence.
- Not provable by code. A decision, a plan or a promise settles it, and none of those is in the repository. Refuse, and say who can answer.
The third bin is the one agents get wrong. Language models are fluent, and fluency fills a gap faster than silence does.
The sorting test
Eight questions a customer or a prospect could ask. The product and the answers are illustrative; the sorting is the point.
| Question | Bin | What the agent does |
|---|---|---|
| "Does the export endpoint accept a date range?" | Provable now | Answers from the current code, names the source |
| "What changed in the API since last month?" | Provable now | Answers from the history of diffs |
| "Do you support SSO?" | Provable as of a date | Answers, states when the evidence was read |
| "Will you support SSO by next quarter?" | Not provable | Refuses; says the roadmap belongs to the product team |
| "How much is the team plan?" | Depends | Answers only if the price is published; otherwise refuses |
| "Can you guarantee 99.9% uptime?" | Not provable | Refuses; a guarantee is a contract, point to the sales contact |
| "Why did you remove the legacy report?" | Partly | Answers what the commit says changed; refuses the business reason unless a commit message gives it |
| "Is my data safe?" | Not provable as asked | Answers the verifiable parts (what the code does with the data), refuses the blanket assurance |
Notice the shape of two rows. The price question and the "why" question are split: one part answerable, one part not. A good refusal is often partial. It answers what the evidence supports and names the boundary out loud.
Why code makes the line easy to draw
For product facts, the code and its history give an agent a clean test. If a statement can be traced to a commit or to the current code, it can be asserted. If it cannot, it cannot. No judgment about tone is needed.
That is why a source built from documents makes the line harder to hold. A help-center article mixes shipped behavior, planned behavior and marketing language in the same paragraph, and the agent cannot tell which sentence is which. A document written in March that says "coming soon" is read in October as a fact about October.
DeployIt reads the real code (resynced on every push) and the git history (commits and diffs) through its own MCP servers, and checks the code before asserting anything. Read-only, revocable at any time. When the code holds no evidence, the answer is an explicit "cannot confirm", not silence and not a guess.
Writing the refuse column
You do not need a long policy. Write one page, with four parts.
- The categories. Roadmap and timelines. Prices that are not published. Contractual promises (uptime, compliance, data residency). Opinions about competitors.
- The owner of each. A name or a role, not "the team".
- The sentence. What the agent says, with a next step in it: "That is a decision I can't see in the code. The product team owns it; here is how to reach them."
- The exception rule. When a commit message or a published page does state something, the agent may repeat it and cite it.
Start from your last ten escalations. Sort them with the three bins. Most teams find the refuse column holds three or four recurring categories, not forty.
"Won't a cautious agent just annoy people?"
It will if it refuses everything. The measure is not the number of refusals but whether each one is correct and useful. An agent that answers ninety questions from evidence and declines three with a named owner is a better colleague than one that answers all ninety-three and is wrong about two.
There is also a mirror worry: that the refusal list leaks information by what it hides. It does not need to. The sentence says the question belongs to someone else, which reveals nothing about the answer.
The quick check
Ask your agent about a feature you have not decided to build yet. If it says yes, or sounds hopeful, you have found a hole in the scope. Fix that one with a line in the refuse column, then run the sorting test on your last ten escalations.
DeployIt's MCP server is in early access / design partner program, and the program is open. DeployIt is free during early access; paid plans arrive in January 2027.
Frequently asked questions
Is refusing to answer a failure of the agent?
Not when the refusal is the correct result. An agent that says "that is not something the code can confirm, here is who decides" has done its job. The failure is a confident answer to a question nobody has settled.
Who decides what goes in the refuse column?
The people who own the commitment: product for the roadmap, the founders or sales lead for prices, legal for contractual promises. The agent applies the list; it does not write it.
Can an agent refuse politely without losing the customer?
Yes, if the refusal carries a next step: a named channel, a date when the answer will exist, or the part of the question that can be answered. A bare "I can't help with that" is the version that loses people.
Does a refusal list need maintaining?
Less than a knowledge base does. Roadmap and commitments change by decision, not by release, so the list moves when someone decides something, which is rare compared with how often the code changes.
Continue reading
Why does your AI agent say a feature doesn't exist when it shipped last week?
A denial of a feature that exists has one of four causes. Four questions, asked in order, tell you which one you are looking at, and what to change.
How do you write MCP tool descriptions an agent actually uses correctly?
An agent picks an MCP tool from its description and nothing else. Four rewrite passes turn a vague entry into one that gets called for the right questions and skipped for the wrong ones.
How do you publish release notes in several languages without retranslating them every release?
Retranslating release notes each release makes the languages drift apart. The way out: one source of facts, translations that carry only the form, and the same set of facts in every language.