Seven AWML Findings in Yegge's Design

Steve Yegge published The Counting House this week, a design for letting cheap AI models handle customer service one kind of case at a time.¹ It is a good design, so I drew it in AWML to test both the modelling language and the design. An evening of drawing turned up seven findings, before anyone built anything.

Last week I argued that you must draw your AI workflow to control it. When I drew six of my own workflows, I found a slew of problems I had missed. The examples on GitHub include a family’s meal planning (something I have done a lot of thinking about), but it was not a complex enough example to really show how AWML can help. This time I wanted a serious design for a large company written by someone who has run one of these departments.

Yegge ran Amazon’s customer service tools group in the early 2000s. His design is for contact centres, claims processing and other casework handling millions of cases a year.

In his Counting House system his cheap models (called “clerks”) start fresh, handle one case and stop. They hold no credentials and cannot write to real systems. A policy table has one row per kind of case, or “intent”, such as a refund or rebooking. It sets the model, its freedom to act and who must approve what.

People first score a few hundred real cases per intent. Two score blind; a third settles disputes. A judge model must agree with them about as often as they agree with each other. Errors are priced: leaving a child at the gate costs far more than misrouting an email.

When a clerk proposes a change, plain code, the orchestrator, checks it against the live system and carries it out using the “saga” pattern.²

I mapped out the whole thing. Here are the findings.

1. The “Shadow” Stage Is 75% of the Cost

By my estimate, about three quarters of the build goes into shadow, before any model answer reaches a customer.

I drew a fictional airline rebooking a passenger after a missed connection at all five levels. At off, people do everything. At shadow, models answer alongside them for scoring. At assist, models suggest and people decide. At contain, models reply to customers. At transact, their proposals change real systems through the orchestrator.

Off to shadow added twelve parts, including the gateway hiding personal details, the model, judge and score stores. Assist added two, contain three and transact seven. Yegge says shadow “doesn’t save you money yet”, but every later level depends on its scores.

Fund shadow as the main project. Each later promotion is a small change you can read in a minute. Back in February I wrote that autonomy is earned through evidence, without skipping levels.

2. Name Who Accepts Risk

A customer reply cannot be taken back. AWML flags contain because nobody reads the reply before it goes out.

Yegge already has the right people involved. Before a model moves up a level, someone from each of five departments signs off its row in the policy table, and each signs for their own piece. CS ops and floor supervisors own the standard procedure, and the knowledge in people’s heads that has to be written down. QA and data science own the scored cases, the rubric and the judge. Finance owns the cost of each kind of mistake and the approval thresholds. Legal and compliance decide which intents may ever reach contain or transact. Platform and IT own the gateway, the orchestrator and the rest of the plumbing.

Drawn in AWML, those sign-offs are a chain of five reviews. Each is a yes to the exact change, and only after the last one does code write it into the policy table.

That chain approves the promotion once. After it, contain sends thousands of replies that nobody reads, so the drawing also needs the decision that covers them. Put it on the drawing as a standing approval, naming who accepted the risk and the evidence they used. In my example, customer experience and legal accept it on the October test cases, for replies on this one intent only. Anyone can see where models reply without a person checking, and who agreed to it.

3. Check Replies at Contain

The orchestrator checks changes to bookings, but a reply at contain never passes through it. Yegge names the risk as “reputational harm to the company because of something a clerk types”. Here is that part of the contain drawing. The orange lines show where the customer’s own words travel: into the clerk, past the standing approval and out in the reply.

The contain level, zoomed in. Open the full drawing on awml.io.

A sweet-talking customer’s words can reach the reply with nothing reading them on the way. Keep contain to replies built from checked facts, such as flight status, and have code check each reply before sending.

4. Check the Judge

A message meant to fool a model could affect which intents the judge is trusted on, and which models get promoted.

To illustrate this, I drew an example judge system of six workflows sharing data: live contacts, refused cases, building the scored set, testing the judge, promoting a model, and scoring every contact to send contact reasons to their owners. (The last is the loop Yegge ran with Jeff Bezos each week, and to my mind it is the most valuable piece of the whole design: every contact tells the business what to fix next.)

Open the full map to explore each workflow.

Real messages enter the scored set, then test the judge, with no human check of that test in my drawing. The scorers already read every message. Have them flag attempts to steer a model and keep those out of the judge’s exam.

5. Define the Demotion Rule

Demotion needs a rule the system can act on. Yegge calls the judge “the scorer for promotions and demotions” and says a bad score moves a model down a level. He does not spell out the threshold or workflow.

Promotion from assist to contain needs five departments’ approval. For falling scores, perhaps after a model update, draw the return path too. Here is one way to draw it. Every night code compares each intent’s scores with the bar in its policy row. When an intent falls below its bar, it drops a level straight away, and QA and data science find the cause before putting it up for promotion again.

Dropping a level needs no sign-off, because it makes the system safer. Going back up takes the full five.

6. Record the System Fixes

The contact chart needs a record of what got fixed. At Amazon, owners of the top contact reasons “were held accountable for fixing their own issues”. Yegge describes that accountability, but no record linking a fix to its result.

Record each fix against its contact reason, and the next week’s chart shows whether it worked - this is the magic that Yegge talks about where Bezos was 25 years ahead of the competition, writ large for all to see. Drawn in AWML, it is a small workflow beside the weekly chart: each owner logs the fix they shipped, and code compares that reason’s contacts before and after.

7. Keep Prices Current

The price list sets how much risk each intent can carry. Yegge gives finance ownership and says to update costs when a cheap mistake proves expensive, but leaves the workflow and approval unclear.

Draw the list as a store with a named finance owner. Send every mistake that cost more than its price to that person, who updates it and records why.

In the drawing, the price keeper is one amber box. It sits between the costly mistake and finance’s cost table, so every price change has a name and a reason beside it. The promotion workflow reads that same table, so the next model to go up for promotion is judged on the new prices.

What AWML Cannot Check

AWML is not an evaluation tool. It shows who scores what and where the scores go, but not the scores themselves. The evaluations, Yegge’s scored cases, judge and priced mistakes, live in the platform that runs the work, and that is where they should be. Undo steps, acting only once and blind scoring remain labels too; the platform must make them work.

Yegge describes people “moving up the stack”: scoring cases, settling disputes, handling refusals and training clerks. Every amber box on the map is one of those people, doing work the system cannot do without them.

Is there an AI design you have only read? Draw it and you will gain much more insight. You can read more about AWML, and draw your own, at awml.io.