gotoHuman

A support agent drafts a response to an inbound ticket, pulling the customer's plan, their last three tickets and the relevant policy. The draft goes to gotoHuman as a review with the proposed reply, the policy it cites and the refund amount it offers. The reviewer reads it in the Agent Inbox, trims two sentences, lowers the goodwill credit, and approves. On Review Completed returns the edited field values, and the agent sends the reviewer's version through Zendesk. The human did editing work, not gatekeeping work, and the difference shows up in the outbound message.

Refunds above a threshold, contract changes and record deletions all route through the same pattern. The agent assembles the case, calls List Review Templates to pick the template that matches the decision type, and raises the request against it. Because each template carries its own field set, a refund review shows the order, the customer's history and the amount, while a deletion review shows what will be destroyed and what references it. The reviewer sees a screen built for that decision rather than a generic approve button, and the Stripe refund or the record deletion only executes on their answer.

Once a review loop has been running for a few weeks, List Review Responses becomes a training corpus. A scheduled flow pulls the approved reviews for a template, along with the difference between what the agent suggested and what the reviewer finally submitted, and writes those pairs into the prompt library the drafting agent uses. The reviews that get rejected most often point at the instruction that is wrong. Review load falls because the agent got better, which is the only sustainable way for it to fall.