TL;DR
The longer you explain a task piece by piece, the worse the AI sticks to your early decisions by the end. The SLUMP study documented this in coding agents: one detailed prompt up front consistently produces a more accurate result than the same requirements scattered across 60 turns of conversation.
The problem: AI has no reliable "commitment tracker." When you say early on "the structure should look like this" and then spend 40 messages refining details, by the end the model often implements its own vision, not yours. Early decisions aren't explicitly deleted from memory, but they get buried under layers of new instructions. Especially vulnerable is structural integration — wiring early modules/blocks into the final result. The model builds the right piece at step 20, and at step 60 creates a new one instead of reusing the old one.
The fix (ProjectGuard): an external "project brief" — a living document with two parts: semantic (what we decided to do and why) and structural (what's already built and how it connects). Before every important step, the brief is injected at the start of the new request. The result: about 90% of the lost quality is recovered without changing the model itself.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
BEFORE YOU START:
Create a "Project Brief" — a living document
[SEMANTIC STATE]
- Project goal and constraints
- Key design decisions (locked in)
- What we're NOT doing (rejected alternatives)
[STRUCTURAL STATE]
- What's already built (blocks, sections, components)
- How they connect to each other
- What must not break in the next steps
IN EVERY NEW TASK:
STEP 0: Update the brief (if anything changed)
STEP 1: Paste the current brief → before the new request
STEP 2: Give a specific task → the next step of the project
STEP 3: Ask it to check the result against the brief → consistency check
WHEN OPENING A NEW CHAT:
Paste the full brief into the first message → before any instructions
Keep the brief up to date by hand, or ask the AI to update it after each session.
Example in Action
Task: Kevin is launching a YouTube channel about investing — in the spirit of the big personal-finance channels, but for 25-35-year-olds with zero stock market experience. He develops the pilot episode over several sessions with Claude: first the concept, then the structure, then the script. The problem: by the third session the AI is writing like the Wall Street Journal, having forgotten the "conversational tone, no jargon" and the "story → mechanics → takeaway" format agreed on in the first.
Prompt:
# PROJECT BRIEF — YouTube channel "Money Without an MBA"
## SEMANTIC STATE (locked-in decisions)
**Episode goal:** explain how dividends work — without brokerage jargon
**Audience:** a 28-year-old office manager from Columbus, Ohio who has never bought a stock
**Tone:** conversational, like explaining it to a friend at a bar — not a lecture, not a manual
**What we're NOT doing:** no technical breakdown of valuation ratios, no recommendations
to buy specific stocks
**Key decisions:**
- Format of every section: story → mechanics → takeaway for the viewer
- Use Coca-Cola as the example — everyone knows it
- Episode length: 8-10 minutes (≈1,200-1,500 words of script)
- The first line must hook the viewer in 5 seconds — no "Hey everyone"
## STRUCTURAL STATE (what's already built)
**Block 1 — "The Hook" (done):**
"Imagine getting paid every year just because you once
bought something. It's not a scheme and it's not crypto. It's dividends."
**Block 2 — "How It Works" (done):**
Explained through an analogy with renting out an apartment.
Terms: dividend yield, shareholder of record — both already explained.
**Block 3 — "The Coca-Cola Example" (IN PROGRESS — your task now):**
Needed: concrete 2023-2024 numbers, what receiving dividends looks like
in practice; don't explain how to open a brokerage account
**Block 4 — "What the Viewer Should Do" (not started):**
Scheduled after block 3
---
**Task right now:** write Block 3 — the Coca-Cola example.
Format: story → mechanics → takeaway. Tone — same as blocks 1 and 2.
At the end, check: does anything you wrote violate any of the locked-in decisions above?
Result:
The model gets the full project context before doing the task. The answer will contain Block 3 in the right format and tone — no jargon, with analogies, in the "story → mechanics → takeaway" structure. At the end comes a self-check: the model explicitly compares what it wrote against the decisions in the brief and flags anything that diverges. That's exactly what usually gets lost by the third or fourth session without a brief.
Why It Works
The LLM's weakness: the model doesn't keep an internal "decision log." Every new request shifts its attention toward the latest messages. Early constraints and agreements aren't deleted — they just become less "visible" in the context and get crowded out by new instructions. It's not a memory bug, it's how the model weighs text.
The LLM's strength: the model is excellent at following explicit, freshly stated instructions. If a constraint sits right before the task, it follows it. The brief turns early decisions from "something we mentioned a few sessions ago" into "right here, in front of you, right now."
How the method exploits this: injecting the brief makes every locked-in decision equally "fresh," no matter when it was made. The semantic state protects against drift in meaning, the structural state against the model building something new instead of reusing what exists. Together they mimic what happens with a single-shot prompt: the entire specification is available at once.
Control levers:
- Update frequency — update the brief after every session, or only after major decisions. The more dynamic the project, the more often.
- The "What we're NOT doing" section → the most important one. Rejected alternatives keep the model from drifting back to them 20 messages later.
- The check at the end of the prompt ("compare against the brief") → drop it if you don't need an explicit check. Keep it for critical tasks.
- Detail in the structural state → the more precisely the links between blocks are described, the less the model will "rewrite" them during integration.
Prompt Template
# PROJECT BRIEF — {project name}
## SEMANTIC STATE
**Goal:** {what we're creating and why}
**Audience:** {who it's for — specifically}
**Tone and style:** {how, and how not}
**What we're NOT doing:** {rejected options, constraints}
**Locked-in decisions:**
- {decision 1 — what exactly and why}
- {decision 2}
- {decision N}
## STRUCTURAL STATE
**{Component/block 1} — status: {done / approved}:**
{short description or key elements}
**{Component/block 2} — status: {done / approved}:**
{short description}
**{Component N} — status: {in progress — current task}:**
{what needs to be done}
---
**Task:** {the specific assignment for this request}
**Output format:** {what I want to get}
**At the end:** check the result against the locked-in decisions above —
flag any discrepancies.
What to fill in:
- {project name} → the name of the document, channel, product, article
- {locked-in decisions} → everything agreed on earlier that must not change
- {what we're NOT doing} → rejected options, this is critical
- {component status} → "done," "approved," "in progress," "not started"
🚀 Quick start — paste into the chat:
I'm running a long project with AI and want to use the "Project Brief" technique
to fight drift in meaning. Help me fill in the template for my task:
{describe the project in 2-3 sentences}. Ask me questions to fill in every field.
[paste the template above]
The LLM will ask: what's already been decided and locked in, which components/blocks are done, what must not change — because those fields are critical for the brief to work as insurance against drift. It'll take the template's structure and adapt it to your project.
Original from the Paper
ProjectGuard maintains two synchronized external states:
Semantic state — stores durable project knowledge: design decisions, implemented agreements, supporting resources. It's conservative: it records only accepted facts, not every proposal.
Structural state — reflects the repository's organization: files, public symbols, interface relationships, derived from the code.
Before each coding turn, a forecaster combines the current request + the user's previous requests + the external state → and generates a task brief for the agent. The brief highlights relevant design commitments, specifies which modules to preserve or revise, and surfaces repository constraints so edits stay compatible.
When live context runs short → ProjectGuard starts a fresh session and injects the rendered project brief with the current semantic and structural state.
Results on Claude Code: 90% of the faithfulness gap recovered, fully correct components up from 118 to 181, severe failures down from 72 to 49.
Limitations
⚠️ Manual work: You have to update the brief yourself after every significant decision. If you forget, you inject a stale state, which is worse than nothing.
⚠️ Not for short tasks: If the project fits in a single chat with full context, just give everything at once in the first message. The brief is for multi-session work or very long conversations.
⚠️ Structural drift is harder than semantic drift: Both Claude Code and Codex lost structural integration (reuse of early blocks) even with ProjectGuard — it's the most persistent form of loss. State it explicitly in the brief: "these blocks must be reused, not rewritten."
⚠️ Tests don't catch drift: If you ask the AI to check its own result, it may confirm what it did rather than what you wanted. A self-check against the brief ("compare with the locked-in decisions") is more reliable than "check that everything works."
Resources
Paper: When the Specification Emerges: Benchmarking Faithfulness Loss in Long-Horizon Coding Agents
Authors: Lu Yan, Xuan Chen, Xiangyu Zhang — Purdue University
Benchmark (open-source): github.com/lunaryan/drift-benchmark
Related work: PaperBench (Starace et al., 2025), MLRBench (Chen et al., 2025), LMR-Bench (Yan et al., 2025)