An automation that works on launch day is an achievement. An automation that still works sixty days later, at a sensible cost, is the real goal. Between those two dates, inputs change, volumes grow, people find edge cases and a vendor quietly updates a model. The workflow does not break dramatically. It drifts: a little slower, a little more expensive, a little less accurate, until someone notices that the team is fixing its mistakes by hand again.
Optimization is the discipline that stops that drift. It is not glamorous, and it is not about clever prompts. It is mostly about removing work, checking work earlier and measuring what happens. This guide gives you nine techniques, in the order that usually pays off, plus a weekly routine to keep the gains. If you have not built a workflow yet, start with the practical deep dive on AI workflow automation and come back here once something is running.
Start with a baseline, or you are guessing
You cannot optimize what you have not measured. Before you change anything, write down five numbers for a typical week:
- Volume: how many items went through.
- Correction rate: how many outputs a person had to fix or reject.
- Human review share: how many items needed a person before they could finish.
- Time to complete: from the item arriving to the item done.
- Cost per completed item: model usage, tool fees and the time of the people who review.
These five are enough. Do not build a dashboard with forty charts. If you can only get two of them today, take correction rate and cost per item, because they tell you whether a change is worth keeping.
You also need a test set: a fixed collection of real examples with the right answers known. Every optimization below should be checked against it, so that "cheaper" never quietly means "worse." If you do not have one yet, build a test set before you tune anything.
Technique 1: Remove steps before you improve them
The fastest step is the one that no longer exists. Before you tune anything, walk the workflow from start to finish and ask of each step: what breaks if this disappears? In practice you will find steps that exist for historical reasons, approvals nobody reads, copies of data into a second tool that nobody opens, and notifications that people have muted.
A useful test is to look for steps that never change the outcome. If a reviewer approves 99 percent of what they see, with no edits, they are not adding judgment. They are adding delay. Either automate the approval for the safe cases or give the reviewer only the unusual ones, which is technique three.
Removing a step also removes a failure point, a cost line and something to maintain. Nothing else on this list has that effect.
Technique 2: Fix the input, not the model
When an AI step performs badly, the instinct is to rewrite the prompt. More often the problem is the input. Messy, incomplete or inconsistent data makes every downstream step work harder and fail more.
Common input fixes:
- Make fields required at the source, such as a form that will not submit without an amount or a customer identifier.
- Standardize formats early: dates, currencies, names of products or departments.
- Strip noise like email signatures, quoted reply chains and legal footers before the model reads the message. This also shortens the input, which lowers cost.
- Split mixed inputs. An email that contains three requests is three items. Treat it that way.
A rule of thumb: every minute spent making inputs cleaner saves more than a minute of prompt tweaking, and the improvement does not depend on the model version.
Technique 3: Route by difficulty
Not every item deserves the same treatment. Most workflows have a large group of easy, repetitive cases and a small group of hard or risky ones. Treating both the same wastes money on the easy ones and under-protects the hard ones.
A simple routing design has three lanes:
| Lane | What goes here | How it is handled |
|---|---|---|
| Fast | Clear, common, low-risk items | Automated end to end with spot checks |
| Assisted | Ambiguous or mid-value items | AI drafts, a person reviews before it ships |
| Human | Unusual, high-value or sensitive items | A person handles it, with context prepared |
Routing can use plain rules first: item type, amount, customer tier, missing fields. You do not need a model to decide the lane. Add a confidence signal later if rules are not enough. The point is that the person's attention goes where it matters, which is also the idea behind human-in-the-loop design.
Technique 4: Use the smallest model that passes your test set
Larger models are more capable, slower and more expensive. Many workflow steps do not need that capability: classifying a message, extracting fields from a standard document or choosing between five categories.
Run the step on your test set with a smaller or faster model. If the results meet your quality bar, keep it. If they do not, you have learned that the step is genuinely hard, and you can leave a larger model there. You can also split the step: let the small model handle the clear cases and send the uncertain ones to the larger model or to a person.
Two cautions. First, judge on your data, not on general rankings, because performance varies by task. Second, re-run the test whenever a provider changes or retires a model, since behavior can shift without any change on your side.
Technique 5: Cache repeated work
If the same question arrives repeatedly, you should not pay to answer it repeatedly. Common candidates:
- Reference lookups such as a vendor's payment terms or a product's policy.
- Fixed prompts and instructions that are the same on every call. Some providers let you reuse a long, unchanging prefix at a lower cost, so check what yours offers.
- Classification results for identical or near-identical inputs.
Cache with an expiry. A stale answer in a workflow can be worse than a slow one, so decide how long each cached item stays valid, and clear it when the source data changes. If you are unsure, cache only data that changes rarely.
Technique 6: Batch what is not urgent
Real-time processing feels better and costs more, in tool calls, in rate-limit pressure and often in model fees. Ask which parts of your workflow truly need an instant response.
Many do not. Invoice coding, weekly reporting, tagging of old tickets and data cleanup can run in a nightly or hourly batch. Batching also lets you apply checks across a group, for example spotting duplicates, which is hard to do one item at a time. Keep real-time only for steps where a person or customer is waiting.
Technique 7: Put cheap checks before expensive ones
Order your checks from cheapest to most costly, and stop as soon as one fails.
- Format checks: is the field present, is the date a date, is the amount a number?
- Rule checks: is the amount under the approval limit, is the vendor on the approved list, is the account active?
- Consistency checks: does the total equal the sum of the lines, does the order match the invoice?
- Model checks: only when the first three pass, ask a model to judge the parts that need judgment.
This order does two things. It saves money, because you stop paying for model calls on items that were never valid. It also makes failures easier to understand, because a rule failure has a plain reason. If you work in accounts payable, the same logic shows up in three-way match exceptions.
Technique 8: Design the failure path on purpose
Every workflow fails. The question is whether it fails safely and visibly. For each step, decide in advance:
- What happens on a timeout or an error? Retry a limited number of times with a delay between tries, then stop.
- Where does a failed item go? A queue that a named person owns, not a log nobody reads.
- How do you avoid doing it twice? Make steps safe to repeat, for example by using a unique ID so that a retried payment or email does not duplicate.
- When does the workflow pause itself? Set a threshold, such as an error rate above a limit, that stops new items until someone looks.
Retries, timeouts and duplicate protection are standard integration problems, covered in webhook failures and retries. Treat them as part of the design, not as repairs after the first outage. A good failure path often matters more to the team's trust in the workflow than a higher accuracy number does.
Technique 9: Review five numbers every week
Optimization is a habit, not a project. Set aside twenty minutes each week with the owner of the workflow and look at the same five numbers you measured at baseline: volume, correction rate, human review share, time to complete and cost per item.
Ask three questions:
- What changed since last week? Volume jumps, a new input source, a changed model or a new team member can all explain a shift.
- What are the three most common corrections? Group them. One or two causes usually explain most of the fixes.
- What single change will we test next? Pick one. Change one thing at a time, run the test set and keep it only if the numbers improve.
Write each change and its result in a short log. After a few months this log becomes the most useful document about the workflow, because it records what you tried and why. For a structured cadence, see the weekly and monthly alert review and monitoring and alerting for operations teams.
A worked example: support email triage
Imagine a team that uses AI to read incoming support emails, label them and draft a reply. It works, but replies take too long, costs have crept up and agents rewrite many drafts.
Applying the techniques in order might look like this:
- Remove steps: the workflow copies every email into a second tracking tool that nobody opens. Remove it.
- Fix the input: strip signatures and quoted threads before the model reads the email. Shorter inputs, cleaner results.
- Route by difficulty: order-status questions and password resets go to the fast lane. Billing disputes and complaints go to the assisted lane. Legal or safety mentions go straight to a person.
- Smallest model that passes: classification runs on a smaller model. Only drafting for the assisted lane uses the larger one.
- Cheap checks first: a rule confirms the customer account exists before any model call.
- Failure path: if the email system times out, the item goes to a named queue, and a unique ID prevents double replies.
- Weekly review: track correction rate by lane and keep a log of changes.
None of these steps needs new technology. Each one is a decision about where effort and money go. If you want the full design for this use case, read AI ticket triage for support operations.
Common optimization mistakes
- Tuning without a baseline. You cannot tell whether a change helped, so you keep changes that did not.
- Changing several things at once. When the numbers move, you do not know why.
- Optimizing cost alone. A cheaper workflow that makes more mistakes usually costs more once you count the cleanup.
- Ignoring the people who review the output. Reviewers know the common corrections better than any dashboard. Ask them.
- Chasing a perfect score. Past a certain point each improvement costs more than it returns. Decide what "good enough" is before you start, and stop when you reach it.
- Letting the test set go stale. Add new real cases regularly, or your checks will describe last quarter's workflow.
Free tool
Automation ROI calculatorTurn a repetitive task into hours saved, monthly savings and payback time using your own numbers.
When optimization is not enough
Sometimes the right answer is to change the design. If a workflow needs constant human correction even after routing, checks and input fixes, the underlying process may be unclear or inconsistent, and automation is amplifying that. In that case, go back to the process itself: write down the steps, agree on the rules and remove the exceptions. Choosing what to automate first and writing an SOP people follow are the places to start. A clear procedure is the cheapest optimization of all.
Key takeaways
- Optimize only after the workflow works, and measure a baseline first: volume, correction rate, human review share, time and cost per item.
- Removing steps and cleaning inputs usually beat any prompt change.
- Route items by difficulty so people and larger models only handle what needs them.
- Use the smallest model that passes your own test set, and re-test when models change.
- Cache repeated work, batch what is not urgent and run cheap checks before expensive ones.
- Design failure paths on purpose: limited retries, a named owner, protection against duplicates and a pause switch.
- Review five numbers weekly, change one thing at a time and keep a log.
Sources and further reading
Links were checked on October 22, 2026. Features and pricing change, so confirm on the source before you act.
- Anthropic: Building effective agents. Recommends finding the simplest solution that works and adding complexity only when it clearly improves results, which is the core of optimization.
- NIST AI Risk Management Framework. A voluntary US framework whose Measure and Manage functions describe ongoing monitoring of AI systems.