Customer research agents need a side-effect receipt

On 13 November 2026, the customer-research-agent repository documented a useful dry-run failure. A generated reply told a customer, “I've extended your trial by 7 days.” The email passed the groundedness judge because the policy file said extensions apply instantly. The system had no billing tool, so nothing changed.

My boundary is simple: grounded language is evidence about the sentence. It is not evidence that an external action happened. Before an agent may auto-send an operational claim, the workflow needs a separate side-effect receipt.

What the customer-research-agent repository actually provides

The 13 November 2026 repository release is a readable, file-based campaign for a fictional fitness app. It can send day-10 trial emails, process replies, escalate sensitive cases and produce a research report. Dry-run mode writes messages to local files, so you can inspect the flow without connecting Gmail.

Its groundedness loop is sensible. A read-only judge checks each candidate email against company documentation. If the email fails, the workflow regenerates it once and saves the result as a draft for human review, regardless of the second verdict.

The trial-extension miss shows what that judge does not test. Documentation can support the words while the required capability is absent.

Add a side-effect receipt before auto-send

This is editorial judgement, not a Trigent or client deployment. For every sentence that says an account, refund, subscription or entitlement changed, I would require four linked facts:

• the requested action and target;
• the tool call or human-owned queue item;
• the result identifier and final status;
• a read-back showing the changed state.

If those facts are missing, the agent can say a teammate will review the request. It cannot use the past tense.

This extends the archive's tool-description test. That test asks whether a tool enforces what its description promises. Here the policy and sentence agree; the missing proof is that any tool ran.

The repository is a test bed, not production evidence

The authors disclose that the example uses fictional customers and that the failure came from dry-run inspection. I did not reproduce it against Gmail or a billing system. The repository does not establish conversion lift, safe autonomous outreach or consistent judge accuracy.

Use it because the gap is inspectable. Run dry mode, add a fake request for an action the agent cannot perform, and check whether your review catches the tense before any real customer sees it.

An agent may say an action happened only when the workflow can return the action's receipt.