Context engineering

The context is everything the model can see on one call. In the loop from the first guide, that is the whole messages list: your instructions, the question, every earlier model reply, and every tool result so far.

There are two things to keep in mind about it.

• It has a size limit. Models read a fixed amount of text per call, measured in tokens. A token is a small chunk of text, roughly three-quarters of a word. Tasks here also carry their own token budget, which is smaller than the model's raw limit.
• It is all treated as input. The model does not label some lines "important" and others "background". It reads the whole list and writes the most sensible continuation. Anything in there can influence the answer.

If a tool result says the refund window is 14 days, then as far as the model is concerned, the refund window is 14 days. It has no way to check. It does not know that the line came from a page nobody has updated in three years.

This makes the harness responsible for something that sounds like editing. You decide which pieces of evidence the model is shown. Showing it a wrong or misleading line is, in effect, telling it that line is true.

Most context problems fall into a few shapes.

• Noise. Lots of irrelevant text surrounds the one useful line. The model may miss it, or give it the same weight as everything else.
• Stale evidence. An old document, an out-of-date example, or a draft says something different from the real source.
• Conflicts. Two lines in the list disagree. The model has to pick one, and it may not pick the one you would.
• Bloat. The list simply grows. Earlier results pile up, the budget shrinks, and the useful parts get buried.

Here is a concrete example. A support assistant searches a knowledge base for the refund policy. The search returns three hits.

1policy/current.md:12    Refunds are accepted within 30 days of delivery.2drafts/old-policy.md:8  Refunds are accepted within 14 days of delivery.3blog/launch-post.md:41  "Refunds within 14 days, no questions asked!"

One of those three is the source of truth. If the harness appends all of them, the model sees two votes for 14 days and one for 30. Even a good model can be pulled the wrong way, and a tidy-sounding line in the draft makes it more likely.

The first thing many people try is to add a sentence to the instructions: "Only trust the current policy. Ignore old drafts."

It helps a little and it is not reliable, for three reasons.

• The model has to work out which hit is the draft, and it may not be able to tell.
• The misleading line is still in the list. It still pulls on the answer, and a reminder does not take it out.
• It is hard to know it worked. It may pass on the questions you tried and quietly fail on ones you have not seen.

When the wrong evidence is already in the list, no sentence can remove it. The reliable fix is to make sure it never gets in, which means changing what the harness does, not what it says.

You have three places to intervene, and the earlier you act, the better it works.

Before the tool runs

Narrow the request. If you know the answer lives in the policy folder, search there and nowhere else. A tool call with a tighter scope returns fewer lines, so there is less to filter. Many tools take a path, a filter, or a limit. Use them.

After the tool runs, before you append

This is the most powerful spot. The result is sitting in a Python variable and nothing has been added to the list yet. You can inspect it, drop the lines that cannot be the answer, shorten the rest, and only then append what is left.

1def keep_authoritative(result: str) -> str:2    """Drop search hits that come from places that are never the source of truth."""3    kept = [4        line for line in result.splitlines()5        if not line.startswith(("drafts/", "blog/"))6    ]7    return "\n".join(kept) or "No matching lines in the policy folder."

Rules like this are ordinary code, and they are exact. They do not rely on the model working something out, and they behave the same on a question you have not seen.

Between steps

On long runs, look at the whole list now and then. Large old results that no longer matter can be cut or replaced with a one-line note. Keep the original instructions and the question. Keep the evidence the answer rests on. Throw away the rest.

Filtering only works if you can answer a question first: where is the truth? Before writing any rule, decide which sources are authoritative and which are not.

• The real implementation outranks documentation about it.
• Current files outrank drafts, examples, and archives.
• A system's own configuration outranks someone's description of it.
• Tests and docs are full of the same names as real code, attached to different values, on purpose.

Look at the paths in a result. A path is often the cheapest and most reliable signal you have about whether a line is worth showing.

Sometimes the right move is to shrink the history by summarizing it. That is fine, but a summary that says "the refund window is 14 days" has lost the information about where that came from. Write it so the model can still tell a verified fact from a guess: "From policy/current.md: 30 days." A claim without a source is hard to trust and impossible to check.

When an answer is wrong and the right information is somewhere in the run, do this.

1. Find the call where the model produced the wrong answer.
2. Open exactly the list it was sent on that call.
3. Find the line the answer came from. Where did it come from, and is that a place you trust?
4. Work back to the step that put that line there.
5. Change the harness at that step so the line is never added.

Notice that none of those steps involve rewording the prompt. They are about what the list contained.

Problems 04 and 05 are context problems. In 04 nothing is wrong with the data: every record the model reads is useful once and then sits in the list, paid for again on every call, until the budget runs out. Your code has to shrink what the model has finished with. In 05 a search returns real hits mixed with look-alikes from other places, and one wrong line left in the list can decide the answer. As you work on it, keep asking: which lines are in the list at the moment the model answers, and which of those would you not want it to believe?