When an AI Agent Answers Before the Work Is Done
An agent that drafts a priced reply before anyone has seen the job adds review work. Here is the hold that prevents it, and how to decide where holds belong.
Last Updated: October 28, 2026
A three-question test that decides which incoming requests an agent should hold for a person. A worked enquiry showing where the approval points sit, and the four ways holds get built wrong.
What is an approval gate in an AI agent? A rule that stops the agent before a named class of action and hands that action to a person. For actions in that class, nothing reaches a customer, a ledger or an outside system until someone releases it. Everything outside the class runs on its own.
An agent reads an inbound enquiry for work that needs a visit first, matches labour and material rates, and produces a priced reply for the owner to approve. Nobody has seen the job. The figure in that draft was invented, because the design that decides it does not exist yet. The agent should not have written the reply at all.
Quick Answer
When the answer depends on a measurement or decision only a person can make, the correct behaviour is a hold, also called an approval gate. The agent logs the request, proposes an assessment slot for approval, and assembles everything that does not turn on the unknown figure. It produces nothing a customer could mistake for an answer.
Building the hold is the easy half. The design work is deciding which requests get one.
A confident draft costs more than a hold
Three costs sit behind that invented figure. The first is review time. Every pre-emptive draft becomes an item in the owner's queue that cannot be approved, so the agent has added a document someone must read, catch and discard.
The second is calibration. Once a person learns that the queue holds items that are plausible and unusable, they start skimming all of it the same way. The gate is still there and the attention behind it is gone.
The third is liability, and it arrives through the second. A skimmed queue is how an invented figure reaches a customer. A British Columbia tribunal held Air Canada responsible for wrong information its website chatbot gave a passenger about bereavement fares (Global News; Moffatt v. Air Canada, 2024 BCCRT 149). That tribunal handles claims up to $5,000 (Tribunal Small Claims Regulation, s. 3), so the dollar amount was small. Read it as a signal about how a tribunal treats a business's software.
Gartner predicts that over 40% of agentic AI projects will be cancelled by the end of 2027 (Gartner, June 2025). The release names three causes, escalating costs, unclear business value and inadequate risk controls, but gives no data behind them; we have written separately about what goes wrong inside a failed AI project. Gartner's framing elsewhere is that agent success rests on reliability more than autonomy (Gartner).
Three questions that decide where a hold belongs
Before it drafts anything, the agent runs each request against three questions. Any single yes sends the request to a hold.
| Question | What it catches | Example |
|---|---|---|
| Does the answer depend on a fact nobody has established yet? | Work that must happen before a true number exists | A measurement, an inspection, a permit decision, a credit check |
| Does the rule vary by customer or contract? | Terms that live in one person's head | Negotiated rates, per-contract percentages, a routing rule one employee knows |
| Is the action irreversible once taken? | Anything you cannot quietly correct | A sent price, a posted entry, a credit, a cancellation, a committed date |
The harder an action is to undo, the less freedom the agent should have, whichever AI model sits behind it.
Tie each hold to a field in your own system. The priced draft reads the determination from wherever the person recorded it, so an empty field leaves the drafting step with nothing to work from. A hold built into the data holds under pressure. An instruction asking the agent to wait is only as good as the agent's reading of it that day.
Ambiguous requests default to the hold. The agent earns the drafting path by matching a request type you wrote down, and anything it cannot match waits for a person. That rule carries more weight than it sounds, because classification is the one step in this design that is still a model judgment.
The approach fits request types with a recurring shape, and fails in three cases. One-off requests that never repeat are not worth a rule. Work whose determination is never written down, even after the person makes it, leaves the agent chasing a value it can never read. A business with fixed published pricing needs no hold on price at all.
The workflow, step by step
A single inbound enquiry, in a business whose jobs begin with an assessment.
In: an email arrives asking for a price.
Step 1. The agent classifies the request against the hold list. Price requested, no assessment on file, so question one is a yes.
Step 2. No reply is drafted. The agent creates the job record and files the address, the contact, the stated scope and any photographs where your team already looks.
Step 3. The agent prepares the parts that do not depend on the unknown. An acknowledgement that commits to nothing but the next step. A proposed assessment window from the live calendar. The access questions that would otherwise cost a second phone call, and the checklist the technician will carry.
Step 4. A person approves the acknowledgement and the booking. That is the only item in the queue at this stage, and it is approvable, because nothing in it asserts a figure.
Step 5. The assessment happens and the person records the result. One field is enough: the determination, the date, and who established it.
Step 6. The agent drafts the priced reply from that recorded result, with the figure traceable to the line items behind it.
Step 7. A person approves the price and the agent sends it.
Out: a quote that is right the first time.
The agent acted five times in that sequence and a person decided twice. The judgment stayed with the people who hold it. That is the difference between an agent doing the work and a tool producing drafts next to it.
Does the hold actually reduce the work
The figures below show how the arithmetic works. They describe a model. No measured deployment sits behind them.
A business receives 60 inbound enquiries a month and 25 need an on-site determination before a price can exist. With no hold, the owner reads 60 priced drafts closely enough to recognise which 25 to discard. With the hold, 25 acknowledgements are approved at a glance, because none of them can be wrong about a figure, and 35 priced drafts get the close read. The queue is the same length and about 40% of it stopped needing careful attention. The category that could embarrass the business can no longer leave unseen.
Where this goes wrong
Holding everything. When every action needs approval, approval becomes a reflex. Gartner's position is that applying uniform governance across all AI agents can lead to enterprise agent failure (Gartner, May 2026). In our own view, a control earns its place where the cost of being wrong is asymmetric.
The opposite failure has a name in security. Researchers call it excessive agency: an agent allowed to take a damaging action on model output nobody checked. The OWASP Top 10 for LLM Applications lists excessive autonomy as one of its three root causes, with excessive functionality and excessive permissions (OWASP LLM06:2025). This is a different problem from a model stating something untrue, and it does more damage.
A queue nobody owns is the third. Requests arrive, the agent holds them correctly, and they sit. The hold was never meant to be silence toward the customer, which is what the Step 3 acknowledgement is for. Every hold needs a named owner and a time at which it escalates.
Invisible holds are the fourth. If the agent holds a request and says nothing internally, the business finds out when the customer calls. A hold is an event: logged, visible somewhere a person looks daily, and ageing in plain sight. We cover the surrounding control gaps in agent governance gaps for smaller businesses.
See where your own holds would sit
Our assessment starts from your actual request types and runs them against the three questions above. That list is the part that takes judgment, and it decides whether an agent is useful or merely busy. Start with the AI readiness assessment.
What to do next
Write one table with two columns. In the first, your recurring request types in your own words. In the second, the fact that must exist before a true answer can be given, and who establishes it. Then run all three questions against each row, because a varying rule or an irreversible action can need a hold even where column two is empty.
Bring that table to any vendor conversation. A vendor who cannot tell you where their system refuses to act is describing a drafting tool, and you should price it like one.