Fable
The weaving workshop drew the work that could go off track as a stateful diagram
The weaving workshop brought in a master who could arrange the work. He could have the dye house, tailors, accountant, and inspector take turns working, and simple orders could be completed with just verbal instructions.
Once orders became complex, verbal instructions began to fail. Some cloth had to be color-checked before cutting, some had to wait for customer confirmation, and some, after failure, had to go back to the previous step. The master kept more and more processes in his head.
The apprentice first wrote all the steps into one long checklist. The checklist looked complete, but could not handle branches, waits, and retries; once someone interrupted midway, no one knew where the work had stopped.
One time a major client changed the dimensions. The tailor had already cut the fabric, the dye house was still fixing the color, and the accounting office was still quoting according to the old specifications. The process did not break at any single step; it broke because the state was not saved in common.
The master switched to a weaving diagram. Each node was a process step, each edge described the condition for the next step, and the order status was written in the center of the diagram; wherever customer confirmation was needed, it would stop, and after confirmation it would continue along the correct edge.
The weaving diagram also ties knots at key nodes. Even if work stops at night, the next day can resume from the last checkpoint; if a node fails, it can be retried according to the diagram or routed to a manual branch. The most useful are the manual stop points. When a customer delays confirmation, an inspector finds a color difference, or the accountant needs to change a price, the weaving diagram does not force its way forward but stops at the node where it should stop, waiting for a human judgment before continuing.
Later, the weaving workshop could handle multiple orders at once: some executed sequentially, some waited in parallel, and some were handled collaboratively by several masters. The complexity did not disappear, but it was placed into a visible, recoverable structure. Later the manager wrote this experience into the daily rules: first look at the scenario, then the boundaries, and finally who can take over when things fail. Only when all of these are clear will a beautiful demo become deliverable work.
The master understood that multi-step automated task execution is not a string of casual calls, but a work graph with states, conditions, checkpoints and places for human intervention. The woven graph felt clunky at first. But as orders multiplied, the master found that it took "where are we now" out of individual memory and put it where everyone could pick up the thread.