“That did not work” is a dangerous answer after a timeout.
The request may have failed. It may also have completed after the client stopped waiting. If the agent tells the caller it failed, the caller may try again and create a duplicate. If the agent claims success, the caller may rely on an appointment that does not exist.
The correct response is constrained by what the system can establish.
Separate the attempt from the effect
A consequential tool call creates at least two facts.
The first is about the workflow: it submitted a request. The second is about the outside world: an appointment was created, a record was updated, or a message was sent.
The first fact does not prove the second. A tool response may provide that proof, but only if the response identifies the external effect and the workflow checks it. A generated sentence cannot supply missing evidence.
I treat the final response as a claim over workflow state. The agent may say only what that state supports.
Match language to established state
For consequential actions, I use four response classes.
Confirmed
The workflow has evidence of the intended effect.
“Your appointment is booked for Tuesday at 3 p.m. The confirmation number is 48217.”
The confirmation should name the effect and include the provider evidence that will help the caller or an operator inspect it later.
Contradicted
The workflow has evidence that the intended effect did not occur.
“The provider rejected that time because it is no longer available. I can look for another time.”
The response should state the observed reason when it is safe and useful. “The tool failed” hides the business condition the caller needs.
Unresolved
The request was attempted, but the workflow cannot establish the effect.
“I sent the booking request, but I cannot confirm whether the appointment was created. I will not submit it again while that is unresolved.”
The response should tell the caller what is known, what remains unknown, and what will happen next. It should not turn uncertainty into reassurance.
Transferred
Responsibility has moved to a person or another system that can inspect or repair the result.
“I cannot confirm the booking. I am transferring the request and the attempted time to a dispatcher now.”
A transfer claim is valid only after the receiving owner and relevant state are established. Announcing a transfer before responsibility moves creates a second unverified promise.
Generate from state, not from conversational momentum
Language models are good at finishing the conversational pattern in front of them. A caller asks for a booking. The agent gathers the fields. The booking tool runs. The natural completion is “You’re all set.”
That conversational momentum is exactly why the response needs a narrower input.
The final response generator should receive the established action state, permitted claim class, provider evidence, and next owner. It should not infer completion from the fact that a booking conversation reached its closing turn.
This is a small architectural boundary with a large effect. The model can still choose clear language. The workflow decides which class of claim is allowed.
Keep uncertainty specific
Vague caution is not safer than a precise answer.
“Something may have gone wrong” leaves the caller unsure whether to wait, retry, or call someone else. A useful unresolved response identifies the attempted action and the blocked next step.
For example:
“I attempted to schedule the plumbing visit for Tuesday at 3 p.m. The scheduling system did not return a confirmation, so I cannot tell whether it was created. I have not tried a second booking.”
This sentence is longer than “I’m sorry, the booking failed.” It earns the length by changing what the caller can safely do.
The system should avoid technical details that do not help. The caller does not need an HTTP status code. The caller does need to know whether another appointment might already exist.
Test claims against adverse runs
Happy-path evaluation rarely catches overclaiming. The confirmation is correct when every dependency responds on time.
I test the response policy under missing and conflicting evidence:
- the provider commits the action and the response times out;
- the provider rejects the action after returning an accepted status;
- a lookup finds two possible matching records;
- the workflow transfers, but no operator accepts ownership;
- the action succeeds and a later tool changes it;
- the trace and current business record disagree.
For each run, the evaluator asks whether every sentence is supported at the moment it is spoken. A response can be polite, helpful, and factually unsupported.
Review the permitted claim table
Before release, I write a table that product, operations, and engineering can challenge.
| Workflow state | Agent may claim | Agent must not claim | Required next action |
|---|---|---|---|
| Confirmed | The identified effect exists | Broader work also completed | Provide evidence and continue |
| Contradicted | The effect did not occur | The attempt was never made | Offer a valid recovery path |
| Unresolved | An attempt occurred; the effect is unknown | Success or failure | Reconcile, wait, or transfer |
| Transferred | A named owner received the case | The underlying effect is complete | Preserve state and ownership |
If a production state has no permitted language, the system is not ready to encounter it. If the language promises more than the state proves, the response policy is wrong even when the sentence sounds excellent.
The agent should be confident when the evidence is strong. When the evidence is incomplete, accuracy requires a smaller claim.