I originally came across Dan Slimmon’s do-nothing scripts pattern circa 2020, it then resonated with me as the practical pattern I saw working very well within some Amazon teams. Recently, I find myself thinking again about how directly it can extend to agent workflows.

Conceptually, instead of fully automating a manual procedure, you create a script that walks you through each step but doesn’t actually do anything. It just “prompts” you to complete each step manually, then waits for confirmation before showing the next one.

This script doesn’t actually do any of the steps of the procedure. That’s why it’s called a do-nothing script. It feeds the user a step at a time and waits for them to complete each step manually.

At first glance, this seems pointless. You’re still doing all the work. But there is some value upfront here:

It’s now much less likely that you’ll lose your place and skip a step… Each step of the procedure is now encapsulated in a function, which makes it possible to replace the text in any given step with code that performs the action automatically. Over time, you’ll develop a library of useful steps.

The greater value is in the activation energy insight:

A do-nothing script doesn’t save your team any manual effort. It lowers the activation energy for automating tasks, which allows the team to eliminate toil over time.

Slimmon calls these procedures “slogs”:

They’re focus-intensive yet require very little thought. They demand our full attention, but our attention isn’t rewarded with interesting problems or satisfying solutions - just another checkbox checked.

That description fits a lot of agent interactions I’ve seen. The task requires attention to verify the agent isn’t drifting, but the verification itself isn’t intellectually rewarding. It’s a slog. Do-nothing scripts make slogs manageable by creating checkpoints. Agent workflows need the same thing.

This is the same pattern that shows up in research on agent collaboration. Developers who broke tasks into sequential sub-tasks and worked iteratively with agents succeeded on 83% of issues, compared to 38% for those who provided everything at once expecting a complete solution. The temptation with both traditional automation and AI agents is to go all-or-nothing. Automate the whole thing or don’t bother. Delegate the entire task or do it yourself. Both fail for the same reason. Complex procedures have branches, special cases, and hidden dependencies that only surface when you’re in the middle of them.

The pattern maps directly:

  • Do-nothing scripts: decomposition -> verification -> incremental replacement
  • Agent collaboration: decomposition -> verification -> incremental delegation

Both resist the urge to automate everything at once. Both create explicit verification points. Both acknowledge that partial automation has real value, even if the immediate time savings are zero.

Additionally, LLMs can offer greater value. Once you have documented steps in a do-nothing script, you have a structured artifact that agents can actually work with. In the past, you’d find the most impactful automation opportunities only after running the procedure yourself enough times to internalize where the friction was. Now you can point an agent at the script and ask “which of these steps could be automated, and what would you need to do it?” The discovery that used to take months of operational experience can happen in an afternoon.

Better yet, converting text instructions to code becomes nearly trivial. Docker has expored this with runnable markdown where documentation containing commands became directly executable. A do-nothing script is already halfway there. Each step is encapsulated, the dependencies are explicit, and the agent has enough context to generate working automation for individual pieces without needing to understand the whole system. At worst, you can throw an agent to create sub-scripts that are then executed to turn do-nothings into do-somethings with even less activation energy.

And if you’re wondering whether Spec-driven development solve this problem then you may be disappointed. I was quite initially excited about this approach, but I’ve learned to temper expectations. As TL;DR, spec-driven development tries to push all the decomposition upfront by writing a detailed spec, and then letting the agent use it as context. But you still don’t know what you don’t know until you’re executing the procedure. Specs drift from reality just like documentation does. Scripts sidestep this by starting from execution and building structure as you go; as long as you have feedback loops to trim out zombie steps before they become normalized.

When done well, I’d expect such do-nothing scripts to become the interface layer between operational knowledge and agent capability. You’re not trying to specify everything upfront or delegate everything at once. You’re creating a shared artifact that captures what you know, makes verification explicit, and gives agents enough structure to help with the parts you’re ready to hand off.

What I’m less certain about is whether teams will arrive at this naturally or keep reaching for all-or-nothing solutions first. The software world took years to internalize gradual automation, and the current narrative of AI as a great reset might disconnect us from that accumulated wisdom. If so, agent workflow builders will end up relearning the same lesson the hard way.