A workflow that keeps growing and only one person can explain it
45-minute simplification session
Draw trigger, steps, handoffs, output, and owner on one page
Sign 1: No one can explain the whole path
If your team needs a diagram and one particular person to know what happens next, that person has quietly become the workflow. Stop adding steps and write the trigger, the actions, the outputs, and the owner of each step on a single page.
How to judge it: hand that page to someone else and ask them to predict the next run. If they can’t, you have a memorized process, not a documented one—and the day your interpreter is on holiday, a failed run sits untouched because no one dares change it. Writing the page costs an afternoon, and it will drift unless you update it with each change, but an out-of-date page still beats one person’s memory.
Sign 2: Exceptions outnumber the clean runs
A workflow that needs a fresh special case almost every run has no stable contract. Each exception is another branch you have to remember and test, and once they outnumber the clean runs, “normal” is a story you tell yourself. Narrow the job until the common path is boring, and split the genuinely different cases into their own workflows.
How to judge it: look back at twenty runs and count how many needed a manual fix or a one-off rule. More than a handful means the scope is too wide. The failure to watch for is the collision—you bolt on “if the order is from region X, do Y” enough times that a new rule quietly contradicts an old one and both misfire. Splitting into two workflows is two things to maintain, but each earns a contract you can state in one sentence.
Use case: the nine-step restock report
Nadia runs a two-person subscription box and lets her agents handle the Monday restock report. It started simple and grew: three agents, two spreadsheets, and four notifications now produce one report in nine steps. Only Nadia can narrate the whole path (sign 1), the supplier list is copied into both spreadsheets (sign 3), and when the stock check fails nothing tells her until the numbers look wrong (sign 4).
In her 45-minute session she weighed two options. The tempting one was to add a “supervisor” agent to watch the others—but that is a sixth moving part and a fifth notification, more complexity dressed up as control. The other was to remove parts: merge the two agents that share the same access, drop the spreadsheet that only copies data, point both remaining steps at one supplier list, and route any failure to her own inbox with the run and the reason attached.
She chose to remove. The path dropped from nine steps to five, the supplier list went from three copies to one, and failures finally had somewhere to land. The lesson: she fixed the complexity by taking parts out, not by adding a smarter part to manage them.
Nadia’s restock workflow, before and after
Illustrative figures from one 45-minute simplification session—an example of removing parts rather than adding a supervisor, not a customer result.
Two duplicate agents merged and one copy-only step removed.
One source of truth; agents pass a link, not a full copy.
Every error now reaches one inbox with the run and the reason.
Sign 3: The same data lives in several places
When the same record is copied between agents, the copies drift the moment one changes, and agents then act on stale data with no way to tell which version was right. Choose one source of truth and pass a link or an identifier instead of the whole record.
How to judge it: if you corrected one customer’s email today, how many places would you have to update? The healthy answer is one. The failure case is ordinary and expensive—an agent emails the old address because it read the copy that hadn’t been refreshed. A single source does create a real dependency: every agent now needs it to be available. That named dependency is still safer than copies that fall out of sync in silence.
Sign 4: Failures have no owner
Every handoff should name who receives a problem and what information they get. “The system will retry” is not ownership—unowned failures don’t vanish, they wait, and a retry loop can hide a broken step until the backlog surfaces days later.
How to judge it: think about the last failure. Who was told, and did the message say what to do? If the answer is “a log nobody reads,” fix that before anything else. The failure case is the quiet one: an agent retries a dead connection forty times overnight, no alert fires, and Monday’s report is simply wrong. Routing every failure to a person adds interruptions, so route only the ones a person must decide and let the rest fail loudly into one named inbox. Recovery logic also gets harder to reason about as steps multiply, which is one more reason to keep the path short.
Sign 5: One small change forces you to check everything
If changing one step means opening five others to see what breaks, the parts are wired too tightly together. Reduce what they share, give each agent one clear job, and let a change stay local. Tight coupling turns every improvement into a risk, so eventually you stop improving and the workflow quietly goes rigid.
How to judge it: to change the report’s format, how many agents or spreadsheets must you touch? One is healthy; five is the warning. The failure case hides in the wiring—you reword a notification and a downstream agent that matched its exact phrasing silently stops firing. Decoupling can mean repeating a little simple logic in two places, but independent parts are far safer to change than one clever web where everything depends on everything.
Try this next
- Draw the whole path on one page—trigger, every step, each handoff, the output, and who owns a failure. If one person has to narrate it from memory, start here.
- Pause unused schedules, remove connections nothing calls, and merge any two agents that share the same access.
- Point every step at one source of truth, and give each remaining handoff a named owner with the context they need.
- Re-draw the simplified path on one page, and resist adding a supervisor agent to manage what a smaller workflow no longer needs.
Sources and further reading
These primary references support the article’s core claim—that simplicity is what keeps multi-step automation reliable—and its guidance on owning failures and adding a component only when the load truly calls for it.
Argues that reliability depends on minimizing accidental complexity—every added component is a liability, and boring, predictable systems are the goal.
AWS Prescriptive GuidanceSaga patternA failure-management pattern for multi-step work; notes that debugging difficulty and rollback complexity grow with the number of steps—support for keeping the path short and each failure owned.
Microsoft Azure Architecture CenterQueue-Based Load Leveling patternStates plainly that when volume is predictably low and stable, adding a component “provides little benefit”—a check before reaching for another agent or integration.
Ready to put one useful workflow to work?
Start with one clear job, a result you can review, and boundaries you understand.
See launch pricing