Quick answerAn AI agent should complete a policy-compliant request, but before it does, it should surface any consequence the customer likely does not know about and give them a clear chance to reconsider; the agent should never block or override a request just because it thinks it knows better, since that crosses from disclosure into paternalism.
The difference between refusal and disclosure
This is a different problem from the one covered in when an AI agent should refuse a request that is against policy. That post is about requests the company will not allow. This one is about requests the company will allow, but that work against what the customer actually wants once the full consequence is visible.
A customer asking to cancel a subscription two days before renewal, not realizing a contractual penalty applies, has made a request that is completely within policy. The agent is fully authorized to process it. The open question is whether the agent should process it silently, or say something first.
Why silent compliance is the wrong default
Processing the request without comment is the path of least resistance, and it is defensible on a narrow reading of the agent's job: do what the customer asked. But it produces a predictable failure mode. The customer finds the penalty on their next invoice, does not remember agreeing to it, and escalates as a billing dispute or a trust complaint. The company then spends far more resolving the aftermath than it would have spent on one extra sentence at the time of the request.
The fix is not to give the agent discretion to override the customer's stated intent. It is to require the agent to disclose the material consequence before executing, then let the customer decide with full information. This preserves the customer's authority over their own decision while removing the information gap that made the outcome look, in hindsight, like something the company hid from them.
From the team
We build production AI systems for startups.
LLM pipelines, RAG, and agent workflows that hold up under real traffic — not just in the demo.
Where this crosses into paternalism, and how to avoid it
The risk on the other side is an agent that starts second-guessing every request it thinks is suboptimal for the customer, which is its own kind of failure: it slows down simple transactions and implicitly tells customers the agent does not trust their judgment. The line to hold is narrow and specific. The agent should only pause for disclosure when three conditions are all true: the consequence is material (a real dollar cost, a loss of access, or something similarly concrete), the consequence is not obvious from the request itself, and the company has a record showing the customer was never clearly told about it before this moment.
If any of those three is false, the agent should proceed without commentary. A customer canceling a month-to-month plan with no penalty does not need a warning. A customer who was already shown the penalty during signup and is now invoking a right they were fully informed about also does not need a re-warning, though a brief acknowledgment does no harm.
Building the disclosure into the flow, not as an afterthought
The practical design is a pre-execution check, not a post-hoc apology. Before the agent finalizes an action with a known negative-consequence pattern (early cancellation penalties, loss of an accrued benefit, an irreversible downgrade), it should query a policy consequence table, and if a match exists, surface the specific number or effect in plain language, then ask the customer to confirm.
This is the same posture the agent should take when a customer is confirmed as a repeat complainant with a documented history of disputes: proactive disclosure of anything material, rather than waiting to explain it after the fact when a customer contests the outcome. It also connects directly to how an agent should explain an individual decision back to the customer it affected: the explanation is far more useful, and far less likely to trigger a dispute, when it happens before the action instead of after.
FAQ
Does this mean the agent can refuse to process the request?
No. If the request is within policy and the customer confirms after disclosure, the agent processes it. Refusal is reserved for requests that are actually against policy, which is a separate design problem.
What counts as a material consequence worth disclosing?
A concrete, quantifiable cost or loss the customer would reasonably want to know about before deciding, such as a specific penalty amount, forfeited credit, or loss of a benefit that cannot be easily restored. Minor or already-disclosed effects do not need a fresh warning.
How does this interact with the appeal process if a customer still feels misled?
If disclosure happened and is logged, the appeal is usually short: the record shows the customer was told and confirmed. See the post on building an appeal process for an AI agent's autonomous decisions for how that record should be structured.