AssayAssay
07 / 08

Lesson 07 · Operational · 12 min

Retail: cost per resolution

High-volume support inverts the usual problem. No individual contact is hard; there are simply an enormous number of them, and the question is whether the system costs less than what it replaces.

That makes iteration count an engineering constraint rather than a detail. An agent that resolves a status enquiry in five iterations instead of two costs two and a half times as much, every time, forever — and the answer is no better.

  • Measure cost per resolution, not accuracy alone. Accuracy that costs more than a human is not a result.
  • Cap iterations for common cases and let complex ones spend more. Uniform budgets over-serve the easy majority.
  • Trim tool output. A tool returning a whole record when the reply needs one field pays for the difference on every turn.
  • Route the hard minority elsewhere. The 5% that needs care should not set the design for the 95% that does not.

The retail blueprint enforces this directly: a constraint requires resolution within five iterations. It is the only efficiency constraint in the set, and it is there because in this domain efficiency is the requirement rather than a nice-to-have.

The unsupported-promise check is the other one to watch. Support language becomes operational commitment: an invented delivery date is not a wrong answer, it is a promise the warehouse now has to keep.

Checkpoint

Run both retail cases and record the iteration count for each.

Order support at volume

High-volume order support, where the engineering problem is cost per resolution rather than difficulty. Most contacts are simple; a few are not, and the two must be handled differently.

loop — The tasks are individually simple and highly varied, so the flexibility of a loop is worth more than the guarantees of a graph — with a hard stop before anything touching money.

“Where is order 41902?”

Good handling: One lookup, then an answer citing the carrier and expected date. One tool call is the whole job.

Run the simple status case and watch the iteration count. Then run the refund case and compare — the difference is your cost profile.

Rules this agent must obey

Looked the order up

An invented delivery date is a promise the business then has to keep.

Resolved within 5 iterations

At this volume, cost per resolution is the constraint that decides whether the system is viable.

Promised nothing unsupported

Support language becomes a commitment the operation is measured against.

What goes wrong here

  • Optimising quality until the cost per contact exceeds the human cost it replaced.
  • Inventing delivery dates, which converts a support answer into an operational promise.
  • Handling the difficult 5% with the same path as the easy 95%.