Jidoka for Agents: Building AI That Knows When to Stop

Sakichi Toyoda's breakthrough was not a loom that could handle a broken thread. It was a loom that noticed the thread had broken and stopped itself — which meant one operator could run dozens of machines instead of standing guard over one. That principle became jidoka, and Chris Bradley argues it is the most useful idea available to anyone deploying AI agents in an enterprise today. Veritiv's order entry agent was originally given the goal a person would have: complete the order. When it hit something ambiguous, it asked. That design turned every edge case into a round trip — ask, wait, answer, continue — and the waiting became the single biggest brake on adoption of the system. The fix was not a smarter agent. It was a different goal. Book the order, provided nothing needs a human. Otherwise stop where you are, leave the work already done, and hand it back with a specific account of what stopped it. Chris walks through what that change surfaced. How to define friction as needing a person rather than hitting a problem. Why the quality of the stop message decides whether work is removed or merely moved. The hard rule that facts come from the system and only tone comes from the model — earned after a message confidently reported inventory concerns on an order whose inventory was fine. And why the log of reasons an agent stops is not an error report but a prioritized improvement backlog, generated by the work itself. The episode closes on the finding he did not anticipate: an agent that cannot compensate for inconsistent data becomes an instrument that shows you exactly where a process was never standardized — including the difficulty experienced people had been absorbing silently for years. Plus the discipline that keeps that instrument honest: two buckets, and no scorecard.