7.3 Optimize Workflows for Efficiency and Effectiveness
7.3.1 From One Output to a Repeated Workflow
Lessons 7.1 and 7.2 are reactive: something is wrong with one output, and you diagnose and adjust until it isn't. Optimization is a different, proactive move — it makes a workflow that runs repeatedly faster, cheaper, and more reliable every time it runs, not just the one time something went wrong. The question shifts from "how do I fix this result" to "how do I make every future run of this task better by default."
7.3.1 — Key Concept
Troubleshooting a single weak output and optimizing a repeated workflow are related but distinct: one fixes an instance, the other redesigns the process so future instances start from a better baseline.
7.3.2 Five Levers for Optimizing a Repeated Workflow
Five concrete levers do this work, and each is a standing design choice, not a one-time correction.
| Lever | What it buys |
|---|---|
| Right-size the model per step | A fast model for bulk simple work, a stronger one only where reasoning is genuinely hard — efficiency and cost together |
| Persist reusable context in a Project | Instructions and knowledge aren't rebuilt every session — consistency and speed |
| Standardize proven prompts | Quality doesn't depend on re-inventing the prompt each time — templates or system-level instructions carry the win forward |
| Calibrate human review | Review effort matches the stakes — kept where it counts, streamlined where it doesn't |
| Decompose long tasks | Checkable steps catch errors early instead of letting them compound across a long task |
Five levers that optimize a repeated workflow, distinct from diagnosing one bad output (7.1) or iterating on one prompt (7.2).
7.3.2 — Key Concept
Right-sizing the model and standardizing prompts are the same moves used to fix a single output in Lessons 7.1–7.2, applied here as a standing policy for every future run of the workflow — not a one-time fix.
7.3.3 Balance Cost, Speed, and Quality — Don't Maximize One
Effective optimization balances cost, speed, and quality against the task's real requirements — it does not maximize any single lever in isolation. A change that makes a workflow cheaper or faster is only a genuine optimization if quality stays at or above what the task actually needs. Routing everything to the cheapest model, or skipping review to save spend, looks like progress on cost while quietly degrading the dimension the task depends on.
Cost, speed, and quality are traded off together against the task's actual requirements — optimizing any one corner in isolation is not a genuine optimization.
7.3.3 — Exam Trap
Optimizing only for cost or only for speed while quality drops below what the task needs is a common exam trap, not a best practice. A genuine optimization keeps quality at or above the task's real bar while improving cost or speed.
7.3.4 Human Review Is a Governance Lever, Not a Speed Cost
Removing human review to save time on high-stakes output is not an optimization — it is a governance and quality risk dressed up as speed. The correct move is calibration: heavier review where stakes are high, lighter review where they are not, so verification effort matches how much a mistake would actually cost. Treating review purely as overhead to be minimized, rather than a lever to be calibrated, is the specific mistake the exam is testing for here.
7.3.4 — Exam Trap
"Remove human review to go faster" on high-stakes output is a governance/quality risk framed as an efficiency gain — it is not a legitimate optimization. Calibrate review to stakes instead of uniformly cutting it.
7.3.5 Put It Together: Exam Traps for Task Statement 7.3
- •Assuming decomposition, model right-sizing, or Projects are one-off fixes rather than standing workflow design choices meant to pay off on every subsequent run.
- •Optimizing only for cost or only for speed while quality drops below what the task needs — a genuine optimization keeps all three in balance.
- •Treating human review as purely a speed cost to minimize or remove, instead of a governance lever to calibrate against stakes.
Where this shows up on the exam
7.3 questions describe a repeated, ongoing workflow (not a single output) and ask what would make it better long-term. Look for the answer that names a standing lever — right-sizing, persisting context, standardizing prompts, calibrating review, or decomposing — balanced against cost, speed, and quality together.
Key Takeaways
- ✓Optimization targets the whole repeated workflow, not just one weak output.
- ✓Right-sizing the model per step and persisting context in a Project both buy efficiency and consistency across runs.
- ✓Standardized prompts and decomposition into checkable steps make quality and error-catching repeatable, not one-time wins.
- ✓Genuine optimization balances cost, speed, and quality against the task's real requirements — not maximizing one lever alone.
- ✓Human review should be calibrated to stakes — kept where it counts, streamlined elsewhere — not simply minimized or removed.
- ✓Removing human review on high-stakes output to save time is a governance/quality risk, not an optimization.
Check Your Understanding
Test what you learned in this lesson.
Q1.Which of the following is a genuine workflow optimization?
Q2.A team routes every step of a high-stakes financial reporting workflow to the cheapest available model to cut costs, and also removes the analyst review step to save time. Output quality drops noticeably. What happened?
Q3.A workflow currently requires the same detailed instructions to be re-typed into Claude at the start of every session. What is the standing fix, rather than a one-time workaround?
Q4.A high-stakes legal-review workflow and a low-stakes internal meeting-notes workflow both currently require the same level of human review before output is used. What does calibrating review to stakes suggest?
Q5.A long, multi-step report-generation task frequently produces a subtly wrong result that isn't caught until the very end. Which lever from Task Statement 7.3 most directly addresses this?
Practice This Lesson