Run better AI workflows
What Should You Automate With AI? Start With the Workflow, Not the Model
Do not automate the easiest task. Automate the smallest end-to-end workflow whose output you can accept and measure, and whose failures you can recover from.
TL;DR
- A task demo proves that a model can act. An MVP has to prove that the workflow creates value.
- Choose work that is repeated, bounded, verifiable, and recoverable before you choose a model or tool.
- Define the human decision, acceptance evidence, and recovery path before giving AI more ownership.
- Measure time to accepted output, rework, exceptions, review load, and downstream impact instead of generated volume.
01A task demo is not an operational win
AI can turn a rough brief into code, copy, analysis, or a prototype. That proves generation, not a faster product or operations loop. If the customer problem is fuzzy, the handoff changes halfway through, or nobody knows whether the result is acceptable, faster generation just gets you to the wrong answer sooner.
For example, AI drafts a support reply. A person still has to find the account context, check policy, correct the category, send the message, and record the exception. The task got faster. The request did not. The demo simply moved the work downstream.
The practical answer is simple: do not automate the easiest task. Automate the smallest end-to-end workflow whose output you can accept and measure, and whose failures you can recover from.
02Building speed and iteration speed are different jobs
A product team does not learn because it produced more artifacts. It learns when a customer signal becomes a decision, the decision becomes a bounded change, the change reaches a user, and the observed result informs the next decision.
Building is one step in that loop. AI can compress research synthesis, option generation, specification, scaffolding, testing, and evidence collection. Product judgment still has to decide which customer problem matters, what tradeoff is acceptable, what scope is worth approving, and what the result actually means.
The same distinction applies to business operations. Generating a response is fast. Resolving the request, recording what happened, routing the exception, and making the next run better is the workflow.
The product loop to map
- Customer or operational signal enters the system.
- A person makes the decision the signal is meant to inform.
- The decision becomes a bounded brief with an owner and a quality bar.
- AI and humans execute the parts they are equipped to own.
- A reviewer accepts, rejects, or escalates the result with evidence.
- The observed outcome changes the next decision.
03Run the AI Workflow Fit Test before choosing a tool
Repetition and time cost are useful first filters. They are incomplete. They do not tell you whether the whole loop can be owned, reviewed, or recovered when it fails.
The AI Workflow Fit Test is the five-question screen I would use before approving a pilot: user job, workflow friction, AI boundary, acceptance evidence, and business test. If one answer is vague, the workflow is not ready. Tighten it before comparing models or buying another platform.
The five questions
- User job: Whose problem changes, and what accepted result do they need? Start with their job, not the feature you want to add.
- Workflow friction: Where do delay, rework, queues, duplicate effort, or dropped handoffs actually occur? Diagnose the bottleneck instead of assuming the visible task is the problem.
- AI boundary: What may the system own, what requires human judgment, and what must it never change without approval?
- Acceptance evidence: What will a reviewer inspect, which checks can run automatically, and how does a failed result recover?
- Business test: Which movement would justify continuing, redesigning, or stopping the pilot? Name the threshold before the first successful demo makes everyone optimistic.
04Choose work that is repeated, bounded, verifiable, and recoverable
Frequency matters because a workflow that rarely runs cannot repay much setup or maintenance. It is not enough. The best first candidate also has a clear boundary, a result that can be checked without redoing all the work, and a failure that can be contained.
The five-question test tells you what to inspect. These four traits tell you how to route the candidate: automate, augment, constrain, or wait.
05Build the smallest end-to-end MVP
A quick MVP is not a chatbot beside the workflow. It is the thinnest complete path from a real trigger to an accepted business result. The goal is to learn whether the operating loop works before you add autonomy, integrations, or scale.
For the first version, I would constrain it to one request type, one source of context, one AI action, one reviewer, one accepted output, and one durable record. That is narrow enough to keep a failure cheap and visible while still exposing the real design problems.
The MVP needs all six parts
- Trigger: the real event that starts the work, not a demo prompt someone remembers to paste.
- Context: only the inputs the system needs, with a named source of truth.
- AI action: one bounded transformation, recommendation, or draft.
- Review: a person or deterministic check that can accept, reject, or escalate the result.
- Accepted output: the artifact or state the next person can actually use.
- Durable record: what happened, what evidence was checked, and what should change next time.
06A real workflow can reject the work
I use the same pattern in the system behind this site. A rough article request does not go straight into drafting. It gets one discovery outcome, one business outcome, a search-intent decision, an authority check, a bounded brief, an editorial review, visual QA, and a durable publication record.
One planned article stopped before the draft because the point was broad and the proof was weak. That was the workflow doing its job. A system that can only generate has no way to protect the business from confident waste.
This does not prove that the same design will improve every process. It demonstrates the mechanism: explicit ownership, observable gates, a reject state, and enough recorded evidence to make the next decision.
07The right boundary changes with the workflow
The framework stays the same across a solo business, a product team, and an operations function. The ownership line does not. These three scenarios show where I would start and what I would keep human.
08Measure accepted work, not generated output
Prompts sent, drafts generated, and hours spent inside an AI tool are activity metrics. They can rise while the workflow gets worse. The useful unit is accepted work that moves the next decision or customer outcome.
Set a small baseline before the pilot, then compare the same workflow after it. You do not need a perfect ROI model to learn. You need a stable unit, a visible review burden, and a stopping rule.
The first scorecard
- Time to accepted output: from the real trigger to something the next person can use.
- Rework rate: how often the result needs material correction before acceptance.
- Exception rate: how often the workflow leaves its designed path and why.
- Review load: how much human time and attention acceptance actually costs.
- Downstream movement: whether the customer, product, or operational result changed in the direction you intended.
09Do not automate yet if nobody can own the result
Some workflows should wait. If the process changes every week, the quality bar lives in one person's head, or nobody owns the exceptions, automation will create a faster argument instead of a better system.
Use AI as decision support while you clarify the process. Ask it to organize evidence, surface options, or prepare a review. Keep the consequential action human until the workflow earns more ownership.
Stop before the build when
- The workflow has no accountable owner.
- A good result cannot be distinguished from a plausible one without redoing the work.
- The process is still changing so quickly that every run needs a new rule.
- Failure is irreversible, hidden, or too consequential for the available review.
- The workflow is too rare to produce a useful learning loop.
- The pilot has no threshold for scale, redesign, or shutdown.
Still having trouble?
Pull me into your project with @Vlad, your virtual co-founder. Or, if you'd rather work with the real me, set up a call.
10 / Key takeawayConclusion
Start with one slow, expensive, or inconsistent workflow. Map the full loop, choose the smallest bounded AI action, keep the consequential judgment where it belongs, and decide what evidence would earn the next step.
This is the work I do with solo founders, product teams, and operations leaders: find the workflow worth changing, design the human and AI boundary, build the smallest working MVP, and instrument it so the next iteration is based on evidence. Bring me one messy workflow. I can help turn it into a working test with an owner, acceptance criteria, and a clear decision about what to build next.
Vladislav Zhirnov
Quick answersCommon questions
What should a business automate with AI first?
Start with a repeated, bounded workflow whose output is easy to verify and whose mistakes are recoverable. Prefer a complete path from trigger to accepted result over an isolated task that only moves work into a review queue.
How do I know whether a workflow is a good AI candidate?
Name the user job, the actual bottleneck, the AI boundary, the acceptance evidence, and the business test. If any of those are vague, narrow or repair the workflow before choosing a tool.
Should AI automate a task or an entire process?
The first AI action should be narrow, but the test should cover the end-to-end workflow. A bounded action inside a complete loop reveals handoffs, review cost, exceptions, and whether the output creates value.
How small should an AI MVP be?
Small enough to use one real trigger, one context source, one bounded AI action, one reviewer, one accepted output, and one durable record. Add autonomy only after that loop works repeatedly.
Which decisions should stay human?
Keep decisions that define the customer problem, approve meaningful tradeoffs, accept high-consequence risk, or change the business's commitments. AI can prepare evidence and options without owning the final judgment.
How should I measure an AI workflow?
Track time to accepted output, rework, exception rate, review load, and the downstream result. Generated volume and AI usage are activity signals, not proof of impact.
When should I avoid AI automation?
Wait when the workflow has no owner, no testable quality bar, unstable rules, irreversible failure, or too few repetitions to learn. Use AI for evidence preparation or decision support while you fix the operating process.
Sources
3 references- Box: A guide to AI workflow automation (opens in a new tab)blog.box.com
- Department of Product: How to Identify Opportunities for AI Automation (opens in a new tab)departmentofproduct.substack.com
- VladZ.ai: Stop Making GPT-5.6 Sol Do Everything (opens in a new tab)/guides/stop-making-gpt-5-6-sol-do-everything
Choose your next move