Obsidian/X-Articles/Your Prompts Are Fine. Your Context Is Broken.md

title, source, author, published, created, description, tags

title	source	author	published	created	description	tags
Your Prompts Are Fine. Your Context Is Broken	https://x.com/kiruwaaaaaa/status/2047960386066890756	@kiruwaaaaaa	2026-04-25	2026-04-26	Everyone got obsessed with prompt engineering. The perfect wording. The magic phrase. The "act as an expert" trick. And for a while, it work...	clippings

Everyone got obsessed with prompt engineering. The perfect wording. The magic phrase. The "act as an expert" trick. And for a while, it worked.

Then agents arrived - and everything changed.

Now your AI is not answering one question anymore. It is running a full workflow: searching the web, reading files, calling APIs, editing code, retrying errors - all in one session. And at some point, usually around turn 20, it starts forgetting things. Making mistakes it already fixed. Ignoring instructions it followed perfectly an hour ago.

That is not a prompting problem. That is a context problem.

Welcome to 2026, where the real skill is not writing better prompts - it is Context Engineering.

The Evolution Nobody Talks About

The industry went through three phases quietly, and most people missed the transition:

2023 - Prompt Engineering. Craft the right words, get the right output. Static, one-turn, artisanal. One person, one question, one answer. This is where 90% of AI content online is still stuck.

2024-2025 - Context Engineering. Design the entire information ecosystem. What the agent knows, when it knows it, how it stores and retrieves it. This is the phase that separates people who build toys from people who build products.

2026 - Intent Engineering. Align the full intent of a task - outcomes, trade-offs, constraints - so the agent makes decisions autonomously, not just executes commands.

Most vibecoders are still in phase one. They write longer prompts when things break. They add "please" and "be careful." They wonder why the agent keeps making the same mistake on step 15 of a 20-step task.

The answer is almost never the prompt. It is almost always the context.

What Context Engineering Actually Is

Context engineering is the practice of deliberately designing, structuring and optimizing all information that enters an AI agent's context window at runtime - system prompts, conversation history, retrieved documents, tool definitions, memory, and structured state.

Andrej Karpathy, one of the founding researchers behind modern AI, put it best:

"Context engineering is the delicate art and science of filling the context window with just the right information for the next step."

The analogy that makes this click: an LLM is like a CPU, and its context window is like RAM. The CPU can only process what is in RAM right now. Everything else - no matter how important - does not exist for the model at this moment. Context engineering is the operating system that decides what gets loaded into RAM, when, and how.

Prompt engineering asks: "How should I phrase this?"

Context engineering asks: "What does the model need to know right now to do this correctly?"

The difference sounds subtle. It is not. One is a conversation skill. The other is a system design skill - and in 2026, it is the #1 job of anyone building serious AI applications.

The Four Ways Context Kills Your Agent

When things go wrong in an agentic workflow, the failure mode almost always fits into one of these four categories:

Context Poisoning - a hallucination makes it into the context and gets treated as fact for the rest of the session. The agent built a lie into its foundation and now everything downstream is wrong.

Context Distraction - the volume of context overwhelms the model. There is so much information that the model loses the thread of what actually matters. It answers adjacent questions instead of the real one.

Context Confusion - superfluous or redundant context influences the response. The agent has two conflicting versions of the same instruction and picks the wrong one.

Context Clash - different parts of the context actively disagree with each other. Instructions from the system prompt conflict with instructions in a tool result. The model has to choose, and it might choose wrong.

These are not model bugs. They are architectural failures. Better prompting does not fix them - better context management does.

Context Rot: The Silent Killer of Long Sessions

The specific failure that destroys most agent workflows has a name: context rot.

Context rot is the performance degradation that happens as an LLM processes an increasingly long context window over a session. The model technically has all the information - but it stops using it correctly.

The mechanism behind this is the "lost-in-the-middle" problem, documented by Stanford researchers. Attention weight distributes across the entire context window. Models consistently perform best when critical information sits at the very beginning or the very end of the context. When key instructions get buried in the middle - under tool outputs, error logs, search results, and intermediate reasoning - the model's attention drifts away from them.

The result: your agent ignores rules it followed perfectly 30 messages ago. It re-introduces bugs it already fixed. It forgets what the goal was. It contradicts itself.

The numbers are brutal: 79% of multi-agent failures come from context management issues, not model capability. Your agent is not getting dumber. It is drowning in its own history.

Context gets worse as context windows get bigger. It sounds counterintuitive - surely more context is better? But Opus 4.5 with a 200K context window and Gemini 3 Pro with a 1M window both exhibit the same attention degradation. A 900K-token Gemini session performs dramatically worse on instructions buried at position 400K than instructions at position 0.

More capacity does not solve the problem - it just delays it and makes it harder to debug.

The 4 Strategies That Actually Fix It

LangChain's engineering team, after studying dozens of production agents, distilled context engineering into four core strategies: Write, Select, Compress, Isolate. Here is how each one works in practice.

Strategy 1 - Write: Save Context Outside the Window

The first strategy is to stop trying to keep everything in the active context window. Instead, write important information to external storage - files, databases, state objects - and load it back only when needed.

The most practical implementation for vibecoders: a WORKING.md file.

## Current Task

Build payment API endpoint

## Status

Schema done - controller 50% complete

## Constraints

No external libraries - must use existing auth system

## Next Step
Write error handling logic

The agent reads this at the start of each session, updates it as it works, and uses it as the ground truth instead of trying to remember what happened 60 messages ago. This single habit eliminates most context rot for most projects.

For longer sessions, add a MEMORY.md for persistent facts that survive across sessions - API keys structure, project decisions, architecture choices. The agent loads this once at the beginning and never has to re-establish context from scratch.

This is exactly how Anthropic's multi-agent researcher works internally: it begins by saving its plan to memory before doing any work, because if the 200K context window gets truncated, the plan must survive.

Strategy 2 - Select: Pull Only What Is Needed, When It Is Needed

Stop dumping everything into context upfront. Instead, design your agent to fetch information at the moment it becomes relevant.

This is the principle behind Retrieval-Augmented Generation (RAG): instead of loading an entire knowledge base into context, the agent embeds a query, searches a vector database, and pulls only the top 3-5 most relevant chunks - at runtime, for that specific step.

RAG solves the core problem of static knowledge. Your AI's training data has a cutoff. Your codebase changes daily. Your documents get updated. RAG lets the agent reach into live data sources and pull exactly what the current step needs, without polluting the context with everything else.

The same principle applies to tools. Agents with 50+ available tools perform significantly worse than agents with 5-10 relevant tools per task - because the tool descriptions themselves consume tokens and create confusion about which one to use. Some teams apply RAG to tool selection itself: embed the task description, match it against tool descriptions semantically, and only load the top tools into context. Studies have shown this improves tool selection accuracy by 3x.

For vibecoders without a vector database: use Claude Code's Explore sub-agent. Instead of loading your entire codebase into context, the Explore agent reads the codebase in read-only mode, builds a summary, and returns only the relevant parts. Your main context stays clean.

Strategy 3 - Compress: Shrink What Is Already There

When context cannot be avoided, compress it.

Claude Code does this automatically at 95% capacity with /compact. The agent summarizes the entire session trajectory into a compressed handoff note and starts fresh with that clean summary as the foundation. Think of it like a developer writing a clean end-of-day status update instead of handing a colleague 6 hours of raw chat logs.

But compression should not wait for 95% capacity. Build compression into your workflow from the start:

- After long tool calls, summarize the result before adding it to context

- At the end of each major phase, write a phase summary before moving to the next

- When switching tasks, compact the previous task's context first

- Use structured formats (JSON/XML/YAML) instead of prose - they are denser and more reliably parsed

The 60% rule: when Claude Code hits 60% context capacity, compact proactively. Waiting until 95% means the model is already degraded for the last 35% of the session.

Strategy 4 - Isolate: Split Context Across Agents

The most powerful context engineering technique is also the most underused: isolating context by distributing work across specialized sub-agents with separate context windows.

The main orchestrator manages goals, decisions, and coordination. Each sub-agent handles a specific subtask in its own isolated bubble. When a sub-agent finishes, only the clean result comes back to the orchestrator - its entire working memory, intermediate steps, failed attempts, and debugging logs are discarded.

Anthropic's research found that many parallel sub-agents with isolated contexts consistently outperform single-agent architectures on complex tasks - because each sub-agent's full context window is allocated to a narrow, focused problem instead of being shared across everything.

The tradeoff is token cost. Multi-agent architectures use up to 15x more tokens than single-turn chat. But for production workflows where reliability matters - and where a failed run costs hours of work, not cents - the isolation is worth it.

In Claude Code 2.0, spawning a sub-agent takes three lines of config. The Task Tool schema handles the rest:

{
  "description": "Audit payment module",
  "prompt": "Review src/payments/ for security issues. Return findings only.",
  "subagenttype": "security-reviewer",
  "model": "haiku",
  "runInBackground": true
}

The sub-agent runs, does its work, returns a clean report, and dies. Your main context never touched the raw audit process.

The Memory Stack Every Serious Builder Needs

Production AI agents in 2026 use a three-tier memory architecture. You do not need a full vector database to implement this - you can build 80% of it with markdown files.

Tier 1 - Hot Memory (Session State)

The last 5-10 interactions. Managed automatically by the agent. For Claude Code, this is the active conversation. No action needed.

Tier 2 - Warm Memory (Working Files)

Your WORKING.md and daily notes. What are you building today? What did you finish? What is next? What decisions have been made? This is where most context rot gets prevented. Write to it constantly. Read it at session start.

Tier 3 - Cold Memory (Semantic Storage)

Facts, documents, and knowledge that need to survive across weeks and projects. For simple setups: a structured MEMORY.md. For serious production: a vector database (ChromaDB, Qdrant, Pinecone) with embedding-based retrieval. The agent queries this store with semantic search and pulls only what is relevant to the current task.

The transition from Tier 2 to Tier 3 is where vibecoding becomes a real engineering practice. When your project is complex enough that a single MEMORY.md file is getting unwieldy - that is the signal to move to vector storage.

RAG is Part of Context Engineering - Not the Same Thing

This confusion is everywhere, so it is worth being explicit.

RAG (Retrieval-Augmented Generation) is a retrieval technique. It answers one question: "What is relevant to this query?" It uses vector search to fetch matching chunks from a knowledge base and injects them into the prompt.

Context engineering is the discipline that contains RAG - and much more. It answers a different question: "What is relevant, trustworthy, timely, and auditable enough to put in front of this model right now?"

Dimension | RAG | Context Engineering

What it is | Retrieval technique | Full discipline governing all context input

Scope | Fetches relevant knowledge chunks | Manages instructions, memory, tools, state, history

Key question | "What is relevant?" | "What is relevant, trusted, and properly timed?"

Handles memory | No | Yes

Handles tool outputs | No | Yes

Handles multi-agent | No | Yes

When it is enough | Simple Q&A on static corpus | Always needed in agentic systems

RAG is a powerful tool inside the context engineering toolkit. But thinking RAG solves your context problems is like thinking a good database solves your software architecture problems. It is necessary. It is not sufficient.

MCP: The Infrastructure Layer That Changes Everything

Model Context Protocol (MCP) is the open standard Anthropic released that makes context engineering scalable at the infrastructure level. Think of MCP as USB-C for AI - a universal connector that lets your agent pull live, structured data from any external system at runtime.

Before connecting an AI agent to GitHub required custom integration code. Connecting it to Notion required different custom code. Connecting it to Slack required more custom code. Every integration was bespoke, fragile, and maintained separately.

MCP provides one universal protocol. Implement it once in your agent, and it unlocks an entire ecosystem of integrations - GitHub, Notion, Slack, Google Drive, databases, APIs - all through the same interface. The agent requests what it needs, the MCP server provides it, and the information flows into context exactly when required.

The key insight for context engineering: MCP enables just-in-time data access at the infrastructure level. Instead of pre-loading everything an agent might need (which causes context bloat and rot), MCP lets the agent pull precisely what it needs at each step. Anthropic's research shows this approach resolves roughly 80% of routine data queries while keeping context lean and accurate.

For vibecoders, the practical implications are significant:

- Connect Claude Code to your GitHub repository and it reads the diff directly instead of you copy-pasting it

- Connect it to Notion and your project docs flow into context automatically

- Connect it to a Telegram bot and your agent operates live without you running it manually

MCP is also the foundation of code execution as a context engineering tool. Instead of passing raw data into the context window, the agent writes code that processes the data in a sandboxed environment and passes back only the result. This is how you handle token-heavy objects - images, large files, raw API responses - without poisoning your context with them.

Context Engineering in Practice: A Vibecoder's Workflow

Here is what a properly context-engineered session looks like for someone building a crypto Telegram bot with Claude Code.

Before the session starts:

- WORKING.md is updated with current task, status, and next step

- MEMORY.md holds project architecture decisions, API endpoints, and key constraints

- MCP servers are connected: GitHub (for code), Telegram API (for testing)

Opening message to the agent:

"Load WORKING.md and MEMORY.md. Continue from where we left off. Current task: add price alert functionality."

Two sentences. The agent has full context in 20 tokens.

During the session:

- Agent reads files via MCP instead of you pasting code

- Agent writes progress notes to WORKING.md after each step

- At 60% context: /compact - agent summarizes and continues

- Sub-agent handles the notification logic in isolation, returns clean code

After the session:

- Agent writes a phase summary to MEMORY.md

- WORKING.md is updated with completion status and next steps

Total context used: dramatically less than a chaotic unstructured session. Reliability: dramatically higher. The bot works on turn 50 the same way it worked on turn 5.

The Bigger Picture: Why This Matters Beyond Individual Projects

Context engineering is not just a productivity trick. It is the difference between AI that works once and AI that works reliably at scale.

Vibe coding failures are accelerating in 2026. Amazon's March 2026 outage - caused by an AI-assisted deployment - shut down Amazon.com for 6 hours and cost an estimated 6.3 million lost orders. A December 2025 study found 69 vulnerabilities across 15 apps built by major AI coding tools, with 45% of all AI-generated code containing at least one security flaw. Every single tested app lacked CSRF protection.

Almost none of these failures were model capability failures. They were context failures. Agents that did not have the right information at the right time made catastrophically wrong decisions. Agents that were not told about security constraints did not apply them. Agents whose context had drifted forgot that a table was in production.

Context engineering solves this by making the agent's information environment explicit, auditable, and controlled. When you design what your agent knows - and what it does not know - you can reason about what it will do. Prompting is a black box. Context engineering is architecture.

The vibecoders shipping reliable products in 2026 are not the ones with the best prompts. They are the ones who treat context as a first-class engineering concern.

The Stack to Start With Today

You do not need a vector database. You do not need a custom MCP server. You do not need to understand embedding dimensions. Start here:

1. Create WORKING.md in your project folder. Write your current task, status, constraints, and next step. Update it every session. This alone eliminates 80% of context rot for most projects.

2. Create MEMORY.md for facts that survive sessions. Architecture decisions, key API structures, project goals. Load it at the start of every session with two lines.

3. Use /compact proactively at 60% context, not 95%. Your session's second half will be dramatically more reliable.

4. Use structured prompts with XML or markdown blocks instead of prose. <current_task>, , , <next_step>. The model's attention finds tagged information far more reliably than narrative paragraphs.

5. Delegate with sub-agents when a task is genuinely separable. Let the sub-agent do its work, return its result, and die. Keep your main context clea

That is it. Five habits. No infrastructure required. Start with WORKING.md today, and you will immediately feel the difference.

Prompt engineering got you started. Context engineering is what gets you to production.

The models are already good enough. The bottleneck is what you put in front of them.