The most expensive AI failure I deal with rarely looks like a failure.

It arrives quickly. It is organized. It uses the right language. It ends with some version of:

Done.

Then I try to use it.

A requirement is missing. A source was never checked. The agent changed something outside the scope I gave it. The answer is plausible, but there is no evidence behind it.

Now I have a second job.

I reopen the files. Reconstruct the context. Find the gap. Explain the correction. Rerun the work. Review it again.

The model call may have cost a few cents. My attention cost much more.

I have learned to separate output latency from work latency.

Output latency ends when the model responds.

Work latency ends when I can accept the result.

The gap between those two is what I call The Rework Tax: every minute, rerun, review, and delayed decision caused by AI work that looked complete before it was usable.

If AI work comes back for correction, you did not save time. You financed a first draft.

That does not mean AI is not valuable. I use it constantly. It means "the model answered faster" is a weak productivity metric.

METR found a useful version of this gap in a May 2026 survey of 349 technical workers. The median respondent reported a 3x change in speed from AI, but only a 1.4x to 2x change in the value of their work, depending on how the question was asked. The researchers explicitly warned that self-reported speed likely overstates value.

That survey is not a causal productivity study, and it is not proof of any team's return. But the distinction is right: speed and value are not the same measurement.

The useful question is not, "How fast did AI produce something?"

It is, "How much total effort did it take to produce something we could accept?"

Context engineering, without the jargon

The name makes context engineering sound like a trick for fitting more information into a prompt.

That is too narrow.

For me, context engineering is designing the conditions around the model:

• what information it sees

• what sources it should trust

• what tools it can use

• what it may change

• how much risk the task carries

• what evidence must exist before the work counts as finished

• what happens when the evidence is missing

The model is one part of the system. The operating rules around it determine whether a fast answer becomes finished work or another review cycle.

This is why the same model can look brilliant in one workflow and strangely unreliable in another. In one system, it gets relevant context, bounded authority, the right tools, and a hard acceptance test. In the other, it gets a request and permission to declare victory.

Model intelligence matters.

The acceptance system matters too.

In my own agent setup, the recurring failure was partial completion: one command passed, one file existed, and the agent treated that local success as proof of the whole job. The output was real. The acceptance logic was weak.

A boring example that catches the real problem

The example I use in The Context Engineering Cookbook is intentionally unglamorous.

An AI agent needs to answer a refund-policy question from approved support documentation. It may search and read public docs. It may draft an answer. It may not issue a refund, change account state, or use private customer data.

The workflow has four requirements:

1. The delegation prompt names the exact outcome.

2. Tool access is limited to approved support-doc endpoints.

3. The workflow records evidence before closing the ticket.

4. No private customer data is included in the prompt.

The answer can sound perfect and still fail the fourth requirement.

Here is an excerpt from the actual output of the included finish check when evidence exists for only three requirements:

Goal Loop Finish Check
======================
Status: INCOMPLETE

PASS Delegation prompt names the exact outcome
PASS Tool access is limited to the support docs search endpoint
PASS Workflow records evidence before closing the ticket
MISSING No private customer data is included in the prompt

Next step: do not claim completion. Add evidence for every
missing requirement or explicitly change the goal with user approval.

That is a useful failure.

The checker does not claim private data leaked. It says the workflow has not proved that it did not. Instead of letting a persuasive answer cross the finish line, the system keeps the missing requirement visible.

You can apply the same idea without installing anything.

If you're trying to measure AI by accepted work instead of impressive demos, subscribe. I publish the systems and real artifacts behind that shift.

The Five-Check Acceptance Test

Take one recurring task your team already gives to AI. Before you automate more of it, run these five checks.

1. Is the handoff complete?

A useful handoff answers five questions:

• Task: What exact outcome must exist?

• Context: What should the model read, trust, ignore, or preserve?

• Authority: What may it change or decide without asking?

• Evidence: What proves the outcome exists?

• Escalation: When must it stop and involve a person?

If one is missing, the model has to guess. Sometimes it guesses well. Sometimes you discover the guess during review, when it is most expensive to unwind.

2. What context are you paying the model to carry?

More context is not automatically better context.

Every irrelevant file, stale instruction, noisy tool result, and unused tool schema competes with the information the task needs.

One sample in the Cookbook models an agent with eight MCP servers, nine tools per server, and an estimated 430 schema tokens per tool. That is 30,960 tokens loaded before the task begins, or 24.2% of a 128,000-token window.

After a task-scoped tool diet, the same planning example drops to 6,811 schema tokens, or 5.3% of the window.

Those numbers are estimates based on the supplied assumptions, not a universal benchmark. The operating question is what matters:

Why is the model seeing this before it starts the job?

If there is no good answer, remove it, retrieve it later, or process it outside the prompt.

3. Where is spend leaking before acceptance?

Most cost reviews stop at model price.

That misses four common levers:

• Compression: stop sending context the task does not need.

• Sandboxing: process large data outside the prompt and return only the useful result.

• Caching: reuse stable instructions and repeated context.

• Routing: reserve expensive models for work where the stakes justify them.

Then add the human cost most dashboards omit:

real cost = model spend + review time + rework time + failure impact

A cheap run that needs three corrections can cost more than a strong run that passes once.

4. Do the model, tools, and review match the stakes?

A reversible formatting cleanup and a payment-flow change should not receive the same model, authority, or evidence bar.

Score the task on five dimensions:

• ambiguity

• blast radius

• reversibility

• user impact

• evidence required

Low-risk work can use a cheap model or deterministic script. Medium-risk work can use a balanced model with focused verification. High-risk work should earn the strongest model, narrow authority, explicit evidence, and independent review.

Routing is risk management.

5. Does every requirement map to proof?

Write the requirements before the work starts.

When the result returns, attach proof to each one:

Requirement: Checkout error state is covered
Evidence: focused test command and passing output
Status: PASS

Requirement: Pricing behavior is unchanged
Evidence: none
Status: MISSING

One passing test does not prove every requirement. A clean summary does not prove the source was checked. A generated file does not prove the user can access it.

The acceptance rule is simple: a requirement with no evidence remains open.

Put a dollar value on the second pass

Here is an illustrative calculation. Replace every assumption with your own numbers.

Suppose a senior operator's loaded cost is $150 per hour. An apparently finished AI result takes 20 minutes to reopen, diagnose, correct, and re-review.

20 minutes × $150/hour = $50 of rework
$50 × 10 occurrences/week = $500/week
$500 × 52 weeks = $26,000/year

That is before the cost of a delayed decision, a customer-facing mistake, or another teammate being pulled into the correction.

Your number may be much lower. It may be higher. The point is to stop treating rework as invisible.

For one recurring workflow, track four things for a week:

1. First-pass acceptance rate: How often can the result be used without correction?

2. Rework minutes: How much human time passes between the first "done" and actual acceptance?

3. Evidence failure rate: How often does a requirement return without proof?

4. Escalation quality: Does the agent stop at a real boundary, or force a human to discover it later?

Those numbers tell you more than prompt count, token count, or raw response speed.

Why I turned the audit into code

I kept using versions of these rules in my own agent workflows. Eventually I stopped wanting another checklist I had to remember and turned the operating rules I use to delegate, route, and verify AI work into five dependency-free Node.js checks.

The current Cookbook package includes:

1. Delegation Stack Checker: catches incomplete handoffs across task, context, authority, evidence, and escalation.

2. Context Tax Calculator: estimates how much of the context window tool schemas consume before work starts.

3. Four-Lever Cost Stack Calculator: compares compression, sandboxing, caching, and routing as planning levers.

4. Stakes-Based Router: recommends a cheap, balanced, or frontier route from task risk.

5. Goal Loop Finish Check: blocks completion when a requirement has no evidence.

They run with Node.js 18 or newer and no external dependencies:

npm test
npm run demo:all

These are small reference implementations, not a complete production agent platform, security scanner, compliance system, or accounting model. They are designed to be understood in one sitting, copied, and adapted to the system around your agents.

You also get the worked support workflow, a field guide, readiness checklists, and the roadmap for the expanding book.

I share the checks, failures, and working systems behind serious AI adoption. Subscribe if you want the next build, not another AI trend recap.

The current early-access offer

You do not need the Cookbook to run the manual audit above. Pick one workflow and use the five checks today.

If you want the executable versions, The Context Engineering Cookbook ships now as an instant ZIP.

The early-access edition is $29 through July 31, 2026. The price increases to $49 on August 1 as the Cookbook expands. Buy once and every future Cookbook update is included, including additional patterns, expanded chapters, and the PDF when the complete edition stabilizes.

That is the honest reason for the lower early price: the five runnable patterns are useful now; the full publication is still growing.

Get the Context Engineering Cookbook for $29

If you're an existing or new annual or founding subscriber, you get access to the book and lifetime updates as part of your subscription. Learn how to access in your subscribers perks page.

My rule now is not to ask whether AI made the first draft faster.

I ask whether the work crossed the acceptance line with less total effort.

That is the difference between generating more output and reducing total work.

Share this with the person who owns AI productivity on your team. Then count corrections for seven days. The Rework Tax gets easier to fix as soon as it becomes visible.