Deciding what travels with every request, and what gets looked up

Twelve steps, four parts, three runnable labs — sixty-four arrangements each.

Introduction

You have five or ten pieces of context — a style guide, a runbook, an API reference, an escalation policy — and no principle for which of them travel with every request and which get looked up. So they all travel, or none do, and both are wrong.

Why this is not a prompt problem

A language model is stateless. It retains nothing between calls, cannot read your filesystem, and knows nothing about your product. It receives one block of text and returns one block of text, and your program builds that whole input on every call.

So the question is not how to word the instruction. It is which of your material is in the block at all — and that is a design decision made per piece, not a setting.

What context engineering is

Context engineering is the practice of deciding, deliberately and measurably, what text goes into each model request.

Every piece of context has exactly one placement. It is carried — attached to every request whether or not this one needs it — or it is fetched, looked up on the requests where something triggers it. There is no third option, and the two fail in opposite directions.

placement	in the block	how it fails
carried	every request	waste — paid for on requests that did not need it
fetched	only when its trigger fires	absence — needed on a request the trigger missed, and nothing reports it

Those two failures are the whole subject. Reduce one and you increase the other, which is why neither “carry less” nor “fetch more” is a strategy.

Is this for you?

It depends on how much material you have and how unevenly it is needed.

if…	then
everything you have fits in the window with room to spare	carry it all and stop — you do not need this volume
one piece is a large share of everything you have	you have a real decision, and step 9 is the one to read
some material is needed rarely and is expensive to be without	you have a real decision, and step 10 is the one to read
you cannot say which of your pieces are reliably fetchable	start at step 5 — on one job here that single property decides everything

What you will get

A procedure of eight questions with a real exit at the third, a one-line rule you can apply without running anything, and the boundary where that rule stops working. Three runnable labs carry it: thirty turns each, six pieces of context each, and all sixty-four ways of arranging those pieces run in full — so the best arrangement here was found rather than argued for.

Two of the three jobs let you carry everything and stop. That is a real exit and the pages say so, with the premium priced rather than described. If your whole bill is small, question three is where you should leave.

How to read the source labels

Every step is labeled with where its content comes from, so you always know whether you are being told something or shown a measurement.

label	means
concept	argued from first principles, quotes nothing from a lab
measured	a lab compares arrangements and reports the difference
hands-on	you run it on your own material

Nothing here is a benchmark. Three jobs, thirty turns, six pieces, a scripted agent, and prices that are a plausible shape rather than a quotation. Step 12 lists every limit, beginning with the one that would move every conclusion in the volume.

Build state: 12 of 12 steps written. The table of contents marks which.

Part 1 — Concepts

01What goes into a request blockThe model is stateless. Your program builds the whole input, from three sources, on every single call.concept

02The context layerOne assembly point and one manifest. Without them, three failures are invisible rather than merely likely.concept

03Carried vs. fetched contextEvery piece has exactly one placement, the two failures oppose each other, and fetched content is dropped first.concept

Part 2 — Method

04Size, need rate, and triggerabilityThree properties per piece. The one that decides is not the one you would sort by.measured

05Triggers and their failure modesA trigger that misses produces a wrong answer and no error. On one job the pieces worth carrying are *exactly* the ones no trigger can find.measured

06Waste, absence, and the price of being wrongTwo counts that move in opposite directions, plus one price no measurement can supply.measured

07The eight-question procedureEight questions in fixed order, with a real exit at the third.concept

Part 3 — Evidence

08Job A: everything fits in the windowFitting is not the same as free. Carrying all six ranks 8th of 64 and the winner is the three pieces no trigger can find.measured

09Job B: one oversized pieceThe piece needed most often is the one you must not carry — and carrying a fourth small piece makes the agent sharply worse.measured

10Job C: expensive mistakesA rule needed on two turns in thirty belongs in the pile all thirty times.measured

Part 4 — Result

11The break-even ruleOne line you can apply on a whiteboard, which picks the winner on all three jobs — and stops working the moment your pieces stop fitting comfortably.measured

12Limits, and your own contextWhat is not measured here, starting with the one that would move every conclusion.hands-on