Why uncertainty is a valid answer from a business agent
Uncertain is a real state rather than a polite failure. A message is reported as sent only once the provider has acknowledged it; between the attempt and that acknowledgement it is uncertain, and it is shown as uncertain rather than guessed either way — because re-sending on a maybe is how a customer receives the same reply twice.
Three states, not two#
A send has three outcomes, and a system that models two has to fake one of them. Guess *failed* and the retry produces a duplicate reply, which the customer reads as carelessness. Guess *sent* and a message that never left sits in a sent folder while somebody waits for an answer that does not exist. Both are worse than saying so.
outbound.py is the single boundary both the engine and a person send through, so the three states mean the same thing wherever a message came from. Provider acknowledgement is what promotes uncertain to sent — not the absence of an exception.
Everywhere else the same choice comes up#
| Situation | What is reported |
|---|---|
| A call's usage breakdown | The per-call profiler reports what was measured and says what was not, rather than estimating the gap |
| A memory tier with nothing in it | The empty tier is returned, so *nothing is set here* is a visible answer |
| A mailbox that authenticates and returns nothing | A quiet mailbox — a health signal, not an error and not a success |
| A commercial term Knowledge does not support | A refusal and an escalation, rather than a plausible figure |
| A slow reply the model itself caused | A model-limited finding with no control offered, instead of a setting that would change nothing |
| A time the caller never named | The follow-up tool answers NOT recorded, so nothing can be narrated as booked |
| A call with almost no caller speech | Never sent to the summariser — ten one-turn rows once carried an invented afternoon at a sales desk |
The pattern is the same each time: a gap in what is known is represented as a gap, and the code that would have filled it in is the code that was removed.
What makes an uncertainty useful#
Saying *I do not know* is only half an answer. The half that matters names what is unknown, why, what is being done about it, and what a person can do now. A held or uncertain item goes to Needs You with the thing it concerns beside it, and the entry drains by itself when the cause clears rather than waiting to be dismissed.
- Name the unknown precisely. *Delivery to this recipient is unconfirmed* is usable; *something went wrong* is not.
- Say what is already true. In a troubleshooting situation the useful pair is what was completed and what was not, in that order.
- Offer the act. Resend, wait, check the provider, ask a person — whichever is correct — rather than leaving the reader to invent one.
- Let it resolve itself where it can. An uncertainty that becomes certain should update without anyone touching it.
What a confident wrong answer costs#
An estimate that fills a gap does not stay an estimate. An early version of the voice profiler looked for a duration field the SDK does not report and recorded 0.0 seconds for every call ever metered — a number that was wrong, stable, and would have been trusted indefinitely because nothing about it looked like a guess.
The same shape appears in a summary of a call nobody really had, in a delivery state inferred from the absence of an error, and in a headline count that silently stops at the page size. Each is a fabrication produced by well-meaning code that preferred an answer to a gap.
When uncertainty is the wrong answer#
A caller on the line cannot be given a maybe. A budget refusal on an inbound call plays the spoken closed-line message in the business's own name rather than leaving silence, and a switched-off line does the same — because to the caller, silence is not humility, it is a fault.
The other misuse is habitual hedging. Uncertainty is worth reporting when it is real and specific; qualifying every statement is a different behaviour that produces the same reading experience as knowing nothing. If a thing is verified, say it plainly.
Questions#
Why not retry automatically and deduplicate later?
Because the duplicate has already been read by then. Deduplication works inside a system you control; a second identical email in somebody's inbox cannot be recalled. Where a retry is genuinely safe — an idempotent internal request — it is retried; a send is not that.
Does an uncertain state ever resolve on its own?
Often, yes: a late provider acknowledgement promotes it to sent, and the queue entry drains. That is why the state is displayed rather than converted into a task — most of them need no human action, only honesty in the meantime.
How should an agent phrase uncertainty to a customer?
By saying what is true and what happens next, without inventing a reason. The same rule as an internal report: name what is unknown, say who is finding out, and give a time. What a customer cannot forgive is a confident answer that turns out to be wrong.