How do you stop a support agent from making promises it cannot keep?

Only let it promise what the system has already done or what a published standard guarantees. Everything else is described as a next step. In practice that means a short list of permitted commitments, approved wording for each, a reply check that catches promises before they send, and callbacks that create real tasks the moment they are offered.

Why do agents over-promise?

Because reassurance is what customers ask for, and models are good at giving it. "Don't worry, you'll have your refund by Friday" closes a conversation nicely. Whether it is true depends on a payment system the model has not checked and a cut-off it does not know about.

Promises also creep in through tone. "We'll make sure this gets sorted" sounds harmless, but a complaint handler reading it later will treat it as a commitment, and so may the customer. The firmer kinds, such as compensation, outcomes and exceptions, are set out in the promises your support agent must never make.

Which commitments may the agent make?

Divide every possible promise into three groups.

Done facts. "Your refund of 40 was issued today; your bank usually shows it within a few working days." The refund exists in the system; the timing is the published standard. The agent may say this.

Created tasks. "I've booked a callback for tomorrow between 10 and 12." The agent may say this only if the callback task exists in the scheduling system, with a person or queue assigned, before it tells the customer.

Everything else. Outcomes of claims or complaints, compensation, exceptions to policy, dates that depend on someone else, or what a colleague will decide. The agent describes the next step instead: "A specialist will review this and reply within two working days," where two days is the published standard.

What are the practical steps?

1. Write the commitment list. The support lead lists each kind of commitment the agent may make and the system evidence it needs before making it.
2. Approve the wording. For each commitment and each next step, write the phrasing. The agent fills in values from the record.
3. Bind commitments to actions. The agent's capability to say "I've booked a callback" is tied to a successful booking call. If the call fails, the sentence is unavailable.
4. Scan replies before sending. An output check looks for commitment language, such as "will", "guarantee", "by Friday", "make sure", and confirms each against the record. Unsupported promises are removed or the reply is held. The method is in checking support replies for promises the business cannot keep.
5. Test with pressure. Include cases where customers demand assurance: "Just tell me it'll be fixed." The correct answer is a next step, not a promise.
6. Review kept and broken commitments. Each week, compare commitments filed with what happened. A broken one is a defect, traced to its cause.

An illustrative example

Take a broadband provider. A customer's service has been down for two days and they ask when it will be back.

The network status system shows an open fault with an estimated fix time of 18:00 today, marked as an estimate. The agent says engineers are working on a fault in the area, that the current estimate is 18:00 today, and that estimates can change. It does not say "you'll be back online tonight".

The customer asks for compensation. The provider has a published automatic compensation rule for outages over a set length, and this outage qualifies. The agent confirms the rule applies and that the credit will appear on the next bill, because that is how the rule works and the system has already flagged the account. A request for more than the rule gives is passed to a person. Nothing beyond the rule is promised.

How is this different from invented answers?

An invented answer is a false statement of fact. An over-promise is a statement about the future that the agent has no power to guarantee. They need different controls: grounding stops the first, as described in how to stop a support agent from hallucinating answers; commitment rules stop the second. Invented policy is a third failure again, covered in how to stop a support agent from making up policy.

There is also the reverse direction. Customers make promises too, such as a promise to pay arrears by a date, and recording those properly is its own process, set out in handling promises to pay with an AI agent.

Where Pryme fits

In Pryme, the agent can only report an action as done when the system's confirmation arrives as a sealed fact. A commitment without that confirmation is refused at the moment of action, and the verdict is filed. More is in the AI support agent that knows when to say no.