Your AI Agent Should Push Back on You

An AI agent that says yes to everything you throw at it is not helpful.

It is expensive.

The obedient agent is the one that reformats your request, adds a step or two, and delivers something that looks like what you asked for. Which is what you asked for. Which turns out to be the wrong thing about a third of the time, because you were half-thinking when you typed the request, and there was no one in the loop to notice.

Every mature AI agent should learn to push back.

#What pushback actually looks like

Not refusal for its own sake. Not asking the same clarifying question three times in a row. Not the passive-aggressive "are you sure?" pattern that some safety-trained models fall into.

Pushback is one specific behavior: when the agent notices a mismatch between what you asked for and what a person in your position would probably actually want, it stops and asks. Once. With a concrete alternative on the table.

"You asked me to email every contact in the CRM about the new pricing. There are 4,200 contacts. About 800 of them are inactive leads from more than eighteen months ago. Do you want me to include those, or filter to the 3,400 active ones?"

That is pushback. It costs you ten seconds. It saves you 800 emails to people who will mark them as spam and hurt your sender reputation.

#The three conditions worth pushing back on

Most requests do not need pushback. If you ask the agent to draft a two-line reply to a client, it should just draft it. The overhead of a clarifying question is worse than the risk of getting it slightly wrong on a small task.

The three conditions worth interrupting the flow for:

• Scale mismatch. The task, as literally interpreted, will touch far more things than the request seems to imply. Ten items expected, ten thousand actually queued.
• Reversibility mismatch. The task, as literally interpreted, includes something the agent cannot undo. Sending email, publishing to production, spending money, contacting a person by name.
• Assumption mismatch. The task implies an assumption the agent has good reason to think is wrong. A previous decision in the daily note contradicts it. A file on disk disagrees. A person mentioned by name is on the block list.

If none of those three fire, execute the task. If any of them fires, stop and ask.

#Why this saves money

Every ambiguous request is a coin flip. Get it right and everyone is happy. Get it wrong and you spend the next ninety minutes undoing the wrong version. Two email retractions. One apology to a client. A refactor because the agent ran with the wrong assumption.

The cost of asking one clarifying question is ten seconds of your attention. The cost of getting it wrong is somewhere between an hour and a small crisis. Even a ten percent chance of the second one dominates the arithmetic.

#The agent-trained response is different from the model-trained response

Frontier models will already push back on a small set of things. Anything obviously unsafe. Anything obviously against their guidelines. That is the model layer.

The agent layer is where you get to define what "obviously wrong for this business" looks like. That definition lives in the system prompt, in the tools' preconditions, and in a small rules file the agent reads at session start.

A good rules file for your business might include:

• "If a task touches more than one hundred customers at once, confirm scope first."
• "If a task involves reaching out to a named person, check the CRM's do-not-contact flag before drafting."
• "If a task modifies pricing, get explicit sign-off from the person whose name is in owners.md."

None of these are the model's job. They are yours. And they are what turns a general model into an agent that fits your operation.

#The agent that never says no

If you have deployed an agent for two weeks and it has never pushed back on anything, something is wrong.

Either the tasks you are giving it are so mechanical that the pushback conditions never trigger, in which case you should probably automate them with a script and stop paying for LLM tokens. Or the agent is trained to always comply, in which case you are getting the coin-flip risk every day and you have not seen it yet.

The healthy signal is one or two clarifying interrupts per day. Not more. Not zero.

#How to build this in

If you already have an agent in production, add three lines to the system prompt:

Before executing any task, check for scale mismatch, reversibility mismatch, and assumption mismatch. If any of the three apply, pause and ask one focused question with a concrete alternative. Otherwise, execute.

Then log the interrupts. If they happen too often, tighten the definitions. If they never happen, loosen them.

You do not want an agent that always says yes. You want one that says yes on the ninety-nine easy things, and stops you on the one that would have hurt.

---

If you want an agent team that pushes back on the right things and executes on the rest, talk to us. We build that in from day one.