What Is the 'Do Not Automate What You Cannot Describe' Principle?
If you can't describe a workflow's inputs, outputs, exceptions, and ownership, you can't automate it well. Here's how to apply this rule to AI projects.
The Automation Trap Nobody Warns You About
Most failed automation projects don’t fail because of bad tools or wrong models. They fail because the person who built them didn’t actually know what they were automating.
That’s the core idea behind the “do not automate what you cannot describe” principle. If you can’t explain a workflow’s inputs, outputs, edge cases, and ownership clearly enough for someone else to execute it manually, you have no business handing it to a machine. The automation will be fragile, inconsistent, or flat-out wrong — and you won’t know why.
This principle applies to any automation, but it’s especially critical in AI projects. AI systems don’t compensate for vague instructions the way a human colleague might. They follow the path you set. If that path is blurry, the output reflects the blur.
This article breaks down what the principle means, why it matters, and how to apply it before you build your next workflow.
Why This Principle Exists
The phrase “don’t automate what you cannot describe” comes from a broader idea in software engineering and business process management: automation is a multiplier, not a fixer.
If a process is well-defined, automation makes it faster and more consistent. If a process is poorly defined, automation makes the mess run faster at scale.
Remy doesn't write the code. It manages the agents who do.
Remy runs the project. The specialists do the work. You work with the PM, not the implementers.
This matters more with AI than with traditional rule-based automation tools. A Zapier trigger-action chain will simply fail silently or throw an error if something unexpected happens. An AI agent, on the other hand, might confidently produce wrong results because it’s good at filling in gaps — just not always the right gaps.
The “It Depends” Problem
One useful test: ask the person who owns a task to describe it out loud. If they use the phrase “it depends” more than once without immediately explaining what it depends on, the process isn’t ready to automate.
“It depends” is fine if it maps to specific, describable conditions. “It depends on whether the invoice is over $10,000 or has a specific vendor code” is a condition you can encode. “It depends on context” is not.
A lot of knowledge work lives in that second category. People develop intuition for when to make exceptions, when to escalate, when to use judgment. That tacit knowledge doesn’t transfer to an automated system unless you surface it explicitly first.
What “Describing a Workflow” Actually Means
Describing a workflow isn’t the same as writing a vague summary of what it does. It means being specific about four things:
1. Inputs
What does the process need to start? This includes:
- The format of incoming data (email, spreadsheet, API payload, form submission)
- The source of that data
- What constitutes a valid input versus an invalid one
- Who or what triggers the process
If you can’t answer all of these, you’ll end up building automation that works most of the time but breaks in ways that are hard to diagnose.
2. Outputs
What does done look like? This includes:
- The format of the output (a Slack message, a record in a CRM, a PDF, a decision)
- Who receives the output or where it goes
- What quality or completeness criteria the output must meet
- Whether the output triggers another process downstream
Vague outputs lead to automation that technically runs but doesn’t produce anything useful. “Summarize the document” is not a good output definition. “Produce a 3-bullet summary of next steps, flagged by urgency, and post it to the relevant Slack channel” is.
3. Exceptions
What happens when things go wrong or fall outside normal parameters? This includes:
- Inputs that are incomplete, malformed, or missing
- Edge cases where the standard process doesn’t apply
- Conditions that require human review or escalation
- What the system should do when it’s uncertain (fail loudly, flag for review, skip and log, etc.)
Exception handling is where most automations fall apart. Builders focus on the happy path and forget that real-world data is messy.
4. Ownership
Who is accountable for the process and its output? This includes:
- Who monitors the automation after it’s deployed
- Who reviews flagged exceptions
- Who has authority to change the rules
- Who is responsible when something goes wrong
Without ownership, automations drift. Rules become outdated, edge cases accumulate, and nobody notices until something breaks badly enough to surface.
How to Apply This Before You Build
The description work happens before you touch any tool. Think of it as a scoping exercise, not a documentation exercise.
Step 1: Write a Process Narrative
Start by writing out the workflow in plain language, in the order it happens. Don’t use bullet points yet. Write it like you’re explaining it to a smart person who’s never done it.
For example: “When a new support ticket comes in, a team member checks the category, looks up the customer’s account tier, and either responds directly from a template if it’s a tier-1 issue or escalates to the relevant product team if it’s tier-2 or above. Tickets from enterprise accounts always go to the dedicated account manager first.”
That one paragraph already reveals several automation design decisions: category detection, account tier lookup, conditional routing, exception handling for enterprise accounts.
Step 2: Map the Conditionals
Go through your narrative and highlight every decision point. For each one, ask:
- What information drives this decision?
- Is that information available in a structured form, or does it require judgment?
- Can you write an explicit rule for it?
If the answer is yes, that decision can be automated. If the answer is “it depends on things that are hard to articulate,” that’s a flag. Either you need to spend more time defining the rule, or that decision point should stay human.
Step 3: Define the Unhappy Path
Most process owners spend 80% of their description time on the 80% case. Flip that.
Ask: what goes wrong? What’s the weirdest thing that has actually happened? What would make the process produce a bad result if nobody caught it?
Document those cases specifically. Then decide, for each one, what the automated system should do — not what a human would ideally do, but what behavior you want from the system given that the human may not be watching.
Step 4: Write an Acceptance Test
Before you build, write a few test scenarios with known inputs and expected outputs. These become your acceptance criteria.
If you can’t write the expected output for a given input, you don’t understand the process well enough to automate it. Full stop.
Step 5: Assign Ownership
Name the person who will own the automated workflow after it’s deployed. Make sure they agree. They need to know what “normal” looks like so they can recognize when something’s wrong.
Signs a Process Is Not Ready to Automate
Some workflows look automatable but aren’t — at least not yet. Watch for these signals:
No one person understands the whole process. If you have to interview five people to understand the end-to-end flow, the process isn’t documented enough to automate. The first step is process design, not automation.
The rules change frequently. Automation works best on stable processes. If the logic changes every few weeks, you’ll spend more time maintaining the automation than you’d save running it.
The output is evaluated by feel. If the only way to know whether the output is good is to have an expert look at it, you need to either formalize that evaluation criteria or keep a human in the loop.
The volume doesn’t justify the investment. Not every repetitive task is worth automating. A process that happens twice a month may cost more to automate correctly than to just do manually.
Edge cases dominate. If your “standard” process represents only 30% of actual cases, it’s not really standard. You’re building automation for an edge case, and the rest will fall through the cracks.
Where This Principle Gets Misapplied
The principle is sometimes taken too literally — used as a reason to avoid automation entirely, when the real intent is to be disciplined about it.
A few common misreadings:
Treating it as a one-time gate. Some teams do the description work once, check a box, and build. But process descriptions go stale. Revisiting them quarterly or after significant changes is part of responsible automation.
Confusing description with documentation. Long process documentation isn’t the same as a clear workflow description. A 20-page SOP document that nobody has read recently is not a valid description. A clear, current, tested narrative of what the process does is.
Using it to avoid ambiguity instead of resolving it. The right response to an unclear process is to clarify it, not to decide automation isn’t possible. Sometimes the description work itself reveals that a process is simpler than it looks, or that a messy process should be redesigned before being automated.
Applying it only to complex workflows. Even simple automations benefit from this discipline. A two-step workflow with unclear output criteria will still produce garbage at scale.
How MindStudio Helps You Build Workflows You’ve Actually Described
Once you’ve done the description work, building the automation should be the easy part. That’s exactly where MindStudio fits.
MindStudio’s visual, no-code workflow builder is designed for people who know what they want to build. Each step in a workflow maps directly to a specific action: receive this input, run this logic, call this model, send this output. That structure naturally rewards the kind of clear process thinking this principle requires.
When you’ve defined your inputs, you know which MindStudio trigger to use — a form submission, an API call, an email, a schedule. When you’ve defined your outputs, you know which of MindStudio’s 1,000+ integrations to connect at the end. When you’ve defined your exceptions, you can add conditional branches and fallback paths that reflect your actual rules, not guesses.
MindStudio’s access to 200+ AI models — including Claude, GPT-4, and Gemini — also means you can match the model to the task once you’ve described what the task actually is. A well-described summarization step might call a different model than a well-described classification step. That specificity only works if you know what you’re asking the model to do.
The platform also supports custom JavaScript and Python for edge cases that don’t fit a standard integration — useful when your process description turns up an unusual exception path that needs precise handling.
You can start building for free at MindStudio — and the description work you’ve done upfront means the build itself will take minutes, not weeks.
Applying This Principle to AI Agents Specifically
AI agents add a layer of complexity because they can take sequences of actions, not just single steps. The “describe before you automate” principle applies at every level.
For an AI agent, you need to describe:
- The goal — not just “research this topic” but “produce a 5-bullet summary of competitor pricing, sourced from public web pages, updated within the last 6 months”
- The decision-making criteria — when should the agent stop? When should it escalate? What constitutes success?
- The scope of action — what tools can it use? What can it write or delete? Where does its authority end?
- The failure modes — if it can’t find the information, what does it do? If it gets ambiguous results, does it make a call or flag for review?
How Remy works. You talk. Remy ships.
Agentic systems that lack this level of description tend to hallucinate confident results, take unintended actions, or loop indefinitely. The more autonomous the system, the more important it is to have described its boundaries clearly.
This is also why the principle matters more as AI capabilities increase, not less. A simple rule-based automation can only fail in limited ways. An autonomous agent given a vague goal can fail in a much wider variety of creative ways.
Frequently Asked Questions
What does “do not automate what you cannot describe” mean?
It means that before automating any process, you should be able to clearly articulate its inputs, outputs, edge cases, and decision rules. If you can’t write a clear description of what the process does and what a good result looks like, you don’t have enough understanding of the workflow to build a reliable automation for it.
Why do automation projects fail?
Most automation failures trace back to unclear process definitions, not technical problems. Teams skip the scoping work, build based on a rough idea of how a process works, and end up with automations that handle the easy cases but break on anything outside the norm. The automation then either produces bad results silently or requires constant manual intervention — defeating the purpose.
How do you know if a workflow is ready to automate?
A workflow is ready to automate when you can clearly answer these questions without hedging: What triggers the process? What does a valid input look like? What does a correct output look like? What happens when inputs are invalid or incomplete? Who reviews the output and who owns the process? If any of those answers are vague, the workflow isn’t ready.
Does this principle apply to AI workflows differently than traditional automation?
Yes, it applies more strictly. Traditional rule-based automation fails visibly when it encounters something unexpected. AI systems, especially generative ones, tend to produce outputs even when they shouldn’t — and those outputs can look plausible while being wrong. A vague process description leads to confidently incorrect AI outputs, which are harder to catch and fix than obvious errors.
Can you automate a process you only partially understand?
You can, but you should be deliberate about it. One valid approach is to automate the parts you understand clearly and keep humans in the loop for the parts you don’t. This is often better than waiting for full clarity before building anything. The key is to be honest about which parts of the process are automated and which require human judgment, rather than assuming the automation handles everything.
What’s the first step before automating a workflow?
Write a process narrative in plain language — no bullet points, no flowcharts yet. Describe what triggers the process, what happens at each step, who makes which decisions, and what done looks like. Then go through it and mark every decision point. That exercise alone will reveal whether your process is clear enough to automate or whether you need to do more definition work first.
Key Takeaways
- Automation multiplies what’s already there. A well-defined process becomes faster and more consistent. An undefined process becomes faster and more broken.
- The four things you need to describe before automating: inputs, outputs, exceptions, and ownership.
- Use the “it depends” test: if your process owner can’t explain what it depends on, the process isn’t ready.
- Write a process narrative, map the decision points, define the unhappy path, write acceptance tests, and assign ownership — before you open any automation tool.
- AI agents require even more precise descriptions than simple rule-based automations, because they can produce plausible-looking wrong results instead of obvious errors.
- Once the description work is done, building is the easy part. MindStudio’s visual workflow builder is designed for exactly that — try it free at mindstudio.ai.
