Instrucciones de origen · Vista previa de solo lectura
name
context-engineering-advisor
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.
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
Context Stuffing vs. Context Engineering
Dimension
Context Stuffing
Context Engineering
Mindset
Volume = quality
Structure = quality
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:
Reflexively expanding context windows — "Just add more tokens!"
Persisting everything "just in case" — No clear retention criteria
Chaining agents without boundaries — Agent A passes everything to Agent B to Agent C
Adding evaluations to mask inconsistency — "We'll just retry until it's right"
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:
"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)
"My team shares ownership (collaborative boundary definition)"
# Context Manifest: [Product/Feature Name]## Always Persisted (Core Context)- Product constraints (technical, regulatory)
- User preferences (role, permissions, preferences)
- Operational glossary (20 key terms)
## Retrieved On-Demand (Episodic Context)- Historical PRDs (retrieve via semantic search)
- User interview transcripts (retrieve relevant quotes)
- Competitive analysis (retrieve when explicitly needed)
## Excluded (Out of Scope)- Meeting notes older than 30 days (no longer relevant)
- Full codebase (use code search instead)
- Marketing materials (not decision-relevant)
## Boundary Owner: [Name]## Last Reviewed: [Date]## Next Review: [Date + 90 days]
User response: [Describe current ownership model]
Agent provides: Recommendation on formalizing ownership + template for Context Manifest.
Step 5: Diagnostic Question 4 — What Fails if We Exclude This?
Agent asks:
Fourth question: For each piece of context, what specific failure mode occurs if you exclude it?
This is the falsification test. If you can't identify a concrete failure, you don't need the context.
Offer 3 scenarios:
"If I exclude product constraints, AI will recommend infeasible solutions"
Failure Mode: Clear and concrete
Assessment: Valid reason to persist constraints
"If I exclude historical PRDs, AI won't understand our product evolution"
Failure Mode: Vague and hypothetical
Assessment: Historical context rarely needed for current decisions
Fix: Retrieve PRDs only when explicitly referencing past decisions
"If I exclude this, I'm not sure anything would break—I just include it to be thorough"
Failure Mode: None identified
Assessment: Context stuffing; delete immediately
Agent recommends:
The Falsification Protocol:
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:
"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
"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
