Context Engineering for PMs: The Skill After Prompt Engineering
Prompt engineering tunes one request. Context engineering curates everything the model sees: workspaces, memory, agent files. What to put in, what to cut, and who owns it.
In early 2026, researchers at ETH Zurich measured what happens when an LLM writes its own context file. Across eight benchmark settings, the auto-generated files lowered task success in five of them, raised inference costs by 20 to 23 percent, and added an average of 2.45 and 3.92 agent steps per task on the two benchmarks1. Files curated by humans did better for every one of the four agents tested.
The study covers coding agents, not PM workspaces. Its findings suggest a useful practice to test in PM work: review what context adds before keeping it. Prompt engineering covered the per-request layer: structure one ask well, get one good answer. This guide covers the layer above it: what the model already sees before you type anything.
From prompts to context
Bharani Subramaniam of Thoughtworks puts the definition in one line: "Context engineering is curating what the model sees so that you get a better result."2
Besides wording the request, review the standing context: the files the model reads at session start, the workspace memory that persists across chats, the documents retrieval pulls in, the instructions that load only when a task needs them. Stale context can lead to answers based on outdated facts, even when the request is clear.
Four layers, from most ephemeral to most durable:
| Layer | What loads | When it loads | Who curates it | Failure mode |
|---|---|---|---|---|
| Prompt | The request itself | Every message | You, per request | Vague ask, generic output |
| Workspace memory | Product facts, personas, formats | According to the app’s project and memory settings | The PM | Stale material can affect later answers |
| Agent guidance file | AGENTS.md / CLAUDE.md conventions | According to the agent’s file-loading rules | The whole team, via PRs | Unnecessary instructions can add cost and distract from the task |
| Skills and retrieval | Extra instructions, docs, scripts | When relevant to the task | Whoever owns that workflow | Never triggers, or triggers on the wrong task |
Martin Fowler's site describes the bottom two layers for coding agents: guidance files like CLAUDE.md load at session start and carry the conventions that apply to the whole project, while skills point to extra resources, instructions, and scripts that load only when relevant2. The two layers PMs actually touch are the personal workspace and the team's agent file. The rest of this guide works through both.
Curation beats generation
Some coding agents offer an init command that scans the repo and generates a context file. The study tested exactly those LLM-generated files and found they reduced task success in five of eight settings, with drops ranging from 0.5 percent on SWE-bench Lite to 2 percent on AGENTbench, while raising average inference costs1. Human-curated files outperformed the generated ones for all four agents tested, and improved on no-file performance for three of the four agents, though they also increased average costs1.
The Augment Code write-up of the study lands on one rule: write only what agents cannot discover on their own. Auto-generated files mostly restate what the agent already reads in the codebase and docs, so they add tokens without adding information. The study found that codebase overviews did not help agents find relevant files faster1.
Keep decisions and definitions the agent needs, and remove repetition that adds no useful guidance. PMs can help by documenting domain rules that code alone does not explain.
Review generated context before committing it. Keep necessary instructions and useful pointers; remove inaccurate claims and redundant descriptions.
Your PM workspace
The same logic applies outside the repo. Productside's 2026 workflow guide describes the pattern as persistent AI workspaces: a Claude Project or ChatGPT Project that retains your product domain, research, personas, constraints, and preferred formats, so you stop re-explaining your world in every chat3.
Apply the ETH filter to what goes in. Only what the model cannot discover, and what you cannot afford to have wrong:
- A product one-pager. What the product is, who pays, the current bet. About 300 words, not the 40-slide strategy deck.
- Metric definitions with formulas. Your activation definition, your churn denominator, your fiscal calendar. "Activation = completed first sync within 7 days of signup" settles the argument before the model invents its own version.
- Two or three personas, each with a verbatim quote from real research.
- Named non-goals. "We do not serve enterprise. We do not build native mobile in 2026." A non-goals list makes those limits explicit.
- One or two voice samples. A doc you wrote that sounds like you, so drafts start closer to done.
What stays out: the strategy doc from two quarters ago, the dump of 60 raw transcripts, anything you would not personally vouch for today. Remove or clearly label outdated material so it is not mistaken for current guidance.
If you work in Claude Cowork or any file-based setup, the folder-level _Context.md pattern in Getting the most out of Claude Cowork is the same idea at smaller scale: tell the model which files are source of truth and which to skip.
Your team's agent context files
The second surface lives in the repo. AGENTS.md is an open format for guiding coding agents, used by over 60,000 open-source projects. Its maintainers call it a README for agents: a dedicated, predictable place for the build steps, tests, and conventions that would clutter a README written for people4. The format came out of collaboration across OpenAI Codex, Amp, Google Jules, Cursor, and Factory, and is now stewarded by the Agentic AI Foundation under the Linux Foundation4. Check the supported-tool list and your agent’s file-loading instructions before relying on it4.
Engineers own most of this file: build commands, test instructions, code style. The PM contributes the part agents cannot infer from code: domain rules, shared vocabulary, and the reason behind a constraint. For example, trial code may show the duration without explaining why sales-assisted deals need more time. An illustrative PM-owned section could look like this:
## Product rules (PM-owned, ask before changing) - "Workspace" = a billing entity. "Project" = a container inside one. Never swap these. - Trials: 14 days self-serve, 30 days sales-assisted. - Free plan never sees seat pricing. Legal constraint, not a UX choice. - Dates display in the user's locale. Exports use ISO 8601.
BuildBetter's guide adds the operating practices: keep the file under 500 lines, because the whole thing loads into the context window and tokens are the budget; treat it as code, meaning the PR that changes a convention also updates the file; and keep the division of labor clean, with the README staying narrative and AGENTS.md staying imperative5.
If you prototype with agents yourself, you have already brushed against these files. From PRD to prototype covers that workflow.
AGENTS.md and CLAUDE.md both provide project guidance, but tools load them differently. CLAUDE.md is Claude Code’s native file2. Check your agent’s documented behavior rather than assuming it reads both automatically.
Maintenance: context rots
Review a context file when you write it and when the underlying facts change. Pricing, personas, and product priorities can become outdated while the file still looks authoritative.
The fix borrows from how engineers handle docs: couple updates to changes. When pricing changes, the workspace one-pager changes the same week. When a repo convention changes, AGENTS.md changes in the same PR5. The update is part of the change, not a follow-up task that never happens.
We have no data on the right review cadence, so here is the intuition. A 10-minute monthly review of your workspace files is a starting point, and the PR-coupling rule handles the repo side without needing a calendar at all. Add one symptom-driven trigger: when the model references a removed feature or outdated metric definition, check which source it used and correct that source if needed.
A quick rot test: open a fresh chat in your workspace and ask "what do you know about this product?" Read the answer as an audit. Check any wrong answer against the files. The error may come from outdated context, retrieval, or the model’s interpretation.
FAQ
What is context engineering? Curating what the model sees so you get a better result, in Thoughtworks' Bharani Subramaniam's definition2. It covers the standing layers around any single prompt: workspace memory, project files like AGENTS.md, retrieved documents, and instructions that load on demand.
Does context engineering replace prompt engineering? No. The prompt remains the per-request layer, and the 2026 rules for it still hold: ground factual claims, skip boilerplate for reasoning models. Context engineering decides what surrounds the request. A good prompt inside bad context produces fluent answers built on wrong facts.
Should I auto-generate my AGENTS.md? Not as the finished product. In ETH Zurich's benchmarks, LLM-generated context files reduced success in five of eight settings and raised inference costs 20 to 23 percent, while human-curated files beat them for all four agents tested1. Generate a draft if it helps, then check each instruction for accuracy and usefulness.
What is the difference between AGENTS.md and CLAUDE.md? AGENTS.md is a shared format supported by multiple coding tools4. CLAUDE.md is Claude Code’s native guidance file2. Check which file your tool reads and keep shared instructions consistent if the repo uses both.
How long should a context file be? BuildBetter suggests staying under 500 lines5; treat that as a guideline, not a proven cutoff. Keep the instructions needed for the task and link to supporting detail. A roughly 300-word product summary plus metric definitions is a manageable starting point for a PM workspace.