TL;DR. Every major assistant now exposes three configuration layers: a standing brief you write once, a project or workspace that scopes context to one body of work, and a memory that the tool populates itself. Most professionals use one of the three, usually badly, and then conclude the tool does not understand their work. The vendors themselves disagree about how to fill these layers: Google’s official Gem guidance says to provide as much background as possible, while Anthropic’s official documentation caps its equivalent file at roughly 200 lines and states plainly that longer files reduce adherence. Peer-reviewed evidence sides decisively with the second position. In the Lost in the Middle study, handing a model the single correct document raised accuracy between 27.8 and 50.4 percentage points, whereas quadrupling or multiplying the context window by 12.5 changed accuracy by 0.3 points. That is a 93 to 107 fold advantage for choosing well over storing more. The practical conclusion is not “write more context.” It is “assign each fact to the layer where it will still be read.”
The failure this solves
The complaint is familiar. You explain your role, your clients, your constraints and your house style at the start of a conversation. The output improves. Tomorrow you open a new conversation and explain it all again. After the fourth repetition you decide the tool is not built for real work.
The tool is built for it. You are supplying the context in the one place designed to forget: the conversation. The three configuration layers exist precisely to hold what should not be retyped. What almost nobody does is decide, deliberately, which facts belong in which layer. That assignment problem is the whole discipline, and it is separate from writing a good prompt. If you have not yet built a single source document about your work, start with the context file; this piece is about where the contents of that document should actually live.
What the three layers are
Terminology differs by vendor, but the architecture has converged.
Layer 1, the standing brief. Instructions that apply to everything you do with the tool. ChatGPT calls this custom instructions. Anthropic’s developer tooling uses a user-scope instructions file at ~/.claude/CLAUDE.md. Google’s equivalent, applied per assistant rather than globally, is the Gem instruction block. This layer is loaded into every session.
Layer 2, the project or workspace. Context scoped to one body of work: a client, a product, a research thread. Files, reference documents and instructions that apply inside that boundary and nowhere else. Anthropic documents this as a project-scope instructions file committed alongside the work, plus path-scoped rules that load only when matching material is in play.
Layer 3, memory. Notes the assistant writes about you without being asked. Anthropic’s documentation is unusually explicit about the division of labour here: instruction files are written by you and contain “instructions and rules,” while auto memory is written by the model and contains “learnings and patterns,” specifically your preferences, corrections you have given, and project context the model cannot derive on its own. It also states that the memory index loads only its first 200 lines or 25KB into each session, whichever comes first, with the remainder not loaded at session start.
That last detail matters more than it looks. Layer 3 has a hard budget, enforced silently. Anything past it is simply not there.
The evidence: curation beats capacity by two orders of magnitude
The temptation with any of these layers is to fill them. Context windows are advertised in hundreds of thousands of tokens, so storing everything feels free. The controlled evidence says it is not.
Liu and colleagues, publishing in Transactions of the Association for Computational Linguistics, ran a multi-document question answering task under two reference conditions. In the closed-book condition the model received no documents and had to rely on what it already knew. In the oracle condition it received exactly one document, the one containing the answer. Everything else in the study varied where the answer sat among distractors.
Verified data. Closed-book and oracle accuracy, multi-document question answering (Liu et al., TACL 2024).
| Model | Closed-book | Oracle |
|---|---|---|
| LongChat-13B (16K) | 35.0% | 83.4% |
| MPT-30B-Instruct | 31.5% | 81.9% |
| GPT-3.5-Turbo | 56.1% | 88.3% |
| GPT-3.5-Turbo (16K) | 56.0% | 88.6% |
| Claude-1.3 | 48.3% | 76.1% |
| Claude-1.3 (100K) | 48.2% | 76.4% |
Read down the table and two of the rows are near-duplicates on purpose. GPT-3.5-Turbo appears at a 4K window and a 16K window. Claude-1.3 appears at 8K and 100K. Same model family, same task, different capacity. That pairing lets us isolate what capacity alone buys, which the paper does not tabulate.
CEOtudent editorial framework: the curation premium. Derived from the table above; the right-document gain compared with the larger-window gain.
| Comparison | What changed | Accuracy change | Ratio |
|---|---|---|---|
| GPT-3.5-Turbo, closed-book to oracle | Given the one right document | +32.2 points (+57.4%) | reference |
| GPT-3.5-Turbo, 4K to 16K window | Context capacity multiplied by 4 | +0.3 points (+0.34%) | curation worth 107x |
| Claude-1.3, closed-book to oracle | Given the one right document | +27.8 points (+57.6%) | reference |
| Claude-1.3, 8K to 100K window | Context capacity multiplied by 12.5 | +0.3 points (+0.39%) | curation worth 93x |
| LongChat-13B, closed-book to oracle | Given the one right document | +48.4 points (+138.3%) | largest single gain observed |
| MPT-30B-Instruct, closed-book to oracle | Given the one right document | +50.4 points (+160.0%) | largest single gain observed |
Multiplying Claude-1.3’s context window by 12.5 moved oracle accuracy from 76.1% to 76.4%. Giving the same model the correct document moved it from 48.3% to 76.1%. The second intervention was 93 times larger than the first. For GPT-3.5-Turbo the multiple is 107. Both closed-book figures moved slightly the wrong way when the window grew, by 0.1 of a point, which is noise but certainly not an improvement.
This is the number to hold on to when you are deciding whether to paste your entire client folder into a project. Capacity is not the constraint. Selection is.
When more context is worse than none
The stronger finding is the uncomfortable one. Liu and colleagues report that when the relevant information sat in the middle of the input, GPT-3.5-Turbo’s performance could drop by more than 20%, and that in the worst case, performance in the 20 and 30 document settings fell below the model’s own closed-book score of 56.1%.
Restate that in working terms. The model was given the answer. It performed worse than when it was given nothing at all. Nineteen or twenty-nine irrelevant documents surrounding a correct one did more damage than the correct one did good.
The mechanism the authors describe is a U-shaped curve: strong use of material at the very beginning of the context and at the very end, degraded use of everything between. Whatever you bury in the middle of a long standing brief is, functionally, the material most at risk.
This is why “add everything, it might help” is not a neutral strategy. It has a measurable downside, and the downside grows with the amount of plausible-looking but irrelevant material you include. For the related question of what to do when the output is confidently wrong, see why AI hallucinates.
The vendors do not agree with each other
Here is a comparison that, as far as we can find, nobody has put side by side: the official written guidance of two major vendors on how to fill the standing-brief layer.
Verified data. Official vendor guidance on writing the standing-brief layer, from each vendor’s own documentation.
| Vendor guidance | On length | On specificity | On what it actually is |
|---|---|---|---|
| Anthropic, memory documentation | “Target under 200 lines per CLAUDE.md file. Longer files consume more context and reduce adherence.” Shorter files are stated to produce better adherence. | Prefers concrete, checkable instructions: “Use 2-space indentation” over “Format code properly”; “Run npm test before committing” over “Test your changes.” |
Explicitly not enforced configuration. Documented as context delivered as a user message after the system prompt, with no guarantee of strict compliance. |
| Google, Gemini Gems support documentation | Recommends four components, persona, task, context and format, and under context advises: “Provide as much background as possible.” | “Be specific when specifying desired structure” for the format component; persona defines role and response style. | An instruction block attached to a purpose-built assistant rather than a global default. |
Both are official. They point in opposite directions on the single question a new user most needs answered: how much should I write?
The Lost in the Middle results adjudicate. Volume is not the lever; placement and relevance are. Google’s advice is defensible for the narrow case a Gem is built for, where the background genuinely is the task and the assistant does one job. Applied to a general standing brief that loads into every session regardless of what you are doing, “as much background as possible” is close to the experimental condition that scored below closed-book.
There is also a second contradiction inside Anthropic’s own documentation worth noticing, because it is instructive rather than sloppy. It recommends splitting large instruction files into imports for organisation, then states that imported files still load into the context window at launch, so splitting “doesn’t reduce context.” Organisation and cost are different problems, and the docs are careful not to let the first pretend to solve the second. Most productivity advice about AI configuration blurs exactly that line.
The Job Context Spec
The assignment problem needs a rule, not a preference. Ours uses three tests, applied to each fact in turn.
CEOtudent editorial framework: the Job Context Spec. A layer-assignment rule for facts about your work.
| Test | Question | If yes |
|---|---|---|
| Scope | Is this true of every piece of work I do with this tool? | Layer 1, standing brief |
| Boundary | Is this true only inside one client, product or thread? | Layer 2, project |
| Origin | Did I only discover this because the tool got it wrong and I corrected it? | Layer 3, memory |
| Derivability | Could the tool work this out from material it can already see? | No layer. Delete it. |
| Volatility | Will this be false within a quarter? | No layer. Say it in the conversation. |
The fourth and fifth tests do most of the work, because they are the ones that keep the layers small enough to survive the 200-line problem.
Derivability is the test people skip. If your project already contains the style guide, restating the style guide in your standing brief buys nothing and costs placement. Anthropic’s documentation applies exactly this rule to its own auto memory, which it says skips anything derivable from the codebase and anything the instruction files already say.
Volatility is the test people get backwards. Current quarter priorities, the deal that is closing this week, the deadline in eleven days: all of it feels like important context, and all of it is wrong within a quarter, at which point it is not neutral clutter but active misinformation sitting in the highest-priority position in every future session.
Worked assignment for a mid-career professional:
- “I work in regulated pharmaceutical marketing; every claim needs a source.” Scope test passes. Layer 1.
- “Never use bullet lists in client-facing memos.” Scope test passes, and it is concrete enough to verify. Layer 1.
- “This client’s brand voice avoids superlatives, see the attached guide.” Boundary test. Layer 2, with the guide in the project rather than quoted into instructions.
- “I keep asking for shorter openings and keep getting three-sentence preambles.” Origin test. Layer 3, if the tool writes it there itself; otherwise promote the corrected rule to Layer 1 in one line.
- “Our approval workflow has four stages” when the workflow document is already in the project. Derivability test fails. Delete.
- “Q3 target is 14% growth.” Volatility test fails. Say it in the conversation where it applies.
A standing brief built this way tends to land between 15 and 40 lines. That is not a target we invented for elegance; it is what survives the five tests for most single-role professionals, and it sits comfortably inside the only published line budget any vendor has committed to in writing.
Three configuration mistakes worth naming
Writing a persona instead of a specification. “You are a world-class strategy consultant” is a costume, not information. It is not checkable, it does not constrain output, and it occupies the highest-value position in the context. Replace it with the constraints that actually differ from the tool’s defaults.
Treating memory as a filing cabinet. Memory is populated by the model from your corrections. It is designed to hold learnings, and it has a stated load budget. Pushing reference material into it competes with the corrections that make it useful, and anything past the budget is dropped silently at session start.
Never auditing. Anthropic’s documentation warns that if two rules contradict each other the model “may pick one arbitrarily,” and recommends periodic review to remove outdated or conflicting instructions. Configuration decays. A standing brief written eight months ago, when you had a different role and different clients, is now a set of instructions actively steering output toward work you no longer do. Put a recurring 20 minute review in the calendar each quarter and delete rather than add.
What this looks like as a practice
The setup takes about an hour once.
- Write down every fact you have retyped into a conversation more than twice in the last month. This is your candidate list, and it should come from your actual behaviour rather than your idea of what matters.
- Run each candidate through the five tests above. Expect to delete between a third and a half at the derivability and volatility tests.
- Put the survivors in their assigned layer. Write them as concrete instructions rather than descriptions.
- Order the standing brief so the two or three constraints you would most hate to see violated sit at the top and at the bottom, not in the middle. This costs nothing and directly addresses the U-shaped curve.
- Diary a quarterly review whose default action is deletion.
The reason to do this is not tidiness. It is that the difference between an assistant that knows your job and one that does not was measured at 27.8 to 50.4 accuracy points, and it came from selection, not from storage. For the wider skill this sits inside, see what context engineering is; for handing whole tasks rather than context to a tool, see the briefing framework for AI agents.
Lead the configuration like a CEO writing a mandate: few constraints, all of them binding, reviewed on a schedule. Learn like a student: notice which correction you keep repeating, and treat that repetition as the signal that a line is missing from the brief.
Frequently asked questions
Should I put my whole CV in the standing brief?
Almost certainly not. Run it through the scope test line by line. Your current role and the constraints it imposes pass. Your employment history from a decade ago does not affect any output and consumes the positions where binding constraints should sit.
Is a bigger context window a reason to relax any of this?
The evidence in this piece is the direct test of that question. Multiplying the window by 12.5 changed oracle accuracy by 0.3 of a point. The correct-document effect was 93 times larger. Capacity growth has not, on this evidence, made selection less important.
Vendors keep changing the limits. Does that break this framework?
The specific character and line limits change frequently, which is why the framework is built on the tests rather than the numbers. Scope, boundary, origin, derivability and volatility do not depend on any vendor’s current cap. Check the current limit in your tool’s own documentation rather than in a third-party summary, since these figures move faster than most published guides.
Does any of this help if the tool simply gets facts wrong?
Partly. Correct context reduces one class of error, the kind caused by the model filling a gap it should not have had to fill. It does not eliminate confident errors that come from the model’s own generation process, which is a separate problem.
What if my employer manages these settings centrally?
Then Layer 1 may be partly out of your hands. Anthropic documents an organisation-wide managed instructions file that individual settings cannot exclude. Your leverage moves to Layer 2, where project scope is usually still yours to design.
Sources
- Liu, Lin, Hewitt, Paranjape, Bevilacqua, Petroni and Liang, Lost in the Middle: How Language Models Use Long Contexts, Transactions of the Association for Computational Linguistics, 2024. Closed-book and oracle accuracy for six models; the U-shaped positional curve; the finding that 20 and 30 document settings can fall below closed-book performance.
- Anthropic, official Claude Code documentation, memory reference page. The distinction between instruction files and auto memory; the four scope levels; the under 200 lines guidance and the statement that longer files reduce adherence; the 200 line or 25KB memory index load limit; the note that instruction files are context rather than enforced configuration; the guidance on specificity, contradictory rules and imports.
- Google, official Gemini Apps support documentation on writing effective Gem instructions. The four component structure of persona, task, context and format, and the guidance to provide as much background as possible.
This content was compiled with the support of AI following in-depth research, then written and prepared for publication by the CEOtudent editorial team.
This post is also available in:
