What is context engineering, and why does a PM care? It is the discipline of deciding which tokens reach the model on any given call: instructions, tool definitions, retrieved documents, conversation history, prior actions. Prompt engineering was about talking to one call. Context engineering is about building the system around it.

It is a product decision wearing engineering clothes. What enters the window determines what the product is capable of being right about, and that is a scope question before it is a retrieval question.

The constraint is attention, not window size

Every token in a context window competes with every other token. As the window fills, precision drops, reasoning weakens, and the model starts missing things it should catch. The research names the symptoms: lost in the middle, needle in a haystack.

Bigger windows reduce the pressure and do not remove it. A million tokens of available space is not an invitation to use a million tokens, and treating it as one produces a product that is confidently vague. Somebody still has to decide what goes in on every turn. That somebody is making a product decision about what the answer is allowed to be based on.

The 4 strategies, and where each one breaks

The discipline has settled into 4 moves that appear, named or not, in most production agent systems. Each has a failure mode, and the failure modes are more useful to know than the strategies.

Write. Store context outside the active window in scratchpads, memory files or running plans, so the model does not re-derive what it established 2 steps ago. Breaks when nothing prunes the store. A memory file that only grows becomes a junk drawer, and retrieving from a junk drawer is worse than retrieving from nothing because it looks like it worked.

Select. Retrieve only what this turn needs. Breaks in the way that matters most, because retrieval is confident about absence. When the right document is not fetched, the model does not say it lacked the document. It answers from what it has. You get a fluent answer built on a partial file and no signal that anything was missing.

Compress. Summarize history to buy room. Breaks on exceptions, and exceptions are the entire job in most B2B products. Summarization keeps what is typical and drops what is unusual, which is precisely backwards for a product whose value is handling the account that does not look like the others.

Isolate. Split the work across agents or sandboxes so each holds a smaller context. Breaks at the handoff, which is its own subject and the reason step-level tests pass pipelines that fail end to end. I went through that in Agent Teams for a Product Org.

Audit what your tools cost before a user says anything

Connect an agent to several MCP servers and the tool schemas alone consume a real share of the window before the first user message arrives. Most teams have never counted it.

Count it. It is a 20 minute exercise that occasionally explains months of unreliable behavior, and it reframes tool access as a budget rather than a feature list. Every connector you add is context you spend on every single call, whether the user needed that tool or not.

Context rot is now a line item

Monitoring products have started shipping specifically to show engineering leaders how their coding agents are performing across an organization. Vendors do not build monitoring for problems that are not costing anyone money. Context degradation moved from an academic curiosity to something teams track, and that transition is the clearest signal that this stopped being a research topic.

What the PM owns here

The budget, meaning which sources are allowed to spend window on every call and which have to earn their place per turn. The failure policy, meaning what the product does when retrieval comes back thin, because saying so is a design choice and most teams default to hiding it. And the pruning rule for anything written to memory, because nobody owns deletion by accident.

R&D owns the pipeline. The decision about what the product is allowed to be wrong about is not a pipeline decision, and handing it over is how you end up with a system that answers everything and can be trusted on nothing.

The sharpest published example of that budget being enforced rather than requested is Spotify routing bulk file reads away from the expensive model, which I looked at in The Cheapest Token Never Arrives.