A kitchen remodeling company learned what their AI had been doing from a one-star review.
The review was three sentences long. The customer wrote: the AI assistant promised installation "Friday, before 5 PM." Friday came and went — no crew, no call, nothing. When she called Saturday, the scheduler said the next available installation window was eleven days out. The AI had never checked the calendar. The promise came from the same part of the model that says "Great question!" — fluent, confident, and completely disconnected from the scheduling system sitting four feet away in the tech stack.
When the owner pulled the transcript logs, the damage was bigger than one review. In the previous 90 days the AI had made 312 specific delivery or arrival commitments ("the tech will be there between 2 and 4," "your part ships Monday," "the installer will call you an hour before"). Only 168 of them existed anywhere in the dispatch system. The other 144 promises — 46% — were fiction. Every one of them was polite, specific, and load-bearing: customers plan their day off around "2 to 4." Nobody plans their day off around "we'll see what we can do."
That's the failure mode nobody warns you about. AI agents don't hallucinate facts — not usually. They hallucinate commitments. Refunds, delivery windows, call-backs, ship dates. A human agent who says "Friday before 5" usually knows whether that's true, because a human who promises Friday has either looked at the calendar or is about to suffer consequences in a way they remember. The AI has neither. It has a language model that has read ten million customer-service transcripts, and in most of them, the agent says something specific when the customer asks when. So the AI says something specific.
I've audited enough deployments now that I check this before I check anything else: give the agent a question whose answer lives in another system, and see what it says. "When will my order arrive?" Ninety percent of unconstrained agents will produce a date. Some of them are right. All of them sound identical.
Here's how to fix it in an afternoon.
Step 1: Classify every time-commitment into three buckets
The root problem is that the agent can emit a date the same way it emits a greeting — freely. Split all outbound time-talk into three categories and force the agent to label each one:
- QUOTE — reading a real value from a real system. "Your order status shows shipped, tracking says delivery Thursday." Only allowed when a tool call actually returned the data in this turn. The date came from somewhere.
- RANGE — a bounded estimate drawn from policy, not from live data. "Typical installation takes 2–3 business days after approval." Allowed without a tool call, but only if the numbers come from the policy document, and only in this hedged form: typical, usually, generally — never "will."
- PROMISE — a specific commitment to a specific future event for this specific customer. "Friday before 5 PM." This is the dangerous bucket. It is only allowed if the agent has written the event into the system of record in the same turn — created the appointment, booked the slot, opened the task with a due date. No booking, no promise.
That last rule is the entire article. No booking, no promise. If the agent cannot or did not write to the calendar, its strongest permitted sentence is: "I can't confirm a specific time from here, but here's what I can do — I've flagged your request for scheduling, and here's the scheduling team's availability window." Customers accept that. What they don't accept — what turns into one-star reviews — is a specific promise followed by a silent void.
The corollary rule most teams miss: the AI must not promise on behalf of humans either. "A manager will call you back today" is a PROMISE about a human's behavior. If the agent creates a callback task with a due date, fine — that's a booking. If it just says the sentence, the manager never agreed to anything. Same classification applies.
Step 2: The commitment-gate prompt layer (drop this into your agent)
{
"time_commitment_rules": {
"classes": ["QUOTE", "RANGE", "PROMISE"],
"QUOTE": {
"requires": "tool_call_returned_data_this_turn",
"citation": "system_name",
"format": "report_value_verbatim_with_source"
},
"RANGE": {
"requires": "value_from_policy_doc",
"forbidden_words": ["will", "guaranteed", "definitely", "exactly"],
"required_hedges": ["typically", "usually", "generally"]
},
"PROMISE": {
"requires": "system_write_in_same_turn",
"write_targets": ["calendar_event", "task_with_due_date", "appointment_slot"],
"requires_confirmation": "echo_back_written_record_id",
"fallback_when_no_write": "offer_request_submission_instead"
},
"forbidden": [
"inventing_date_without_source",
"promising_human_behavior_without_task",
"repeating_previous_promise_as_fact"
],
"on_customer_asks_when": {
"priority": "QUOTE > RANGE > PROMISE",
"never_skip_down": "if_no_quote_available_answer_with_RANGE"
}
}
}
Three lines in that schema earn their keep:
-
echo_back_written_record_id. When the agent books, it must say "I've got you down for Friday 10 AM — confirmation #A-4412." That sentence is verifiable. If the confirmation number doesn't resolve in the calendar, you've caught a hallucinated booking — the rarer but worse cousin of the hallucinated promise, and it happens more than teams expect when the write endpoint returns an error the agent glosses over. -
repeating_previous_promise_as_factin forbidden. The most toxic variant I see: a customer says "but the AI told me Friday," and the agent — having no memory policy — says "Yes, Friday is correct." Now the fiction has been reaffirmed by a second agent. Your transcript log now contains two confirmations of an event that doesn't exist. The agent must answer with what's in the system, not with what the transcript says it said. -
priority: QUOTE > RANGE > PROMISE— when a customer asks "when," the agent tries the live system first, falls back to the policy range, and only writes a commitment if both fail and it can book. Most agents do the reverse: promise first because it's the most satisfying-sounding answer.
Step 3: Reconcile promises against the system, weekly — not per-review
You can't eyeball this. The kitchen company had 144 fictional promises scattered across 3,900 transcripts; the only reason they found any of them was an angry review. The reconciliation has to be mechanical:
- Extract commitments from transcripts. Every week, run the transcript log through a classifier with one job: find every sentence containing a specific future time for a specific customer ("Friday", "2 to 4", "by end of day", "Monday ship"). Flag PROMISE-class messages.
- Match each promise against the system of record. Does a corresponding calendar event, task, or booking exist with a matching date? Output three buckets: matched / mismatched / orphan.
- The orphan bucket is your incident list. Every orphan is a customer who was told something specific and will experience nothing. Notify the customer before they notice — "about your Friday installation, I need to correct our scheduling" — while there's still time to save the appointment.
Teams that run this weekly find orphans while the customer is still a customer. Teams that run it never find anything until a review does.
Step 4: The weekly audit (Monday, 20 minutes, five checks)
| # | Check | Method | Healthy threshold |
|---|---|---|---|
| 1 | Promise rate | PROMISE-class messages ÷ conversations | Known and stable week over week |
| 2 | Orphan promises | Promises with no system record ÷ all promises | < 2%, target 0 |
| 3 | Reaffirmed fiction | Agent re-confirms a prior promise not in system | 0 |
| 4 | Quote accuracy | Sampled QUOTE values vs. system values | ≥ 98% |
| 5 | Save rate on orphans | Orphans proactively corrected before customer complaint | ≥ 80% |
Check 2 is the headline number. If you can tell an owner "your agent made 312 promises last month, 144 of them don't exist, and here's the list," you have converted a vague AI-anxiety conversation into a mechanical fix with a work queue.
Step 5: The numbers, so you can pitch this internally
From deployments that added a commitment gate:
- Unconstrained agents: 30–50% of specific time-commitments have no corresponding system record. After the gate (PROMISE requires a same-turn write): 0–2%. The fictional-promise class doesn't shrink; it disappears, because the agent is physically incapable of producing an unbacked booking.
- Booking-then-promising increases actual kept appointments by 15–25% versus promise-then-hoping, because the promise now creates a real dispatch record that a human scheduler sees and honors.
- The "no booking, no promise" fallback line converts fine. In deployments I've measured, 60–70% of customers accept "I can't confirm a specific time, but I've submitted your request" without complaint. The remaining 30% wanted to escalate anyway — which the old behavior was only postponing, with interest.
- Reaffirmed-fiction rate drops to zero the week you add the forbidden rule, because it's a prompt-level fix, not an integration project. It's the cheapest check on the list and the one with the most explosive downside when left unfixed.
The kitchen company's fix took one afternoon: the gate schema, a weekly reconciliation script, and one new sentence the agent is allowed to say when it can't book. The one-star review is still up. The agent's 312 promises a month are now 312 records.
Want the full playbook — commitment-gate schemas, reconciliation scripts, audit checklists, and the reply templates that keep scheduling disasters out of your review feed? Get it here: https://whop.com/agentfast-04b6/
Top comments (1)
The trust question is the one nobody wants to answer. Capability is easy to demo, reliability is not.