---name: context-engineering-advisor
argument-hint: "[AI workflow to diagnose]"
description: Diagnose context stuffing vs. context engineering. Use when an AI workflow feels bloated, brittle, or hard to steer reliably.
intent: >-
Guide product managers through diagnosing whether they're doing **context stuffing** (jamming volume without intent) or **context engineering** (shaping structure for attention). Use this to identify context boundaries, fix "Context Hoarding Disorder," and implement tactical practices like bounded domains, episodic retrieval, and the Research→Plan→Reset→Implement cycle.
type: interactive
theme: ai-agents
best_for:
- "Diagnosing context stuffing vs. context engineering in your AI workflows"
- "Building better memory and retrieval architecture for AI agents"
- "Improving AI output quality through structured context design"
scenarios:
- "My AI outputs are mediocre even though I'm giving it lots of information — diagnose what's wrong"
- "I want to architect context properly for a multi-step AI workflow in my product team"
estimated_time: "15-20 min"
---## Purpose
Guide product managers through diagnosing whether they're doing **context stuffing** (jamming volume without intent) or **context engineering** (shaping structure for attention). Use this to identify context boundaries, fix "Context Hoarding Disorder," and implement tactical practices like bounded domains, episodic retrieval, and the Research→Plan→Reset→Implement cycle.
**Key Distinction:** Context stuffing assumes volume = quality ("paste the entire PRD"). Context engineering treats AI attention as a scarce resource and allocates it deliberately.
This is not about prompt writing—it's about **designing the information architecture** that grounds AI in reality without overwhelming it with noise.
## Input
**Works best with:** A description of the AI workflow, agent, or prompt setup that feels bloated, brittle, or hard to steer.
**Also useful:** What you've already stuffed into context (docs, transcripts, schemas) and where outputs go wrong.
Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended `ARGUMENTS:` line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.
**Arriving empty-handed? That works too.** The advisor opens by asking what you're feeding the model today and what breaks.
**Example invocation:** `Diagnose my setup: our support-triage agent gets the full 40-page policy manual per ticket and still misroutes edge cases.`
## Key Concepts
### The Paradigm Shift: Parametric → Contextual Intelligence
**The Fundamental Problem:**
- LLMs have **parametric knowledge** (encoded during training) = static, outdated, non-attributable
- When asked about proprietary data, real-time info, or user preferences → forced to hallucinate or admit ignorance
- **Context engineering** bridges the gap between static training and dynamic reality
**PM's Role Shift:** From feature builder → **architect of informational ecosystems** that ground AI in reality
| **Approach** | "Add everything just in case" | "What decision am I making?" |
| **Persistence** | Persist all context | Retrieve with intent |
| **Agent Chains** | Share everything between agents | Bounded context per agent |
| **Failure Response** | Retry until it works | Fix the structure |
| **Economic Model** | Context as storage | Context as attention (scarce resource) |
**Critical Metaphor:** Context stuffing is like bringing your entire file cabinet to a meeting. Context engineering is bringing only the 3 documents relevant to today's decision.
---
### The Anti-Pattern: Context Stuffing
**Five Markers of Context Stuffing:**
1. **Reflexively expanding context windows** — "Just add more tokens!"
2. **Persisting everything "just in case"** — No clear retention criteria
3. **Chaining agents without boundaries** — Agent A passes everything to Agent B to Agent C
4. **Adding evaluations to mask inconsistency** — "We'll just retry until it's right"
5. **Normalized retries** — "It works if you run it 3 times" becomes acceptable
**Why It Fails:**
- **Reasoning Noise:** Thousands of irrelevant files compete for attention, degrading multi-hop logic
- **Context Rot:** Dead ends, past errors, irrelevant data accumulate → goal drift
- **Lost in the Middle:** Models prioritize beginning (primacy) and end (recency), ignore middle
- **Economic Waste:** Every query becomes expensive without accuracy gains
- **Fix:** Apply Question 4 test to each piece of context
**Agent recommends:**
**Rule of Thumb:**
- **Persist:** Information referenced in 80%+ of interactions
- **Retrieve:** Information referenced in <20% of interactions
- **Gray zone (20-80%):** Depends on retrieval latency vs. context window cost
**User response:** [Categorize their context]
**Agent provides:** Specific recommendations on what to persist vs. retrieve.
---
### Step 4: Diagnostic Question 3 — Who Owns the Context Boundary?
**Agent asks:**
**Third question: Who is responsible for defining what belongs in vs. out of your AI's context?**
**The Ownership Problem:**
If **no one** owns the context boundary, it will grow indefinitely. Every PM will add "just one more thing," and six months later, you're stuffing 100k tokens per query.
**Offer 3 options:**
1. **"I own the boundary (solo PM or small team)"**
- **Assessment:** Good—you can make fast decisions
- **Recommendation:** Document your boundary criteria (use Questions 1-5 as framework)
2. **"My team shares ownership (collaborative boundary definition)"**
For each context element, complete this statement:
> "If I exclude [context element], then [specific failure] will occur in [specific scenario]."
**Examples:**
- ✅ Good: "If I exclude GDPR constraints, AI will recommend features that violate EU privacy law."
- ❌ Bad: "If I exclude this PRD, AI might not fully understand the product." (Vague)
**User response:** [Apply falsification test to their context]
**Agent provides:** List of context elements to delete (no concrete failure identified).
---
### Step 6: Diagnostic Question 5 — Are We Fixing Structure or Avoiding It?
**Agent asks:**
**Fifth question: Is adding more context solving a problem, or masking a deeper structural issue?**
**The Root Cause Question:**
Context stuffing often hides bad information architecture. Instead of fixing messy, ambiguous documents, teams add more documents hoping AI will "figure it out."
**Offer 3 options:**
1. **"I'm adding context because our docs are poorly structured/ambiguous"**
- **Assessment:** You're masking a structural problem
- **Fix:** Clean up the docs first (remove ambiguity, add constraints, define terms)
- **Example:** Instead of pasting 5 conflicting PRDs, reconcile them into 1 Source of Truth
2. **"I'm adding context because we don't have a shared operational glossary"**
- **Assessment:** You're compensating for missing foundations
- **Fix:** Build the glossary (20-30 key terms); AI can reference it reliably
- **What it retrieves:** Historical PRDs, user interviews, competitive analysis
- **Method:** Semantic search triggered by query intent
- **Optimization:** Contextual Retrieval (Anthropic) — prepend explanatory context to each chunk before embedding
- **Your specific needs:** [Agent customizes]
**Agent offers:**
Would you like me to:
1. **Generate a Context Architecture Blueprint** for your specific use case?
2. **Provide implementation guidance** (tools, techniques, best practices)?
3. **Design a retrieval strategy** for your episodic context?
**User response:** [Selection]
---
### Step 8: Implement Research → Plan → Reset → Implement Cycle
**Agent asks:**
Now let's implement the **Research → Plan → Reset → Implement** cycle to prevent context rot.
**The Problem:** As agents research, context windows grow chaotic—filled with dead ends, errors, and noise. This dilutes attention and causes goal drift.
**The Solution:** Compress research into a high-density plan, then **clear the context window** before implementing.
**The Four-Phase Cycle:**
**Phase 1: Research (Chaotic Context Allowed)**
- Agent gathers data from multiple sources
- Context window grows large and messy (this is expected)
- Dead ends, failed hypotheses, and noise accumulate
- **Goal:** Comprehensive information gathering
**Phase 2: Plan (Synthesis)**
- Agent synthesizes research into a high-density SPEC.md or PLAN.md
- This becomes the **Source of Truth** for implementation
- **Key elements:**
- Decision made
- Evidence supporting decision
- Constraints applied
- Next steps (sequenced)
- **Format:** Structured, concise, unambiguous
**Phase 3: Reset (Clear Context Window)**
- **Critical step:** Clear the entire context window
- Delete all research artifacts, dead ends, errors
- This prevents context rot from poisoning implementation
**Phase 4: Implement (Fresh Session with Plan Only)**
- Start a new session with **only the high-density plan** as context
- Agent has clean, focused attention on execution
- No noise from research phase
**Agent offers 3 options:**
1. **"I want a template for the PLAN.md format"**
- Agent provides structured template for high-density plans
2. **"I want to see an example of this cycle in action"**
- Agent walks through concrete PM use case (e.g., discovery planning)
3. **"I'm ready to implement this in my workflow"**
- **[epic-hypothesis](../epic-hypothesis/SKILL.md)** (Component) — Testable hypotheses depend on clear constraints (part of context)
- **[pol-probe-advisor](../pol-probe-advisor/SKILL.md)** (Interactive) — Validation experiments benefit from context engineering (define what AI needs to know)
### External Frameworks
- **Dean Peters** — [*Context Stuffing Is Not Context Engineering*](https://deanpeters.substack.com/p/context-stuffing-is-not-context-engineering) (Dean Peters' Substack, 2026)
- **Teresa Torres** — *Continuous Discovery Habits* (Context Engineering as one of 5 new AI PM disciplines)
- **Marty Cagan** — *Empowered* (Feasibility risk in AI era includes understanding "physics of AI")
