Contextengineering

What context engineering is

Context engineering is deciding what goes into the model's context window on every call, and just as importantly what stays out. That covers the system prompt, the tool definitions, the documents a retriever pulled in, the conversation so far, the notes the agent left itself last time, and whatever the last tool call dumped on the floor. Anthropic's definition is the set of strategies for curating and maintaining the optimal set of tokens during inference, which is a longer way of saying the same thing.

Where the term came from

Tobi Lutke posted it in June 2025, saying he liked context engineering over prompt engineering because it describes the core skill better, which is the art of providing all the context for the task to be plausibly solvable by the LLM. Karpathy agreed a week later and listed what's actually in there, which is task descriptions and explanations, few shot examples, RAG, related data, tools, state and history, compacting, etc. Within a few months it was the word everybody used.

Why it needed a different name

Prompt engineering describes a person typing a request, and in an agent loop almost nothing the model reads was typed by a person. A tool returns 40,000 tokens of JSON, a retriever pastes in six chunks, the harness re-sends the whole conversation on every turn, a sub-agent hands back its findings, etc. None of that is a prompt, all of it is context, and all of it is competing for the same fixed space. We wrote almost none of it and we're paying for every token of it.

Use both kinds of search

Semantic search embeds the query and the chunks into vectors and returns what's closest in meaning, which is how you find the page about authentication when somebody asked about login. Lexical search, usually BM25, matches the actual words, which is how you find ERR_TOKEN_EXPIRED, a Jira key like PLAT-4412, a function name, a commit hash, etc. Embeddings are bad at exact identifiers and BM25 is bad at synonyms, so in an engineering corpus full of both prose and identifiers we want the two of them running together and their results merged.

Anthropic measured what each layer adds. Their baseline was a normal embedding retriever, and the failure rate is how often the right chunk wasn't in the top 20.

Give each chunk its context back

The other half of that result is what they called contextual retrieval. A chunk ripped out of the middle of a document loses everything the document was about, so a cheap model writes 50 to 100 tokens saying where this chunk sits, that gets prepended before the chunk is embedded and before it's indexed for BM25, and both retrievers get better. That's the step that takes failures from 5.7% to 3.7% on its own.

Where I'd start

If you're building an agent and you want to spend your time where it pays, this is the order I'd do it in.

Count what you're sending. Most of us have never measured a real turn. Run cl100k_base over your assembled context and find out how much of it is tool schemas and re-sent history, because it's usually more than you'd guess.

Cut the tools before you cut anything else. They're re-sent on every call, they're the cheapest thing to remove, and a smaller set makes the agent choose better as well as costing less.

Hand back identifiers, not contents. A tool that returns a file path and a line range costs 20 tokens. One that returns the file costs 3,000, and the agent only wanted to know where to look.

Run both retrievers and rerank. Contextual chunking, semantic and lexical together, then a reranker so you can keep three results instead of twenty. That's the 5.7% to 1.9% from section 05, and none of it needs a different model.

Compact deliberately. Decide what a summary must always preserve, which is usually the decisions, the constraints and the open questions, and write that rule down rather than letting a generic summarizer pick.

Then measure it again. ACE, Anthropic and Datadog all got their results by benchmarking against real labelled work rather than by reasoning about what should help.