Why a sales agent should refuse to answer

The questions that create an obligation#

Most of what a customer asks is a question about facts, and an agent grounded in a workspace's own Knowledge answers those well. A small set is different in kind: the answer is not information, it is a commitment, and the business is bound by it whoever typed the sentence.

• Price, discount and terms — what something costs, what can be taken off, what the payment terms are.
• Time and service commitments — how fast, by when, what happens if it slips.
• Warranty and liability — what is covered, for how long, and who bears a loss.

The failure is not that a model gets these wrong at random. It is that a model asked a direct commercial question produces a fluent, specific, plausible answer — which is exactly the kind of answer a customer quotes back later.

Refusing is the behaviour, not the bug#

safe_sales.py refuses a commercial term Knowledge does not support and escalates it. That reads as a limitation until you price the alternative: a single improvised discount on a live call is worth more than the entire efficiency gain of automating the conversation, and a customer who was told a delivery date is entitled to it.

This is why the refusal is written down as correct rather than logged as unhandled. A gap invites somebody to close it — by adding a fallback price, by widening what counts as supported. Naming it as the designed outcome changes the review question from *why did it refuse* to *why is this not in Knowledge yet*, which is the question with a useful answer.

Prevented on one path, detected on the other#

The carrier voice path and email both run each generated sentence through the check before anything leaves, so a priced sentence never reaches the customer. The realtime path is different by construction: the model speaks directly to the caller, and nothing sits between its output and the line.

price_spoken deliberately uses the same expression the carrier path checks each sentence with, so the two paths agree on what a price is. Without that, the detector and the preventer would drift apart and the realtime numbers would mean something slightly different from the email ones — which is worse than not measuring.

Keeping the deal alive while refusing#

1. The agent declines to state the term and says a person will confirm it.

   Result The customer has an answer that is true, and no commitment has been created.

2. The opportunity is raised for review (raise_for_review) with the question attached.

   Result It appears for a person with the context around it rather than as a bare alert, and clear_review closes it when the answer exists.

3. A follow-up is created with its reason, on the channel that suits the answer.

   Result The commitment to come back is itself recorded, so the refusal does not become silence.

The Assistant's rights are narrower than a person's for the same reason: it cannot set pricing, and it cannot clear a do-not-contact entry. Two capabilities are operator-only because they are the business of running the platform rather than using it — verifying customer payments, and JBRH's own pricing.

Where this is still weak#

• A refusal that sounds like a stonewall costs the deal anyway. The wording is part of the mechanism, not decoration around it.
• Knowledge that is out of date produces confident wrong answers that the rule does not catch, because the term *is* supported — by a stale source.
• The realtime detector counts priced lines; it cannot count the ones that were correctly refused, so the rate on live calls is UNKNOWN here.
• A customer can extract a commitment by implication — *so that would be within the week?* — which reads as agreement rather than as a stated term.

Questions#

Related#

• Sales in Connect
• Why uncertainty is a valid answer from a business agent
• Separating the agent's authority from the person's
• Knowledge in Connect
• Making a next-best-action defensible