Context Engineering Concepts › What goes into a request block 12 of 12 steps written
01 — part 1, conceptsconcept

What goes into a request block

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

Why the decision exists at all

A language model is stateless. Every request is independent of every other:

  • it retains nothing from previous requests
  • it cannot read your filesystem, database or source code
  • it knows nothing about your organization, product or customers

It receives one input — a single block of text — and returns one output. Your program constructs that input on every call. Nothing else does.

What the block is made of

sourcewhat it isdecided bydecided when
taskthe user's input, unmodifiedthe userat request time
carried contextmaterial attached to every requestyouat design time
fetched contextmaterial retrieved for this request onlyyour codeat request time
What the model will read one request, filling in the order your program fills it 1200 words — the hard edge the task the user's request, unmodified carried context attached to every request, by you fetched context looked up for this request only fills upward Nothing else builds this. There is no memory between calls and no filesystem the model can reach. Fetched context goes in last, so it is the first thing that does not fit.
One request, filling in the order your program fills it. The task, then whatever you carry, then whatever this request triggered a lookup for.
The order matters more than it looks. Fetched context arrives last, so when the block overflows it is the fetched material that is left outside — and step 3 is about what that costs.

When assembly becomes an engineering problem

Two conditions turn block assembly from string concatenation into a design decision. Either one is sufficient.

1. Your material exceeds the window. The block has a fixed maximum size. Once your material is larger than it, some of it cannot be sent and you must decide which.

The maximum is the context window. It is measured in tokens; this volume measures words, because every figure here is a comparison between two arrangements of the same pieces and the unit cancels.

2. Your material changes. A policy is revised, a runbook corrected, an API versioned. Any copy of that material embedded in a caller is now wrong, and nothing reports it.

Both failures are silent

The model does not report a missing document and it does not report a truncated block. It answers with what it received, in the same tone it would have used if it had everything.

That is the property that makes this a measurement problem rather than a debugging one. You cannot find these by watching for errors, because there are none. You find them by counting what went into the block.

The scale this volume works at

in the labs here
pieces of context6 per job
requests per job30
the window1200 words
arrangements triedall 64 — every way of carrying or fetching six pieces

Six pieces is small. It is enough to show the mechanism and, as step 12 says, not enough to say anything about sixty.

What to take from this step

  • The model is stateless; your program builds the entire input every time.
  • Three sources go into the block, and you decide two of them.
  • Both failure modes are silent, so the only way to see them is to count.