Should this workflow be automated?

Building has become easier than deciding. You can produce a convincing prototype in an afternoon, before anyone has asked whether the process is frequent, stable, valuable and safe enough to justify another system.

Ask "which part of this workflow should change, and what will it cost to keep that change running?" before you ask whether AI can do it.

The ladder

Most workflows do not need to jump from manual to autonomous. There is a ladder, and each rung is cheaper to build, test and undo than the one above it.

1. Write the method down. A checklist, a template or a shared rubric. Often this alone removes most of the inconsistency.
2. A Prompt with variables. One reusable instruction where the changing parts, such as {{notes}} or {{attendees}}, are filled in each time.
3. A Playbook run by hand in a thread. Named inputs, an instruction, required output sections and a rubric, run by a person when the work arrives, with the output reviewed before it goes anywhere.
4. A triggered workflow. The same method, started by an event, with review gates where the downside changes.
5. A multi-step agent. Several steps with tools, state and handoffs between them.

The smallest valuable intervention is very often rung three. It captures the method in a form you can test and improve, every run leaves a record of what went in and what came out, and a person still decides what happens next. In MyPromptVerse that is all a run is today: one model call with one Operator and one Playbook. Triggered and multi-step runs are not built yet. That order is deliberate: rung three is where we think most workflows should start.

Climb only when the rung you are on is demonstrably the bottleneck.

Map the workflow as it actually runs

Start from what people do, not the procedure document. Capture:

• what triggers the work;
• who owns each step;
• inputs and where they come from;
• the decisions people make;
• tools and handoffs;
• exceptions and rework;
• the output and who uses it next;
• current time, cost and error profile.

Interviewing the owner helps, but inspect real examples. People compress repeated judgement into phrases such as "then I clean it up" or "we know which requests are urgent". Those hidden decisions determine whether the process can be automated at all.

Write the job without the buzzwords

Describe the job in one sentence without the words AI, agent, intelligent or automate. "Research a prospect and prepare a grounded outreach draft for account review" is a job. "Build an autonomous sales agent" is a technology preference.

Then pin down the contract around it:

• Trigger: what starts a run?
• Required input: what must be present before work begins?
• Allowed sources: where may the system look for facts?
• Output: what exact artefact should it produce?
• Quality bar: what makes that artefact acceptable?
• Review owner: who can approve or reject it?
• Action boundary: what can the system do without approval?

If the team cannot agree on these points, it is not ready to automate. Run the process manually until the disagreement becomes visible. A Playbook makes the disagreement concrete quickly, because someone has to write the required sections and the rubric.

From the Library · PlaybookSOP / RunbookTurns rough process notes into a runbook with an owner, trigger, checked steps, failure handling and an escalation path.→

Score the opportunity

Use a small table to compare candidates.

A workflow does not need perfect scores, but each weak factor needs a mitigation. Missing structured input may justify an intake form. High failure cost may require approval before action. No owner is usually a stop signal.

Volume and value are different things

High-frequency work is not automatically worth automating. A ten-second task may not justify integration, monitoring and support. A monthly process may be worth a lot if it eats several expert days or delays a critical decision.

Estimate the current burden as runs × average handling time × loaded cost, then add rework and delay where they matter. Compare it with the full cost of the change: design, build, model usage, review, monitoring, maintenance and incident handling. Avoid fabricated precision. A range with stated assumptions beats a confident return-on-investment figure built on guesses.

Stability comes before automation

Automation encodes a method. If the definition of done, the required inputs, the decision criteria or the responsible roles change every few weeks, standardise first. A checklist, template or single intake route may give you most of the benefit with nothing to maintain.

Sort the steps by type

Map each step into one of four types:

1. Transfer: move or reformat known information.
2. Rule: apply an explicit condition.
3. Generation: create language, options or a draft.
4. Judgement: choose based on context, risk, taste or accountability.

Transfer and rule steps usually suit conventional automation and need no model at all. Generation suits a model with review. Judgement stays with a person, or uses AI to prepare the evidence rather than make the call.

Generation is only one stage. Most reliability problems live in intake, source selection and approval. And not every box needs another agent: a deterministic rule can validate required fields, a search can gather context, a model can draft, and a person can approve the risky decision.

Treat missing context as a state

Weak systems improvise when information is missing. Reliable ones stop, ask or downgrade the output. For each required input, decide in advance:

1. how the missing field is identified;
2. why the run cannot proceed safely without it;
3. the smallest clarification that would unblock it;
4. how the work resumes once it arrives.

For optional inputs, define a fallback and label the assumption. An outreach draft can proceed without a recent company announcement, but it must not invent one. The correct result may be a blocked run rather than a weaker draft.

Model the failure before the happy path

List realistic failures and ask what happens next. A lead-enrichment workflow that matches the wrong person and drafts outreach from someone else's facts does reputational damage even if the direct cost is small. An internal tagging workflow that misfiles one archived note in a thousand is reversible and can be sampled.

For each failure, note its severity, how you would detect it, whether it can be reversed and who is affected. If a serious failure is hard to detect and hard to reverse, do not give the system independent action. Put a human gate there; Human review is not a failure mode covers how to design one.

Count the operating burden

Every automation becomes a product somebody owns. Sources change, APIs fail, policies move, models are updated and edge cases pile up. Name the owner for the rules and acceptance criteria, source data quality, technical operation, review queues, monitoring, and change approval and rollback. If nobody holds these after launch, the prototype is not ready to run unattended.

Stop signals

Escalate from a single prompt or Playbook to a multi-step agent only if at least one of these is true:

• the work needs several distinct steps whose outputs feed each other;
• it needs tools, retrieval or actions in other systems;
• it needs state carried across stages;
• different steps need different models or rules;
• it benefits from approval gates partway through.

Do not escalate if:

• one prompt plus better context would solve it;
• the workflow is too vague to map;
• the review rules are unclear;
• you are building an agent because it sounds more advanced.

If you cannot explain the workflow in plain language, an agent will automate the ambiguity rather than resolve it. If the work is still basically "read this and produce that", improve the prompt and its context. And if the real problem is weak review criteria, poor source material or unclear commercial judgement, an agent just gives those problems a larger blast radius.

Pause altogether when the process is politically contested, the task changes every time, inputs are inaccessible, quality cannot be defined, or the proposed automation would only move work into a review queue.

Pilot it by hand first

Before building anything deep, run the proposed method as a supervised workflow, which in practice means running the Playbook by hand on real cases for a few weeks. Keep the inputs, outputs, review decisions, correction reasons, time taken and exceptions.

That pilot answers what a demo cannot:

• Are the required inputs actually available when the work arrives?
• Do reviewers agree on what good looks like?
• Which exceptions keep coming back?
• Does it save meaningful time, or move the work somewhere else?
• Is the output useful to the next person in the chain?

Before you widen it, test the failure paths as well as the clean cases; the prompt testing guide has a list. The pilot may justify automation, a narrower assistant, or no build at all. Each is a good result if the evidence supports it. Start with one workflow, one owner and one meaningful output, and let the system earn more autonomy through observed performance.