AI-Native Series · Agent Engineering, Compared: Prompt · Context · Harness · Loop · Graph

Context Engineering Is a Budget, Not a Bigger Window

Episode 2 of 6. This series compares the ways people engineer AI agents — prompt, context, harness, loop and graph engineering, and the sixth rung this season argues for, evaluation engineering: where each came from, what it controls, who is driving it, and which principles survive measurement. This episode is the rung the popular four-label list skips, context engineering, and the two decisions a bigger window will never make for you.

By Paul Jialiang Wu · agentic-portfolio-lovat.vercel.app · 2026-09-11 · Episode 2 of 6

What this episode covers, and why context engineering comes second

There are five named disciplines for building AI agents with published landmarks, and a sixth this season argues for. They arrived in roughly this order: prompt engineering (2020), loop engineering (2022), graph engineering (2023), harness engineering (2024), context engineering (2025) — with evaluation engineering old as a practice and young as a name. The clearest published statement of the set is Feng et al.'s survey (arXiv:2608.21156), which orders them by what each lets you control rather than by age: prompt → context → harness → loop → graph. This series takes them one per episode, in that order, and asks the same four questions of each — where did it come from, what exactly do you control, who is driving it, and which failure pushes you up to the next rung.

Context engineering comes second because it is what rung one runs out of. Episode 1 ended with a perfect recipe card producing two different dishes, and the reason was not on the card. The moment your agent needs a fact that was not in the words you sent — a policy, a price, yesterday's decision, the last tool result — you are no longer editing a prompt. You are deciding what a scarce resource gets spent on.

Who this is for. An AI engineer whose agent is correct in the demo and expensive or wrong in week three. A founder looking at an inference bill that grew faster than usage. A high-school builder who wants to know why "just paste more into the prompt" stops working. The only prerequisite is having called a language model once.

Where context engineering came from, and who is driving it

[DEF] Context is everything the model can see at the moment it answers: the system prompt, the tool definitions, the conversation so far, whatever was retrieved, whatever a tool returned. Context engineering is the discipline of deciding what goes in there and what stays out. That is the whole definition. The history is how a retrieval trick became a budget.

[DESIGN] Three things to notice. The practice is five years older than the name: RAG in 2020 was already context engineering, it just did not know what to call itself. The two 2025 posts that named it were not papers but a CEO and a former lab director on social media, and the label stuck because the old label had been ruined by usage. And the sharpest results here are measurements that argue with the marketing: the same year vendors announced million-token windows, two independent groups published evidence that a longer window is not a uniformly usable one.

Who drives it now. Model labs write the guidance and own the caching behaviour you are optimizing against. Agent product teams — Manus is the clearest public example — publish the operational numbers, because they pay the bill at scale. Framework vendors turn the practices into defaults. Retrieval infrastructure companies fund the adversarial measurements, which is a healthy arrangement: the people selling retrieval have the strongest incentive to show that stuffing the window is not a substitute for it. Academia supplies one of the two load-bearing measurements — Liu et al., Stanford and Berkeley; the rest are industry, which is the honest shape of this rung.

The mental model for the series: the kitchen ladder

One picture carries all six episodes, so here it is again, stated as a tool rather than a story. Every cook climbs the same ladder: for yourself, then your family, then a restaurant kitchen, then a fast-food chain, then the national supply chain that feeds several chains — and above all of it, the recall log. Every AI engineer climbs a matching one, school learner to frontier leader, and each rung of agent engineering is one kitchen on that ladder.

Episode 1 was the recipe card: you write it, a cook you cannot talk to makes the dish, and everything has to fit on the card in advance. Rung two is the pantry and the counter. You are cooking for your family now, several times a week, from a kitchen that accumulates. The card still matters. But between Tuesday and Friday the pantry filled up, and the counter — the small flat surface where the cooking actually happens — is where every dish is won or lost.

The pantry is everything you own: shelves, freezer, the back of the fridge. The counter is what is out right now, in arm's reach, while you cook. They are not the same object, and confusing them is the entire episode. Nobody has ever improved a dinner by owning more jars. What decides dinner is what made it onto the counter — and whether any of it has gone off.

Two axes, not one. It is not a ladder you climb and leave behind: every kitchen has all six layers at once. A home cook has a card, a pantry, a stove, a taste, a supplier, and a memory of what went wrong last time. What changes as you climb is how many layers you are allowed to touch and how rigorously you run each one: by feel, then measured, then gated, then self-correcting. A national chain with a decorative supply-chain diagram and no expiry policy is less mature than one family kitchen that dates every jar. So the disciplines are layers (what you control); seniority is maturity (how you run them); and "graph" is not automatically more advanced than "loop".

The analogy is allowed to introduce a claim. It is never allowed to be the evidence for one — every element is pinned to one thing in code in the 1:1 technical map below. And one object from the end of Episode 1 is still here: the jar somebody left open next to the salt. Keep an eye on it. It is going to cost us real money in about nine hundred words.

The ladder is not mine

[DEF] The vocabulary, pinned to its source — because several labels compete for this territory and most listicles get the set wrong.

The clearest published statement of the ladder is Feng et al.'s survey (arXiv:2608.21156, revised 2026-08-26). It defines this rung in six words: "Context Engineering to manage information access" — sitting between prompt engineering, which elicits what the model already can do, and harness engineering, which organizes what it can reach.

The practitioner definitions arrived first. Shopify's Tobi Lütke, in June 2025, called it "the art of providing all the context for the task to be plausibly solvable by the LLM"; Andrej Karpathy amplified it days later as "the delicate art and science of filling the context window with just the right information for the next step". Both are quoted from Simon Willison's note of 2025-06-27, which is the artifact I read.

[DESIGN] Notice what all three have in common and what popular usage lost. Lütke says all the context; Karpathy says just the right information; Feng et al. say manage access. Not one says "more". The discipline was named as a curation problem and is routinely practised as an accumulation problem, and the gap between those readings is where most agent bills come from.

The claim, classed

[DEF] Context is a budget, not a container. A budget has three properties a container does not: it is finite, it is spent, and what you spend it on is a choice you make every turn. It also has a layout — because in this budget, where a token sits changes what it costs and how well it is read.

[EVIDENCE] Take position first, because it is the oldest and most measured part of the claim. Liu et al. put the same information in different places inside the window and looked at accuracy:

"performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle of long contexts, even for explicitly long-context models"
— Liu et al., Lost in the Middle, arXiv:2307.03172

The last clause is the one to sit with: even for explicitly long-context models. A longer window does not repair this, because it is a claim about the shape of attention across a window rather than about its size. (The paper appeared at TACL in 2024; I diffed the published abstract against the arXiv one and they are word-for-word identical.)

[EVIDENCE] Chroma's 2025 technical report pushes the same knife in from the other side. Where Lost in the Middle varied position, Chroma varied length and held difficulty constant: "Each task remains intentionally simple and is deliberately controlled to isolate the impact of context length alone." Across 18 models the summary is blunt — "models do not use their context uniformly; instead, their performance grows increasingly unreliable as input length grows." Anthropic adopted the term in its own engineering post and drew the conclusion this episode is named after: "Context is a critical but finite resource for AI agents."

[EVIDENCE] Now the money, the half that gets less attention and lands on you monthly. An agent loop re-sends its entire history every turn, so the input-to-output ratio is nothing like a chatbot's — Manus reports theirs around 100:1. One number then dominates the bill:

"If I had to choose just one metric, I'd argue that the KV-cache hit rate is the single most important metric for a production-stage AI agent."
— Yichao "Peak" Ji, Manus, 2025-07-18

And the way that metric is destroyed is so small it looks like a nicety: "A common mistake is including a timestamp—especially one precise to the second—at the beginning of the system prompt." The cache is a prefix cache. It is reused for the longest run of tokens your request shares with the last one, from the front. Change one token at position twelve and everything after position twelve is prefilled again, for every turn that follows, forever.

[DERIVATION] Put the three together and the rule is not "keep your context small". It is sharper than that, and it is two rules:

• Layout is a cost decision. Anything that changes between turns belongs at the end of the context, never in the prefix. Position is not cosmetic; it is priced.
• Freshness is a correctness decision. A fact that cannot be dated cannot be refused. If your memory store has no expiry or supersession field, no amount of retrieval quality can stop a retired policy from being cited, because staleness is not a property your retriever can see.

[DESIGN] The vendor claim deserves a fair hearing rather than a sneer. The long-context announcements are true, and for single-shot tasks — read this contract, answer this question — a million tokens is a genuine capability that did not exist in 2023. What does not follow is the inference everyone draws: that curation is now optional. Chroma tested exactly that inference under controlled conditions and found it false even for simple tasks. And the bill is untouched either way — a bigger window makes an uncurated context cheaper by exactly zero.

[OPEN] Two honest limits. Both measurements are about retrieval-shaped tasks; neither establishes that curation always beats stuffing for reasoning-shaped ones. And the cache economics are provider-specific — the 10× gap between cached and uncached input that Manus quotes for one model family is a list price at one point in time, not a law of nature. Re-derive it for your own provider before you quote my arithmetic.

1:1 technical map

Every element of the metaphor maps to exactly one thing you can point at in code. A metaphor may introduce a claim. It may never evidence one — so here is the translation, with nothing left decorative.

[DEF] The three numbers the rest of this episode leans on, defined once:

• Prefix-cache hit rate — over a run, the fraction of input tokens served from cache rather than prefilled. Nothing about quality. Purely: how much of what you sent did you already pay for.
• Stale-fact leakage rate — over N answers, the fraction that use at least one fact that had already expired or been superseded. Nothing about fluency. The answer can be beautiful and cite a retired clause.
• Budget overflow — over N assemblies, the count that exceed the declared token budget. Not "degraded": a context over budget is truncated by someone other than you, from whichever end the provider prefers.

Prediction Gate

Before you scroll, commit. Write your answer down — the point of this device is that a prediction you did not record is a prediction you will believe you got right.

Q1. An agent runs 100 turns. Its system prompt begins with the current time, precise to the second. Everything else is append-only. What fraction of its input tokens will be served from the prefix cache?

Q2. You move that one line from the top of the system prompt to the last line before the model answers. Same tokens, same information. What happens to the hit rate, and what happens to the bill?

Q3. Your memory store has no expiry stamps and roughly a quarter of it is out of date. You want to reduce how often answers use stale facts. Rank these by effect, most first: (a) double the context budget, (b) improve the retriever's ranking, (c) add an expiry field and filter on it before scoring.

Answers are in the Failure Room and the Notebook. If your instinct on Q3 was (b), you are in good company and the sweep in cell 6 is going to be worth your fifteen minutes.

Failure Room

Break it deliberately. A mechanism you cannot break is a claim, not a mechanism.

Failure 1 — "the window is a million tokens now, so this is solved." The most common belief on this rung and the one with the most published counter-evidence. Chroma held difficulty constant and varied only input length across 18 models; performance still degraded. Liu et al. held length constant and varied only position; accuracy still moved, explicitly including long-context models. A bigger counter is genuinely useful and changes neither result — and it does nothing at all to the two numbers this episode measures.

Failure 2 — "we have caching enabled, so we're fine." Caching is not a checkbox, it is a prefix property, and it is destroyed by things that look like good engineering. A timestamp so the model knows the time. A session id for tracing. A "user tier: pro" line so the persona adapts. A tool list rebuilt in a different order because your JSON serializer does not guarantee key ordering. Each is one token, at the front, and each costs you every token after it. In the lab below that mistake takes the hit rate to 0.003 — and nothing errors, nothing warns, and the dashboard that would have caught it is the one nobody built.

Failure 3 — "retrieve better." The trap the sweep exists to spring. Better ranking moves which stale items arrive first; it does not stop them arriving, because staleness is invisible to a ranker that cannot see a date. In the lab, leakage without expiry stamps sits between 0.690 and 0.910 across every counter size from 4 to 50 and never once reaches zero; with stamps it is 0.000 at every one. That is not a better retriever — it is a different question, asked before the retriever runs.

Failure 4 — the metric that reads 0.000 and means nothing. Drive leakage to zero by putting almost nothing in context. Congratulations: your agent is reliably uninformed. Same shape as Episode 1's determinism metric reading 1.000 on an empty object, and it is why the fridge-list project reports how many ingredients the plan actually named beside the leakage rate. A curation metric with no usefulness metric next to it is an invitation to cheat.

Answer to Q3: (c), then (b), then (a) — and (a) is not merely last, it is arguably the wrong sign. Raising the budget from k=4 to k=20 took the mean number of expired items on the counter from 1.08 to 9.25 — and even one doubling, k=4 to k=8, took it from 1.08 to 2.90. You did not dilute the problem. You invited more of it in.

Notebook

Lab 02 — Prefix stability and the budget.

labs/02_context_budget.ipynb · Colab free tier · no API key · ~2 seconds of CPU · every cell executed before publication · the gist also carries both projects.

Seven cells, two halves. First: a stub tokenizer (one token per four characters) plus the only cache model that matters — the KV cache is reused for the longest common prefix between this request and the last. Second: a pantry file, an assembler and a leakage metric.

1. The tokenizer and the prefix-cache model, with the published list prices used as a cost model.
2. The agent's context, assembled two ways — a clock at the top of the system prompt, or the same clock as the last line before the answer.
3. The measurement over N=100 turns. Read the token column first: it is identical for both arrangements.
4. The pantry: 40 items, 11 of them already expired, each with an added date and optionally an expires date.
5. The assembler and the leakage metric, at a counter size of 12.
6. The sweep, and the cell worth stealing. Vary the counter size and watch the two interventions come apart.
7. The bridge: replace two functions and the identical measurement runs against a real endpoint.

[EVIDENCE] Cell 3, exactly as the run printed it:

arrangement                        input tok    cached  hit rate   cost USD
volatile field at the TOP            252,064       693     0.003     0.7543
volatile field at the END            252,064   246,396     0.978     0.0909

cost ratio (top / end)          : 8.30x
cost delta over 100 turns       : $0.6634

Same tokens. Same information available at the moment the model answers. One line moved from front to back, and 8.30× of the input bill evaporates. Notice what did not happen: no error, no warning, no degraded output. The expensive version works perfectly — which is precisely why it survives code review.

[EVIDENCE] Cell 6 is the one that changed my mind while I was writing the outline, and the verdict is computed at runtime rather than asserted in advance so that it could contradict me — which it did, in a way I nearly deleted:

[OPEN] The honest reading of that table, including the part that argues against me. Leakage without stamps is not monotone in k: it rises to 0.910 at k=20 and falls back to 0.690 at k=50. My first instinct was to cut the last two rows, and cutting them would have been trimming toward my thesis. The cause: the pantry holds 40 items, 11 expired, so by k=32 every expired item is already on the counter — the fourth column pins at 11.00 — and raising k further adds only fresh items while the stub cook still names a fixed four. The per-answer rate dilutes while the counter's contamination is complete. That is an artifact of the stub, and it is worth saying out loud, because it is the exact shape of a real reporting error: a rate can improve while the underlying state gets strictly worse. The claim that survives is the one the whole column supports — without stamps, leakage never reaches zero at any budget; with stamps it is 0.000 at every one.

[DESIGN] Why a stub. A simulator reproduces where a cost enters and what removes it, in two seconds, free, with no key. It does not reproduce magnitudes. Nothing the notebook prints is evidence for Liu et al.'s position effect or Chroma's degradation curves; only those sources can be cited for those. The 8.30× is arithmetic over stub tokens with published list prices applied — the ratio is the finding, the dollars are an illustration. Cell 7 is the honest bridge: swap the tokenizer and the stub cook, and the measurement code does not change.

Projects

Two builds, from nothing — no frameworks, no dependencies beyond the standard library. Both were run before this section was written, so every number below is measured rather than predicted.

Project 1 — real life: the-fridge-list

projects/02-real-fridge-list/ · python3 fridge_list.py 100

A family meal planner whose entire context is one file, pantry.json. It reads the pantry, puts twelve items on the counter, and writes the week's dinners from whatever it can see. Nobody puts expiry dates in a text file they wrote for themselves, which is exactly why it is the right first build. A different pantry file and a different stub cook from the lab's — same shape, so the rate is not the lab's 0.880.

pantry: 40 items, 11 already expired on 2026-09-11 · N=100 weekly plans · k=12

pantry file                   leakage rate   stale items named   of items named
WITHOUT expiry stamps                0.750                 134              242
WITH expiry stamps                   0.000                   0              372

[EVIDENCE] Three quarters of the plans tell the family to cook with something already off, and the plans are fluent, sensible and wrong. The number I did not expect is the last one: with stamps the planner names more ingredients — 372 against 242 — not fewer.

That inverts the intuition that makes people skip this work. Filtering did not shrink the counter; the counter is twelve items either way. It replaced twelve slots of which five were unusable with twelve that all are, so more meals became plannable. Curation is not subtraction. It is the same budget spent on things that work — Anthropic's high-signal-tokens argument, arriving here from a fridge.

Project 2 — enterprise: the-desk-memory

projects/02-enterprise-desk-memory/ · make measure · make gate

A support-desk context assembler. Ticket in, assembled context out, with a token budget and three invariants gated in CI. The knowledge base is 144 snippets — versioned policy clauses, past resolutions, and dated seasonal notes — of which 30 are stale: 16 superseded policy versions and 14 expired notes.

[EVIDENCE] One invariant removed at a time, N=100 tickets each:

what was removed          budget_overflows   stale_fact_leaks   distinct prefixes   exit
nothing                                  0                  0                   1      0
the budget packer                      100                  0                   1      1
the freshness filter                     0                100                   1      1
the stable prefix                        0                  0                 100      1

make gate exits 0. make gate-off — the same gate with the freshness filter deleted — exits 1. make gate-removed removes each invariant in turn and asserts that each removal fails, because a gate you have never watched fail is a hope rather than a gate.

Read the second row closely, because it is the one that will happen to you. Removing the budget packer raises no error anywhere: it assembles 1,420 tokens on average and 1,481 at worst for a 1,200-token counter and hands them over, and a real provider truncates — silently, from whichever end it prefers — so the fact you most needed is the one that fell off. And here is our jar. The third row is a superseded refund clause sitting on the counter, cited in a hundred replies out of a hundred. It looked exactly like a policy. It was a policy, in March.

Build it in 30 minutes — the contract

Everything the assembler needs, in the order an engineer will ask for it. Inputs: a ticket and a knowledge base. Output: one assembled context. Invariant: nothing enters that cannot be dated, and nothing is packed that does not fit. Stop rule: at the budget, stop — never truncate the prefix to make room.

PINNED_PREFIX = system_prompt + tool_schemas   # byte-identical on EVERY request:
                                               # no clock, no session id, sorted keys
SNIPPET = {                                    # the minimal shape of a memory row
  "id":            str,
  "text":          str,
  "expires":       date | None,                # the field that makes refusal possible
  "superseded_by": id   | None,
}
def assemble(ticket, kb, budget=MAX_CONTEXT_TOKENS):
    pool   = [s for s in kb if is_fresh(s)]           # 1. FILTER — before anything else
    ranked = sorted(pool, key=lambda s: -score(s, ticket))   # 2. SCORE
    out, used = [], n_tokens(PINNED_PREFIX)
    for s in ranked:                                  # 3. PACK, newest-relevant first
        if used + n_tokens(s.text) > budget: continue
        out.append(s); used += n_tokens(s.text)
    return PINNED_PREFIX, out, used

# CI gate (make gate): N=100 tickets
#   budget_overflows             == 0
#   stale_fact_leaks             == 0
#   distinct_prefix_fingerprints == 1     (sha256 of the pinned prefix, per request)
# any line off threshold → exit 1 → the build fails

Deliberately missing from that block: an answer-correctness metric (the honest gap, below), reranking (it moves the order, not the eligibility), and a live model.

[DESIGN] Four properties make this enterprise-shaped rather than a demo, and each earns its place:

• Filter before score, not after. A stale clause removed after packing has already displaced a fresh one that would have fitted. This is the same shape as Episode 1's plan gate, which validates before any tool runs rather than after — filtering afterwards only tidies the log.
• The prefix is fingerprinted, not merely intended. The gate hashes the pinned prefix on every request and requires exactly one distinct value across all 100. "We keep the prefix stable" is a belief; a sha256 over N=100 is a fact, and it is the only version that survives the next person who adds a helpful timestamp.
• Supersession is a first-class field, not a convention. superseded_by retires a row without deleting it, so an audit can still read what the desk was told in March while the assembler refuses to serve it today. Deleting the row destroys the audit; leaving it undated destroys the answer.
• Overflow is a build failure, not a warning. The provider "handles" an over-budget context by truncating it — a decision about which fact your customer loses, made by an API, silently. Gating it at zero moves that decision back to you.

[OPEN] What neither project proves. Both corpora are synthetic and both cooks are stubs. The enterprise build's honest status is runnable and gated, not deployed and measured. What would make it real: a knowledge base sampled from an actual desk with its real supersession history, and an answer-correctness metric reported beside the three invariants — because a context that is fresh, small and stable can still be the wrong context, and none of these three numbers would notice.

Same story, five exits

One spine, then a door for each reader. Take one decision and one action; leave the rest.

Reality Mission

Fifteen minutes, on something you already run this week.

1. Print the exact bytes you send on two consecutive turns of one real agent — not what you think you send, what goes over the wire.
2. Diff them. Find the first byte that differs. Everything from there on is being prefilled again, every turn, forever.
3. If that byte is a clock, an id, a tier, a randomized tool order or a formatted date, move it to the end of the context. Nothing else changes.
4. Open your memory store and ask one question of the schema: can I tell, from a row alone, whether it is still true? If the answer is no, you do not have a retrieval problem, you have a missing column.
5. Add the column. Filter on it before you score. Re-run whatever you used to trust.

If step 2 turns up nothing because your agent sends a fresh single-shot prompt each time, you have learned something more useful: you are still on rung one and the counter has not started filling up. It will.

Research Challenge

Hand this to an agent and pre-register the prediction before it runs — a result you did not predict is a result you will rationalise.

Take one retrieval-shaped task with a checkable answer and a corpus in which a known fraction of rows is superseded. Hold the model and the task fixed. Vary two things independently: the context budget (four settings, from tight to 10× the needed size) and the freshness policy (none · filter-on-expiry · filter plus recency-weighted rerank). Report answer accuracy, stale-fact leakage, prefix-cache hit rate and cost for all twelve cells, and report leakage per answer and contamination per context separately.

Pre-register: whether accuracy is monotone in budget, and whether the two leakage measures ever move in opposite directions.

My own stub says those two measures do come apart at large budgets, for a reason that is an artifact of the stub. Whether they come apart on a real model, for a real reason, is the part nobody has published — and if they do, you have a result worth writing up rather than a bug in your setup.

What moved

State of this rung at press time. Generated from a live weekly feed sync across 30 pioneer sources in research-anything (make watch-sync), ranked by technical signal and never by audience reach.

Sync date: 2026-09-11.

• arXiv:2609.11728 (2026-09-10) — Reproducibility in the Age of Agentic AI: Context Engineering at the Timescale of a Codebase. One day old at press time: reproducible-research practice — tests, commit history, repository structure, decision records — read as context engineering for coding agents, with the author insisting researchers stay responsible for verifying the artifacts.
• arXiv:2608.23992 (2026-08-25) — Hybrid Semantic Tool Discovery for Enterprise MCP Gateway. The production number this episode would have loved to have measured itself: at PayPal, exposing 2,000+ tools across 200+ servers consumed 140.2k tokens, 70.1% of the context window, before the user's question arrived. Replacing the dump with two search tools took it to 1.3k tokens, 0.8%. The paper's own framing is a context-engineering bottleneck, not a retrieval one.
• arXiv:2608.29016 (2026-08-29) — Towards Fully Automated Medical Imaging Code Generation via Validation-based Context Engineering. Context assembled from domain knowledge bases, shared memory and validation feedback rather than by hand, across six datasets and five backbone models. The direction of travel: context construction is becoming a component with its own tests.
• Older but load-bearing: arXiv:2005.11401 (RAG), arXiv:2307.03172 (Lost in the Middle), arXiv:2310.08560 (MemGPT), and the 2025 practitioner canon — LangChain's four buckets, Chroma's Context Rot, Manus's cache-rate post, Anthropic's engineering post.

[OPEN] What has not moved. I looked for a 2026 replication of Chroma's degradation curves on current long-context models and did not find one: the strongest public evidence for context rot is still a vendor-run report from July 2025 and a 2023 paper, neither independently repeated on 2026 models. Treat the size of the effect as unsettled and the direction as well supported. I also found no controlled public measurement of prefix-cache hit rate across providers — the 10× cached-versus-uncached gap everyone quotes traces to one vendor's list price at one moment.

Exit test

Check yourself without scrolling up.

1. What is the difference between the pantry and the counter, and which one does a bigger context window enlarge?
2. Why does a timestamp at the top of a system prompt cost more than the same timestamp at the end, given that both are the same number of tokens?
3. Name the two measurements that argue against "a million-token window solves retrieval", and say what each one held constant.
4. A retriever is excellent and the memory store has no expiry field. Explain, in one sentence, why leakage cannot reach zero.
5. Your stale-fact leakage reads 0.000. Give the cheapest way that number could be a lie, and the one metric you must report beside it.

Cliffhanger

You fix the counter.

Every volatile field moved to the end; the prefix hashes to one value across a hundred requests. Every row carries an expiry and a supersession pointer, and the assembler refuses anything it cannot date. Budget declared, overflow gated at zero. Cache hit rate 0.978, leakage 0.000, and for one afternoon you believe you have solved the kitchen.

Then a customer writes in. Your agent reads the ticket, retrieves exactly the right clause of exactly the current policy, and composes a reply correct in every particular.

And then it issues the refund.

Twice, because the first call timed out and nothing told it that a refund is not the kind of thing you retry. For an amount above the desk limit, because nobody had written the desk limit down where the agent could read it. And it wrote to the ticket system and the billing system in an order that left the two disagreeing — and when you ask for the undo, there isn't one.

The counter was clean. The facts were fresh. Nobody had decided what the cook was allowed to touch.

Episode 3 — The Restaurant Kitchen. Harness engineering: the model sees the right facts and still cannot act — and the measurement that found a first-pass harness making things worse in two of four cells.

Read next

• Prompt Engineering Is a Specification, Not a Spell — Season 7, episode 1 — the rung below this one, and the one free-text step that took determinism from 0.51 to 1.00
• The Order Ticket — Season 6, episode 1 — the same territory argued rather than built, and the season that found the nest diagram does not survive contact
• The Governor — Season 6, episode 3 — why none of these labels can express stability, and the 1877 criterion that could

Episode 2 of Intelligence Engineering Adventures, Season 7 — The Kitchen Ladder. Claims in the series source are tagged by class — definition, derivation, evidence, engineering choice, open question — and a metaphor may introduce a claim but never serves as evidence for it. Every episode ships a Colab notebook that runs on the free tier with no API key, plus two applications built from nothing — one personal, one enterprise-shaped. The ladder is Feng et al.'s (arXiv:2608.21156), not mine. The "what moved" section is generated from a live weekly feed sync of 30 pioneer sources, ranked by technical signal and never by audience reach. This article contains no material from any employer or client. — Paul Jialiang Wu · agentic-portfolio-lovat.vercel.app

References

1. Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., Liang, P. (2023). Lost in the Middle: How Language Models Use Long Contexts. arXiv:2307.03172 — abstract page read 2026-09-11; the position sentence is quoted verbatim from it. Published as TACL 12 (2024); I diffed the two abstracts and they are identical, so the quotation holds for either version.
2. Ji, Y. ("Peak") (2025-07-18). Context Engineering for AI Agents: Lessons from Building Manus. manus.im/blog — read in full 2026-09-11; source of the KV-cache-hit-rate quotation, the timestamp-in-the-prefix quotation, the 100:1 input-to-output ratio, and the cached/uncached list prices used as the lab's cost model.
3. Anthropic (2025-09-29). Effective context engineering for AI agents. anthropic.com/engineering — read 2026-09-11; source of the finite-resource quotation and of the attention-budget framing described in the history table.
4. Hong, K., Troynikov, A., Huber, J. (2025-07-14). Context Rot: How Increasing Input Tokens Impacts LLM Performance. Chroma technical report, research.trychroma.com/context-rot — read 2026-09-11; 18 models, task complexity held constant, input length varied.
5. Feng, Y., Xiang, Z., Yang, C., Ma, Q. (2026). Graph Engineering in the Era of LLM Agents: From Individual Intelligence to System Intelligence. arXiv:2608.21156v2, revised 2026-08-26 — the series' ladder; "Context Engineering to manage information access" quoted from the abstract page.
6. Lewis, P., Perez, E., Piktus, A. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. arXiv:2005.11401 (NeurIPS 2020) — the 2020 landmark in the history table; abstract page read, not quoted.
7. Packer, C., Wooders, S., Lin, K. et al. (2023). MemGPT: Towards LLMs as Operating Systems. arXiv:2310.08560 — virtual context management; abstract page read, not quoted.
8. Willison, S. (2025-06-27). Context engineering. simonwillison.net — the artifact I read for both June-2025 posts. Originals: Tobi Lütke and Andrej Karpathy; both render client-side, so the quotations here are taken from Willison's transcription and attributed accordingly.
9. The LangChain Team (2025-07-02). Context Engineering. langchain.com/blog — the write / select / compress / isolate taxonomy; read 2026-09-11, described not quoted.
10. Barba, L. A. (2026-09-10). Reproducibility in the Age of Agentic AI: Context Engineering at the Timescale of a Codebase. arXiv:2609.11728 — "what moved"; abstract page read 2026-09-11.
11. Saha, O. et al. (2026-08-25). Hybrid Semantic Tool Discovery for Enterprise MCP Gateway: Architecture and Implementation. arXiv:2608.23992 — "what moved"; the 140.2k → 1.3k token figures are from the abstract page, read 2026-09-11.
12. Zhao, Z. et al. (2026-08-29). Towards Fully Automated Medical Imaging Code Generation via Validation-based Context Engineering. arXiv:2608.29016 — "what moved"; abstract page read 2026-09-11.
13. Dhage, S. (2026). Harness Engineering for Predictable Agentic Systems: An Empirical Study of Deterministic Execution Constraints. arXiv:2608.26197 — Episode 1's measurement, referenced here for the plan-gate shape and previewed for Episode 3.
14. Anthropic (2024-12-19). Building Effective AI Agents. anthropic.com/engineering — harness-engineering landmark in the series table.
15. Lab and projects for this episode, every cell executed before publication: gist.github.com/wjlgatech/47eb7973aa5e292524c9c205c73c34d9 — 02_context_budget.ipynb, the-fridge-list, the-desk-memory.
16. Intelligence Engineering Adventures, Season 7, Episode 1 — Prompt Engineering Is a Specification, Not a Spell, for the recipe card, the plan gate and the determinism metrics this episode builds on.