Workflow steps should be atomic

The step that hides three steps inside it

Somewhere in your life there is a workflow — a morning routine, a publishing process, a weekly review — that contains a step so familiar you no longer notice it is broken. The step sounds reasonable. "Review the document." "Set up the environment." "Get ready for the meeting." You have done it dozens of times. You know what it means. And that is precisely the problem: you know what it means, but only because you have accumulated enough context to fill in everything the step leaves unsaid. The step itself, stripped of your expertise and your memory and your good days, is a container holding multiple unspecified actions, each of which can fail independently while the step as a whole appears to be in progress.

This is the failure that atomicity solves. An atomic step is one that can be completed without ambiguity — a single, clearly bounded action that either happens fully or does not happen at all. When a workflow is composed of atomic steps, you can execute it reliably even when you are tired. You can hand it to someone else without a thirty-minute explanation. And when something goes wrong, you can identify exactly where the failure occurred, because each step is small enough to serve as its own diagnostic.

The previous lesson established that every workflow needs a clear trigger — a specific event or condition that initiates the sequence. This lesson addresses what happens after the trigger fires: the internal structure of the sequence itself. A workflow with a perfect trigger but ambiguous steps is a machine that starts reliably and then breaks down somewhere in the middle, in a location you cannot identify without re-running the entire process and watching carefully.

The database transaction and the all-or-nothing principle

The concept of atomicity originates in computer science, specifically in database theory. When a database processes a transaction — say, transferring money from one account to another — the operation must be atomic: it either completes entirely (both the debit and the credit) or it does not happen at all. If the system crashes halfway through, after the debit but before the credit, the money has vanished. Atomicity prevents this by treating the entire transaction as an indivisible unit. There is no valid state between "started" and "completed." The transaction either succeeds fully or rolls back as though it never began.

The principle was formalized as the "A" in the ACID properties (Atomicity, Consistency, Isolation, Durability) by computer scientist Jim Gray, whose work on transaction processing in the 1970s and 1980s earned him a Turing Award. Gray recognized that the complexity of a system does not come from the number of operations it performs but from the number of intermediate states in which it can become stuck. Every non-atomic operation creates a potential halfway state — a state in which some sub-operations have completed and others have not, and the system does not know which is which. These halfway states are where bugs live. They are where data corruption occurs. They are where debugging becomes an archaeology expedition through layers of partial completion.

The same principle applies to human workflows, though the failure modes are different. A database crashes because of hardware or software faults. A human workflow "crashes" because of interruption, distraction, fatigue, ambiguity, or a shift change that hands the process to someone who does not share the original executor's implicit knowledge. In both cases, the damage comes from the same structural source: a step that was not atomic, that could be left in a halfway state where partial completion is indistinguishable from full completion or from no progress at all.

When you write a workflow step that says "prepare the report," you have created a non-atomic operation. Preparing the report involves gathering data, formatting tables, writing the summary, checking the numbers against last month's, generating the charts, and exporting to PDF. If you are interrupted after formatting the tables but before checking the numbers, you are in a halfway state. The report looks partially prepared. Whether you remember where you stopped — whether you can resume without re-doing work or skipping something essential — depends entirely on your memory, your attention, and your luck. An atomic decomposition eliminates the luck: each sub-step is a checkpoint that either has been completed or has not, and you can resume from the last completed step without ambiguity.

Gawande's checklists and the anatomy of unambiguous steps

Atul Gawande's "The Checklist Manifesto" (2009) is, beneath its medical narrative, a book about atomicity. Gawande, a surgeon at Brigham and Women's Hospital and a professor at Harvard, set out to understand why modern medicine — practiced by highly trained, deeply experienced professionals — produces so many avoidable errors. His answer was structural, not motivational. The problem was not that doctors were careless or incompetent. The problem was that medical procedures had become so complex that no single human memory could reliably hold every step. Complexity had outrun the capacity of expertise to compensate for it.

The solution was the surgical safety checklist, developed in collaboration with the World Health Organization. The checklist broke complex procedures into simple, unambiguous verification steps. Not "ensure the patient is properly prepared" — that is a compound step that different professionals will interpret differently. Instead: "Confirm patient identity aloud. Confirm surgical site is marked. Confirm antibiotic was administered within the last sixty minutes." Each item passes a test that Gawande made explicit: the step must be specific enough that it can be completed or verified in a single action, and its completion must be observable by anyone present.

The results were dramatic. In a study across eight hospitals in eight countries, the WHO surgical checklist reduced major complications by 36 percent and deaths by 47 percent. These were not marginal improvements. They were the kind of gains that normally require new technology or new drugs. Here, they required only a structural reorganization of existing knowledge — breaking compound actions into atomic steps and ensuring that each step was completed before the next began.

Gawande identified two types of checklists: READ-DO (read the step, then do it) and DO-CONFIRM (do the steps from memory, then use the checklist to confirm nothing was missed). Both types depend on atomicity. A checklist item that says "manage the airway" is useless because it encompasses dozens of possible actions depending on context. A checklist item that says "confirm endotracheal tube placement by auscultation" is useful because there is exactly one thing to do, and it was either done or it was not.

The insight that transfers from surgery to personal workflow design is this: the value of a checklist is entirely a function of how atomic its items are. A checklist of vague steps is not a tool — it is a gesture toward organization that provides the feeling of structure without its benefits. A checklist of atomic steps is a cognitive prosthesis that lets you execute complex processes reliably even when your attention, energy, or experience would otherwise be insufficient.

The next physical action: David Allen's granularity principle

David Allen's Getting Things Done (GTD) methodology, published in 2001 and refined over two subsequent decades, arrived at the same structural insight from the direction of personal productivity rather than surgical safety. Allen's central claim is that most people's task lists are not actually lists of tasks. They are lists of projects — multi-step outcomes that have been written down as though they were single actions. "Plan the offsite" is not a task. It is a project containing dozens of tasks. And the reason it sits on your list undone, generating anxiety every time you look at it, is that your brain cannot execute a project. It can only execute a next action.

Allen's formulation of the "next physical action" is a precise definition of atomicity for personal workflows. A next action must be a single, physical, visible activity that moves a project forward. Not "think about the budget" — thinking is not physical and has no observable endpoint. Not "handle the client situation" — that is a project, not an action. Instead: "Call Sarah at extension 4120 and ask whether the Q3 numbers include the Portland office." That is atomic. It is a single action. It has a clear completion state. You either made the call and asked the question, or you did not.

Allen observed that the mental effort of defining next actions is precisely where most productivity systems fail. People are willing to write down their commitments. They are not willing — or, more accurately, they are not practiced at — decomposing those commitments into the specific physical actions required to fulfill them. The decomposition requires a kind of thinking that feels tedious in the moment but that eliminates an enormous amount of ongoing cognitive friction. Every time you look at a vague item on your list and think "what does this actually mean I should do right now," you are paying a cognitive tax that atomic decomposition would have eliminated at the point of capture.

The GTD system's power comes not from its organizational structure — the contexts, the tickler file, the weekly review — but from the relentless insistence that every item on every list must be a single, concrete, executable action. That insistence is an atomicity requirement. It is the same principle Gawande applied to surgical checklists and Gray applied to database transactions: break the compound into the simple, so that execution becomes a matter of doing rather than figuring out what to do.

Cognitive load and the hidden cost of ambiguity

John Sweller's cognitive load theory, developed through research beginning in the 1980s, provides the psychological mechanism that explains why non-atomic steps degrade performance. Sweller distinguished three types of cognitive load: intrinsic load (the inherent difficulty of the material), germane load (the effort of learning and schema-building), and extraneous load (the effort imposed by poor instructional design or, in our context, poor process design). Extraneous load contributes nothing to the task. It is pure overhead — the mental energy spent figuring out what the step means rather than doing what the step requires.

A non-atomic workflow step is an extraneous-load generator. When a step says "prepare the environment," your working memory must hold open a set of questions: Which environment? Prepare how? What counts as prepared? Is the database included? What about the config files? Each question occupies working memory capacity that could otherwise be directed toward actually performing the work. Sweller's research demonstrated that working memory is sharply limited — George Miller's classic "seven plus or minus two" items, further constrained by the need to actively process rather than merely hold information. Every ambiguous step consumes a portion of that limited capacity for interpretation rather than execution.

The practical consequence is that non-atomic workflows work well only under ideal conditions: when you are alert, experienced, undistracted, and executing the workflow yourself. The moment any of those conditions degrades — you are tired, you are new to the process, you are interrupted, or you are handing the workflow to someone else — the ambiguous steps begin to fail. The experienced practitioner fills in the gaps from memory. The novice, the fatigued version of yourself, or the colleague covering for you does not have those gap-filling resources. They encounter the ambiguous step and either guess (introducing errors), ask for clarification (introducing delays), or skip the step entirely (introducing gaps that may not be discovered until much later).

This is why atomicity is not perfectionism or over-engineering. It is a structural investment in resilience. An atomic workflow degrades gracefully: when conditions worsen, each step still means what it says, and the executor can proceed step by step without needing to interpret or improvise. A non-atomic workflow degrades catastrophically: when conditions worsen, the hidden dependencies and implicit knowledge that held the workflow together evaporate, and the process collapses in ways that are difficult to diagnose because the failure is distributed across multiple sub-actions that were never separated.

The curse of knowledge and the expert's blind spot

Chip and Dan Heath, in "Made to Stick" (2007), described the "curse of knowledge" — a cognitive bias in which people who possess expertise systematically fail to reconstruct what it was like not to have that expertise. Once you know something, you cannot un-know it, and this makes it nearly impossible to accurately predict what someone without your knowledge will find confusing, ambiguous, or incomplete.

The curse of knowledge is the primary reason workflows become non-atomic. The person who designs a workflow is, by definition, expert in that workflow. They write steps that make perfect sense to them because every step is backed by a rich network of implicit knowledge — conventions, preferences, edge cases, and "obvious" prerequisites that the expert no longer consciously registers. "Format the data" seems perfectly clear to the person who has formatted this particular data set forty times. To anyone else — including the expert's own future self, six months from now, having not run this workflow in the interim — "format the data" is an ambiguous instruction that could mean a dozen different things.

The antidote to the curse of knowledge, in the context of workflow design, is the "competent stranger" test. For each step, ask: could a reasonably competent person who has never done this before complete this step without asking me a single clarifying question? If the answer is no, the step contains implicit knowledge that needs to be made explicit, and the step almost certainly needs to be decomposed further. The competent stranger does not need to be a real person. They are a thought experiment — a way of forcing yourself to surface the knowledge you have forgotten you possess.

This test also functions as a gift to your future self. The person who will execute your workflow six months from now, at 7 AM on a Monday after a bad night's sleep, is functionally a competent stranger. They share your general abilities but not your current context. Every implicit assumption in your workflow is a trap set for that future person. Atomicity disarms the traps by making every assumption explicit and every step self-contained.

Lean manufacturing and elemental operations

The Toyota Production System, developed by Taiichi Ohno and Shigeo Shingo from the 1950s onward, formalized the decomposition of work into elemental operations decades before knowledge workers began grappling with the same problem. In lean manufacturing, every task on the production line is broken into standardized work elements — the smallest repeatable units of productive activity. Each element has a defined start point, a defined end point, a defined sequence of motions, and a defined time duration (the takt time).

The purpose of this decomposition is not bureaucratic control. It is three things that matter equally: quality consistency, trainability, and improvability. When work is broken into elemental operations, quality becomes inspectable at each step rather than only at the final output. A new worker can be trained on one element at a time rather than trying to absorb an entire complex process. And when something goes wrong, the failure can be localized to a specific element rather than requiring a forensic investigation of the entire workflow.

Shingo's concept of poka-yoke — mistake-proofing — depends entirely on atomicity. You cannot mistake-proof a compound step because there are too many places where mistakes can occur and too many ways they can interact. You can mistake-proof an atomic step because there is only one thing happening, and the set of possible errors is small enough to anticipate and prevent. A step that says "assemble the component" cannot be mistake-proofed. A step that says "insert pin A into slot B until you hear a click" can be, because there is only one action and one observable confirmation of success.

The knowledge worker's equivalent of standard work is the documented workflow with atomic steps. Most knowledge workers resist this level of specification because they believe their work is too creative, too variable, or too dependent on judgment to be decomposed. Some of it is. But far more of it is routine than most knowledge workers admit, and the routine portions benefit enormously from the same elemental decomposition that transformed manufacturing quality in the twentieth century.

The Goldilocks granularity

Atomicity is a principle, not a mandate to decompose everything into its smallest conceivable units. There is a threshold below which further decomposition creates more overhead than it eliminates — where the act of reading and tracking steps consumes more cognitive capacity than the ambiguity it would prevent.

The practical test for finding the right granularity is failure localization. Ask yourself: if this step fails, will I know what went wrong without further investigation? If yes, the step is atomic enough. If no — if the step could fail in multiple ways, and a failure would require you to re-examine sub-actions to identify which one broke — the step needs further decomposition.

Consider the difference between these two levels of granularity for a deployment workflow. Too coarse: "Deploy the application." This could fail in a dozen ways, and a failure tells you nothing about where to look. Too fine: "Open the terminal. Type 'ssh'. Press space. Type the server address..." This is insulting to the executor and creates overhead that dwarfs the task itself. The right level: "SSH into the production server. Pull the latest code from main. Run the migration script. Restart the application service. Verify the health check endpoint returns 200." Each of these steps is a single action with a single observable outcome. Each can independently succeed or fail. And each failure points directly to its cause without further investigation.

The Goldilocks granularity also varies by audience and context. A workflow written for your own use can assume higher baseline competence — your atomic steps can be coarser because you share context with yourself. A workflow written for a team, for a new hire, or for your future self after a long absence needs finer granularity. The competent-stranger test adjusts for this: the stranger you imagine should match the least experienced person who will actually execute the workflow.

The debugging dividend

There is a secondary benefit to atomic workflows that only becomes apparent when things go wrong — which, in any workflow executed repeatedly over time, is inevitable. Atomic steps make failures diagnosable. Non-atomic steps make failures mysterious.

When a workflow composed of compound steps fails, you face a combinatorial debugging problem. The failure could be in any of the sub-actions hidden inside any of the compound steps, and the sub-actions interact with each other in ways that compound the diagnostic difficulty. You are searching for a needle in a haystack, and you are not even sure which haystack.

When a workflow composed of atomic steps fails, you face a linear debugging problem. You walk through the steps in order. You find the first step whose output does not match its expected result. That is where the failure occurred. There is no searching, no guessing, no interaction effects to untangle. The atomic structure converts a diagnostic problem from exponential to linear complexity.

This is the same principle that makes unit tests valuable in software development. A unit test exercises a single, atomic function. When it fails, you know exactly where the problem is. An integration test exercises multiple functions together. When it fails, you know something is wrong, but you do not know where. Both are useful, but the unit test provides diagnostic precision that the integration test cannot, precisely because it is testing an atomic unit rather than a compound interaction.

Your workflows deserve the same diagnostic precision. Every step you leave non-atomic is a region of your process where failures can hide, where diagnosis becomes guesswork, and where the same errors can recur because the structural cause was never isolated and addressed.

What changes with AI

AI transforms the economics of atomicity by eliminating its primary cost: the tedium of decomposition. The reason most people do not break their workflows into atomic steps is not that they disagree with the principle. It is that the work of decomposition — sitting down, thinking through each step, surfacing implicit knowledge, writing it all out — feels like overhead rather than progress. The workflow itself is familiar. Breaking it down feels like explaining something you already know to someone who is not in the room.

AI changes this calculation. You can describe your workflow in natural language — vague, compound, full of implicit knowledge — and prompt an AI to decompose it into atomic steps, flagging each point where the description relies on assumed context. The AI serves as an automated "competent stranger," asking the clarifying questions that expose your curse-of-knowledge blind spots. "When you say 'format the data,' do you mean convert to CSV, apply the column schema, remove duplicates, or all three?" These are the questions you would never think to ask yourself, because you have forgotten that the answers are not obvious.

AI can also maintain and update atomic workflows over time. As your process evolves — as you discover new edge cases, add steps, or optimize the sequence — an AI can track the changes, flag inconsistencies, and ensure that the workflow document remains current rather than drifting out of sync with actual practice. The drift between documented process and actual process is one of the most common failure modes of workflow documentation, and it occurs precisely because maintaining documentation is tedious enough that people stop doing it. AI reduces the tedium below the threshold where abandonment occurs.

But there is a sovereignty consideration. If AI decomposes your workflow and you accept the decomposition without examining it, you have outsourced your understanding of your own process. The atomic steps are only useful if you understand why each step matters, what it produces, and how it connects to the steps around it. AI should generate the first draft of the decomposition. You should review, correct, and internalize it. The goal is not a document you follow blindly. The goal is a level of understanding so precise that you could reconstruct the workflow from memory — and a document that ensures you do not have to.

From triggers to structure

The previous lesson gave your workflows a clear starting point: the trigger that initiates the sequence. This lesson gives them internal integrity: each step small enough to complete without ambiguity, to succeed or fail independently, and to be diagnosed without guesswork. A triggered workflow with atomic steps is a machine that starts reliably and executes predictably — not because you are always at your best, but because the workflow's structure compensates for the moments when you are not.

The next question is ordering. You now have a set of atomic steps, but how do they relate to each other in time? Some steps must happen in sequence — step B depends on the output of step A, and starting B before A completes would produce errors or wasted effort. Other steps are independent — they could happen simultaneously, and forcing them into a sequence wastes time without adding safety. The next lesson, Sequential versus parallel steps, introduces the distinction between sequential and parallel steps, giving you the structural vocabulary to arrange your atomic units into workflows that are not just reliable but efficient.