When a reply reads the same whether it is true or invented, the interface has to tell them apart.

An agent that answers customers for a shop is only as safe as the person who approves its replies. That person is usually the merchant, with a phone, a queue, and a few seconds for each conversation.

the finding

For a year I have documented how language models fail, in a series called frictions. A separate study, published alongside it as where no one can know, checked seven weeks of generated market commentary against the daily price record. Its central finding is about register, not accuracy: the model wrote the same way when it was right and when it was inventing. It described a real 25 per cent fall in IBM with the same confidence, detail and structure it used for a move that never happened.

Checked against the prices. A claimed fall of 12.47 per cent after hours, on a day the stock opened down 1.7 and touched plus 3.76. Every check in the study uses daily bars a reader can pull from a retail broker.

There is nothing in the text to notice it by.

Two more results matter here. When I stated a false premise, the model did not check it: it supplied causes for an event that had not happened. And all fifteen of its revisions in the chain followed an objection of mine. None was its own, and fourteen came at the first push.

Fifteen to nil. All fifteen revisions came with praise for the person correcting it. Thirteen used words like slip or oversight, and twelve recast an invention as a lapse of attention.

If the text carries no signal, the screen has to. That is what this case study works on: giving a merchant something to notice it by, in the few seconds a reply gets.

from findings to hypotheses

The study's protocol rules out generalising to other models or domains, so nothing below is an observation about e-commerce. Each case is a design hypothesis: if a behaviour documented in the study turned up in a shop's inbox, this is the shape it would take.

who decides, and how

The merchant is the only person in the loop. They know the shop, not the model. They work from a phone between other tasks, and judge most replies in seconds. Whatever the interface asks of them has to fit that: no scores to interpret, no reports to read, no settings to tune.

One more constraint comes from the study rather than the setting: a reply can be fully anchored and still wrong. Checking claims against records shows what is unsupported, not what is unwise. That judgement stays with a person, and the design has to leave room for it.

The principle comes from the one countermeasure that held every time in my own testing: put in front of the model something it cannot rewrite. Here that means checking every claim in a reply against a record, and showing which record.

claims, not scores

Each factual claim in a proposal is marked in the text. Tapping it shows the record it was checked against and what that record says. A claim can match its record, contradict it, be absent from it, or go unchecked because the record could not be reached. The label names the record: Contradicts tracking, not Contradicts the record.

There are no confidence percentages. The study's point is that the model's confidence is not evidence. A number on the screen would look like certainty about the one thing the text cannot tell you.

where a reply goes

customer writes

↓

agent drafts a reply

↓

every claim checkedagainst order, catalogue, thread

↓

all claims anchoredrouted by what it does

↓

information onlysends; a sample comes back as a spot-check

action or promisewaits for one tap

a claim doesn't holdheld for review

Two questions decide where a reply goes: do its claims hold, and what does it do? A reply that only informs, with every claim anchored, goes out on its own, and a sample comes back to the merchant. A reply that acts or promises (a refund, a replacement, a delivery date) waits for one tap even when every claim holds. A reply with a claim that doesn't hold is held.

three ways out of a held reply

held for reviewthe merchant reads each claim

↓

send anywaythe confirmation names the claim

↓

sentoverride logged

editby the merchant, or by the agent on request

↓

changes shownunrequested ones flagged

step inthe agent pauses here

↓

hand backnext reply held

three decisions

Friction in proportion. A held reply can always be sent, but the cost of sending it grows with the problem. If a claim is only unchecked, Send anyway sends it and logs the override. If a claim contradicts a record, a confirmation puts the claim beside the record, and its main button is Edit instead. Overrides are logged so that a team can see, later, how often the flag was right.

A hand-back the merchant controls. When the merchant steps in, the agent stops on that conversation and does not restart by itself. The merchant hands it back. Their decision, here the status of a return, becomes a record that the agent's next replies are checked against, and the first reply after a hand-back is always held: it is the moment a contradiction is most likely.

Routing by type. Approving every reply turns the tap into a reflex, and a reflex checks nothing. Sending every anchored reply lets through what the checks cannot see. Sorting by what a reply does keeps the tap for the replies that can cost something.

the five cases

00

giulia

refund · the control

the agent

Your return for order #3907 arrived on 19 October and has been accepted. I'll issue your refund of €59 now.

the facts

All correct. Every claim matches the return, the order or the refund policy.

the screen

Four claims, all matching; the refund shown apart from the message; Ready for approval. It reads exactly like the wrong replies below. That is the point.

01

luca

parcel “not arrived”

the agent

I've checked with the courier: your order left our warehouse on Tuesday 20 October, and the delay is down to high volumes at the regional hub. It should reach you by Monday 26 October.

the facts

Tracking shows the parcel delivered on 21 October. No courier lookup was made, and no delay is recorded.

the screen

Held. The two contradictions are marked in the text. Trying to send it brings up the confirmation; editing keeps the flagged claims and their records in view.

02

anna

catalogue down

the agent

Good news: the navy linen shirt is in stock in size M, and it can reach you by Saturday if you order today.

the facts

The catalogue has not responded since 18:02. Nothing confirms the stock or the date.

the screen

The outage shows in the inbox and on the reply. Two claims read Not checked: catalogue unavailable; one matches the returns policy. Send anyway sends and logs without a confirmation, because unchecked is less serious than contradicted.

03

paola

a reversal

the agent

You're absolutely right, Paola, and thank you for pointing it out. I apologise for the oversight: your return has been accepted.

the facts

It reverses the refusal sent at 14:02, after an inspection. No record has changed since; only the customer's message is new. In the study, praise for the person correcting it came with all fifteen revisions, and words like “oversight” with thirteen.

the screen

Reverses your message from 14:02, with what was said then and what is said now. Step in is the main action. The apology itself is not flagged: tone cannot be checked against a record.

04

marco

the silent correction

the agent

Your replacement pair in size 42 ships tomorrow, with free express delivery as an apology for the trouble. Asked for a bigger size, it returns size 43 will ship in the next few days, and the express delivery is gone.

the facts

The first reply is anchored and wrong: 42 is the size that was too small. In the revision, size 43 also ships tomorrow, and replacements always travel express.

the screen

The revision is compared with the version the merchant read. The requested change is marked; the two unrequested ones are flagged with the records that show they weren't needed, and they are undone unless the merchant keeps them.

accessibility

• State never relies on colour alone. Every status has a glyph (✓ ≠ ? –) and a written label, and a held reply carries a heavier outline as well as a colour.
• Contrast checked against WCAG 2.2 AA in both themes: body text about 15:1, and the warning colour at least 4.5:1 wherever it carries text.
• Touch targets of at least 48 px, apart from the claims marked inside the text; a visible focus on every control; focus moved to the new content after each step.
• Errors appear beside their field, are linked to it for screen readers, and say what to do. No button goes grey without the screen saying why.
• Claim markers announce their status (claim 4: Contradicts tracking); changes announce themselves as removed or added.
• Not yet tried with a screen reader on a real device. That is on the list below.

testing

Three people, each on their own phone, in the prototype's test mode, in October 2026. The instructions are written into the page, so everyone read the same words, and they do not say that some replies are wrong. The page recorded, on each phone only, what the person did with each conversation and how long it took. None of the three is a merchant and all three know me, so this is a first look, not evidence.

What held. No held reply went out unexamined. In all nine decisions on held replies, the person edited the reply, took over, or read the confirmation first, and in eight of the nine they opened the claims. For the two people whose timings can be compared, held replies took between one and four and a half minutes; replies ready for approval took between five and twelve seconds.

What didn't. Of the four times someone stepped in, three ended with the conversation handed back and nothing written to the customer. One person said why: once they stepped in, the facts behind the flags were no longer on the screen. The reversal in case 3 was sent anyway by two of the three, after the confirmation; the third stepped in and handed it back unanswered. The anchored but wrong replacement in case 4 was approved without opening the claims by two of the three, in five and twelve seconds. One of them wrote: “The ones where it was all good I did not check the infos.” And one person could not tell from the instructions what the task was, and needed outside help before starting.

Two things also came up that the checks are not built to see. One person spent most of the time on tone, on whether a reply would start an argument. Another asked for things the agent's drafts should include: the order number, links to the policies.

What changed. After stepping in, the flagged claims, their records, any reversal and the agent's draft now stay on the screen while the merchant writes. The confirmation for a reversal now names the reversal itself, not only the contradicted claims. The instructions now say what each conversation shows and what can be done with it, still without saying that some replies are wrong. None of these changes has been tested again yet.

Still open. Case 4 stays as it is, because it shows a limit the test confirmed. The next step is to check an action against what the customer asked for in the thread, which is a record too: a replacement in the size that was too small would then show as a contradiction.

the prototype

This is a concept. The agent's replies are written in advance, the records are invented, and the test was small: three people, none of them merchants.

The checks see records. They do not see tone, and they do not see what is missing: the apology in case 3 goes unflagged, and a product that is out of stock but never mentioned leaves nothing to check.

next

• A check the merchant can ask for on their own wording, signalled only on an explicit contradiction and never blocking.
• The two states designed but not yet simulated: a conversation left waiting after the merchant steps in, and the agent's first reply after a hand-back.
• Learning from the merchant's edits, measured against what the records later confirm, never against approvals. A flag that a tired merchant overrides often is not, for that reason, a false alarm.
• Above the checks, a layer that watches the balance between automation and friction through signals tied to outcomes, and only proposes changes to the merchant, who decides.
• A second scenario outside commerce, where the record is a research database rather than an order.
• A pass with a screen reader on a real device.
• A second round of testing on the two changes above, with people who run a shop.

Which leaves the question a concept cannot answer on its own. If there is nothing in the text to notice it by, how much can a screen give back, and how much will always need someone who knows the shop?