The demo worked. Who owns the next click?

Stop the demo one screen later

Here is a demo I would want to see: a support agent opens a ticket, gets an AI-drafted reply, edits an incorrect sentence, checks the source, and sends the message. Then another ticket arrives with missing account data. What happens now?

That second ticket is where the product conversation gets interesting. Does the draft disappear? Does the agent have a normal reply box? Can they tell whether the system is still working? Is the send button disabled for a reason they understand? A beautiful first answer does not answer any of those questions.

For this design exercise, follow the ticket all the way to completion. The job is responding to a customer accurately, not making text appear in a box. Checking a source, correcting a mistake and deciding to send are part of the product too.

Give the first version a smaller job

For a first release, I would ask the system to draft, cite and flag uncertainty. I would leave sending to the support agent. That is not the same as calling a system safe because a human is somewhere nearby. The reviewer needs the evidence, enough time to read it, and a clear way to reject the draft without starting over.

Keep the existing workflow available. If an assistant cannot draft a reply, the agent should still be able to handle the ticket. Put the suggestion next to the work rather than forcing the work into a new chat window. Every copy-and-paste handoff is another place where context can be lost.

Anthropic’s engineering guide distinguishes predefined workflows from more autonomous agents and argues for using the simplest approach that fits the task. For this example, a bounded drafting workflow is enough. It does not need permission to wander through every tool the support team uses.

Download Excalidraw source ↗Click diagram to enlarge

Text version

Proposed first release

1. Read the ticket: Authorized account context + relevant evidence
2. Prepare a draft: Suggested reply, citations, unresolved questions
3. Agent reviews: Edit, reject, or send through the existing workflow

On missing context or a generation failure: keep the normal reply editor available. No automatic send.

Measure the work that remains

A draft acceptance rate can be misleading. Accepting a draft may mean it was good, or that the reviewer was rushed. Rejecting one may mean it was poor, or that it helped the agent notice something important. The click is a signal, not the outcome.

A small, permissioned review of completed tickets with the support lead is more revealing. How much editing was needed? Did the final reply address the actual problem? Was an incorrect claim sent? How long did the whole ticket take, including checking sources and waiting for the draft? Separate those observations by ticket type. A tidy aggregate can hide a workflow that helps with routine questions and makes exceptions slower.

This requires a baseline. Ask agents to handle comparable tickets with the current tools before deciding what improvement looks like. Agree on which errors are unacceptable. A made-up refund promise should not be averaged away by a hundred nicely formatted greetings.

Download Excalidraw source ↗Click diagram to enlarge

Text version

Proposed release review · criteria set with the support lead

1. Was it correct?: Sample final replies. Check unsupported promises and wrong account details.
2. Was it useful?: Compare total handling time and editing effort with the existing workflow.
3. Could they recover?: Test missing data, timeouts, rejected drafts and a disabled assistant.

Someone has to own Tuesday morning

Who reviews a reported bad draft? If the answer is ‘the AI team’, keep asking. A policy error may belong to the knowledge owner. Incorrect account data may belong to an integration owner. A reply that is factually correct but inappropriate for an angry customer may need a change to the product’s behavior. One mailbox can receive reports, but somebody still has to make the decision.

I would keep a short incident record: the ticket category, what the system proposed, what the reviewer changed, and which component needs attention. Store only what is necessary under the organization’s access and retention rules. A debugging workflow should not quietly become a second, less protected customer database.

A useful pilot also has an off switch. The operations lead should know who can disable drafting, what users will see, and whether ordinary ticket handling will continue. Test it. An untested fallback is just another demo.

Autonomy can come later, one action at a time

There may eventually be a case for automatically handling a narrow class of tickets. That decision needs evidence from the actual workflow, a precise action policy, authorization enforced outside the model, and a recovery plan. Good results on drafting do not establish that the system is ready to issue refunds.

I would rather launch a limited assistant that agents choose to keep than a wide-ranging one they work around. The most revealing product question is not whether the demo gets applause. It is whether the person on the next shift can explain what the assistant does, when to distrust it, and how to carry on without it.