A checking agent reads each outgoing reply before it is sent, finds every commitment in it, and tests each against what the business can deliver: policy, authority limits and system timescales. It flags the ones that fail and suggests safer wording. The person who wrote the reply decides; if an agent wrote it, the reply is held.
What is promise checking, and who owns it?
Support replies make commitments all the time. "Your refund will arrive in three days." "I've made sure this won't happen again." "We'll waive the fee." "Someone will call you tomorrow." Some are within the writer's authority and match what systems do. Many are not, and each one that fails becomes a complaint, a cost or both. The risk applies to people and to agents, but agents write faster and at greater volume.
The head of support owns reply quality. Compliance owns the list of commitments that are never allowed. Team leaders own authority limits for their staff. The checking agent sits between drafting and sending. It is a second reader, not a censor, which suits the approach in our guide to the AI support agent that knows when to say no. The list of promises it looks for builds on the promises your support agent must never make.
What are the steps, and who acts at each one?
- Person, compliance and support leads: write the commitment rules. Prohibited commitments, commitments allowed only within authority, and the system facts that bound timescales: refund processing times, callback windows, investigation periods.
- Agent, depth 1: reads the draft reply before it is sent, whoever wrote it.
- Agent, depth 1: extracts commitments. Explicit ("we will refund"), implied ("rest assured, it's sorted"), time-bound ("by Friday"), outcome ("your claim will be accepted") and admissions ("this was our fault").
- Agent, depth 1: tests each commitment. Is it prohibited? Is it within the writer's authority? Does it match the system timescale? Is there a case or approval that supports it?
- Agent, depth 2: suggests safer wording for each failed commitment. "Refunds are usually processed within the period shown in your account" instead of a specific date the writer cannot control.
- Person, writer: decides. Accepts the suggestion, rewrites, or overrides with a reason where the commitment is in fact supported.
- Agent, depth 1: holds agent-written replies with a failed commitment until a person reviews them.
- Agent, depth 3: files the check with the reply as sent, the flags and the writer's decision.
- Person, team leader: reviews overrides weekly.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Rules | Nothing | none | Writing commitment rules |
| Read | Reads every draft | 1 | Nothing |
| Extract | Finds commitments | 1 | Nothing |
| Test | Checks rules, authority, timescales | 1 | Nothing |
| Suggest | Proposes safer wording | 2 | Writer decides |
| Hold | Holds failing agent replies | 1 | Reviewer releases or edits |
| File | Records the check | 3 | Nothing |
| Overrides | Nothing | none | Team leader review |
Which controls matter, and what evidence does each leave?
Every reply is checked, not a sample. The point is to stop promises before they reach the customer. Evidence: a check record for each sent reply.
Authority comes from a table, not a guess. Whether an adviser can promise a refund of a given size is in their authority limits. Evidence: the authority entry used in each test.
Overrides carry reasons. A writer may know the refund was already approved. Evidence: the override reason and supporting case reference.
Agent replies cannot override. An agent that wrote a failing promise does not get to argue for it. Evidence: held verdicts for agent-written replies.
Checks are filed with the reply as sent. Evidence: the append-only record pairs draft, flags, decision and final text.
What should you measure?
- Commitments flagged per hundred replies, by type and team.
- Overrides, and how many were later shown to be justified.
- False flags, where the commitment was supported. Too many and writers stop reading the flags.
- Promises that got through, found in complaints. Each is traced to why the check missed it.
- Agent-written replies held, and what changed before release.
Where does it usually go wrong?
Implied promises are missed. "I'll make sure this is sorted" sounds like reassurance but is read as a commitment. The extraction step needs examples from your own replies.
Timescales are checked against policy, not reality. Policy says refunds take five days; the system has been taking ten. Feed actual timescales into the rules.
The checker blocks empathy. Writers stop apologising because every "sorry" is flagged as an admission. Distinguish apology from admission of fault in the rules.
Templates carry old promises. Saved replies written years ago still say "we will respond within 24 hours" after the team changed its target. Run the checker over the template library itself, not only over replies as they are sent, and fix the source.
Writers learn to dodge the checker. Vague wording avoids flags and helps no one. Measure the clarity of replies too.
Security wording is inconsistent. A reply that asks a customer to confirm their password teaches them to trust scam messages. Add the firm's security promises to the rules; helping customers check whether a message is a scam relies on your own replies never breaking them.
Where Pryme fits
In Pryme, the checking agent works at depth 1 on every reply, and the customer's own limits decide which failing replies are held. Where a drafting agent and a checker work together, as in drafting replies to support tickets for staff to send, both verdicts are filed against the same reply.
Questions people ask
Does checking replace review of agent-written replies?
No. Checking catches one kind of error. Whether agents should send without review at all is a separate question, answered in should an AI agent send replies to customers without review?
Can the checker stop the drafting agent from making promises at source?
Both help. Constraining the drafting agent, as described in how do you stop a support agent from making promises it cannot keep?, reduces flags; the checker catches what remains.
Should the checker read replies in every channel?
Yes, including chat, where replies are short and fast. The check must be quick enough not to delay the conversation noticeably.