Prompt chaining: the double charge

A support agent reads a ticket, pulls out the order number and the problem, judges how urgent it is, and writes a reply. On Tuesday a customer wrote: "I was charged twice for order 88213, please fix this today." The agent replied: "Thanks for reaching out about order 82813! Glad all is well." Then it sent the email. The run ended with status success.

Two digits were swapped and a customer who had been charged twice was called neutral. Nobody noticed until the customer replied, angrier. The trace below is the whole run. It is six lines long.

The prompt asked for three things at once: extract the entities, judge the sentiment, write a friendly reply. A model doing three jobs in one call does each of them a little worse, and when the first job goes wrong the other two build on it. The order number was wrong at line 3. By line 4 the reply was already written around it.

The deeper problem is not the model. It is that nothing stood between the extraction and the reply. No check that the order number in the output matches the one in the ticket. No rule that a ticket with the words "charged twice" cannot be neutral. The chain had one link, so there was nowhere to put a gate.

Split the job into steps with a checkable output between them. Step one extracts a small JSON object: order_id, issue, urgency. Step two is not a model call at all: a gate that checks the order_id is a substring of the ticket text, and that issue is not empty. Only then does step three write the reply, and it writes it from the checked JSON, not from the raw ticket.

This is prompt chaining, and the point of it is the gates, not the prompts. Each step does one thing, its output has a shape, and a plain function can refuse to pass it on. When the check fails the run stops and a person gets the ticket. That is a better outcome than a cheerful email with the wrong number.

Cost goes up a little: three short calls instead of one long one. Latency goes up by about a second. In return, the failure moves from the customer's inbox to a log line you can alert on.

When an interviewer shows you a run like this one, say the line number first, then the cause, then the gate. "Line 3. The extraction returned 82813 for a ticket that says 88213, and nothing checked it before the reply was written. I would split extraction from reply and put a string check between them." That is the whole answer. Everything after that is detail they will ask for if they want it.