Prompt Engineering Is Dead. Context Engineering Is What Actually Matters Now.

Signup Write New Story Prompt Engineering Is Dead. Context Engineering Is What Actually Matters Now. by Emmanuela Opurum by Emmanuela Opurum | @ cloudsavant Solutions Architect at Softnet Technologies DevOps & Cloud Solutions Architect skilled in AWS, Azure, GCP, CI/CD, multi-cloud strategy, and scalable infrastructure.

DevOps & Cloud Solutions Architect skilled in AWS, Azure, GCP, CI/CD, multi-cloud strategy, and scalable infrastructure.

In 2023, the trick was knowing how to word a prompt. In 2026, every serious AI model follows instructions well enough that phrasing stopped being the bottleneck. The bottleneck is now what information the model has when it answers. That is context engineering, the discipline of designing everything the model sees, not just what you say to it. This is the complete guide.

I had spent three days rewriting a prompt.

The system was a customer support agent. It was giving inconsistent answers, sometimes accurate, sometimes confidently wrong. I tweaked the wording. I restructured the instructions. I added examples. I tried different models. I moved sentences around. I experimented with different formatting.

Then a colleague asked a question that changed everything:

"What information does the model actually have when it answers?"

Not "what are you telling it to do", that was the prompt, and I had optimised it to death. But "what does it actually know?"

The answer, when I looked honestly, was: not enough, and what it did have was poorly organised.

The model was not failing because my instructions were badly worded. It was failing because I had given it instructions without giving it the information it needed to follow them. The prompt was fine. The context was broken.

That is the difference between prompt engineering and context engineering. And once you see it, you cannot unsee it.

Prompt engineering is the practice of optimising the words you use to instruct a model.

It emerged in 2022 and 2023 when models were less capable and the gap between a good prompt and a bad one was enormous. A few techniques, chain of thought, few-shot examples, role assignment, clear output formatting — could take a model from useless to genuinely helpful for a specific task.

Those techniques still work. But they have a ceiling.

Prompt engineering assumes the model has everything it needs and just needs good instructions. It is optimising how you ask. It is about the phrasing, the structure, the examples you give, the persona you assign.

When the information is not there, no instruction can conjure it.

You can write the most elegant, well-structured, example-rich prompt in the world. If the model does not have access to the customer's account history, it cannot tell you why the payment failed. If it does not have the current documentation, it will hallucinate from its training data. If it does not have memory of what was said three sessions ago, it will contradict itself.

The model is not going to invent the right information because you asked nicely.

Andrej Karpathy, the former Director of AI at Tesla, founding member of OpenAI, and one of the most respected voices in the field, coined the term "context engineering" in mid-2025 to name this shift. His point: the leverage in modern AI systems has moved from how you phrase the instruction to what information surrounds it.

In 2026, with models that follow instructions reliably, context is the primary variable.

Context engineering is the discipline of designing everything a model sees when it generates a response.

Every time a model responds to something, it sees a context window, a block of tokens that contains everything available to it at that moment. That window can contain:

Prompt engineering optimises one of these: the system prompt and maybe the current message.

Context engineering optimises the whole thing.

The question it asks is not "how should I word this instruction?" It is "what should the model know when it answers?"

These are different questions. They lead to different work. And in production AI systems, the second question is where almost all the real leverage lives.

Understanding context engineering means understanding what you are assembling. There are five layers, and each has its own design decisions.

This is the layer prompt engineering focused on. It still matters. But context engineers think about it differently.

A prompt engineer asks: "what is the best way to instruct this model?"

A context engineer asks: "what is the minimum system prompt that sets the right operating parameters, without bloating the context with things that belong elsewhere?"

Long, rambling system prompts are a context engineering problem. They consume tokens, they dilute the model's attention, and they put information in the wrong place, instructions mixed with knowledge, constraints buried in paragraphs.

Good context engineering for the system prompt means:

# Not this — 800 tokens of tangled instructions and knowledge: system_prompt = """ You are a helpful customer service agent for TechCorp. TechCorp was founded in 2018 and sells software subscriptions. Our products include the Basic plan at £29/month, the Pro plan at £99/month, and the Enterprise plan which is custom priced.

When users ask about pricing they should be directed to our pricing page. When users have technical issues you should ask them about their browser and operating system. When users want refunds you should check if they are within the 30-day refund window.

Our refund policy states that... [500 more words of policy embedded in the prompt] """ # This — 80 tokens of clean operating parameters, knowledge retrieved separately: system_prompt = """ You are a TechCorp customer support agent. Be accurate, friendly, and concise. For pricing, policy, and product details: use ONLY the information provided in the retrieved context below.

Never invent or estimate. If information is not in the context, say so and offer to escalate. """ # Product knowledge, pricing, and policies come from the RAG layer — not here The system prompt should instruct.

The knowledge should come from retrieval. Mixing them is the most common context engineering mistake.

This is where most production AI failures actually live. Not in the prompt. In retrieval.

The model cannot know things it was not told. But in RAG (Retrieval Augmented Generation) systems, the retrieval is often broken in ways that look like model failures.

The three most common retrieval failures:

Wrong chunks returned: the retrieval returns text that is topically related but not semantically relevant to the actual question. You asked about refund eligibility. The retriever returned the refund initiation process, adjacent, not identical.

Right content, wrong context: the relevant passage is retrieved but it is missing the surrounding context that makes it interpretable. A sentence like "this applies only to annual subscribers" is meaningless without knowing what "this" refers to.

Too much retrieved; the system returns 20 chunks, stuffs them all into the context window, and the model either ignores most of them or averages across them instead of focusing on the relevant one.

Context engineering for retrieval looks like this:

import boto3 import json bedrock_agent = boto3.client('bedrock-agent-runtime', region_name='us-east-1') def retrieve_context(query: str, knowledge_base_id: str) -> tuple[str, list]: """ Retrieve context intelligently — not just the top N chunks, but the right chunks, formatted for model consumption. """ # Step 1: Retrieve candidates response = bedrock_agent.retrieve( knowledgeBaseId=knowledge_base_id, retrievalQuery={"text": query}, retrievalConfiguration={ "vectorSearchConfiguration": { "numberOfResults": 10, # Retrieve more candidates "overrideSearchType": "HYBRID" # Semantic + keyword } } ) results = response.get("retrievalResults", []) # Step 2: Filter by relevance score — do not send irrelevant chunks MINIMUM_RELEVANCE_SCORE = 0.7 relevant = [r for r in results if r.get("score", 0) >= MINIMUM_RELEVANCE_SCORE] # If nothing is sufficiently relevant, say so rather than hallucinating if not relevant: return "NO_RELEVANT_CONTEXT_FOUND", [] # Step 3: Take only the top 5 after filtering — not all 10 top_results = sorted(relevant, key=lambda x: x.get("score", 0), reverse=True)[:5] # Step 4: Format for clarity — structure matters context_parts = [] sources = [] for i, result in enumerate(top_results, 1): content = result["content"]["text"] source = result.get("location", {}).get("s3Location", {}).get("uri", "internal-docs") score = result.get("score", 0) # Clearly label each source so the model knows where information came from context_parts.append( f"[Document {i} | Source: {source} | Relevance: {score:.2f}]\n" f"{content}\n" f"[End Document {i}]" ) sources.append({"source": source, "score": score, "index": i}) formatted_context = "\n\n".join(context_parts) return formatted_context, sources def build_message_with_context(user_query: str, retrieved_context: str) -> list: """ Build the complete message — user query + retrieved context, structured so the model knows what is instruction and what is data. """ if retrieved_context == "NO_RELEVANT_CONTEXT_FOUND": content = f"""Question: {user_query} Note: No relevant documentation was found for this specific question.

Please acknowledge that you don't have specific information about this and offer to escalate to a human agent.""" else: content = f"""Question: {user_query} Retrieved Context (use ONLY this information to answer): {retrieved_context} Answer the question using only the retrieved context above. If the context doesn't fully answer the question, say what you can confirm from the context and what would require further investigation.""" return [{"role": "user", "content": content}] The context engineering insight here: the model's answer quality is constrained by retrieval quality, not by prompt quality. Improving the prompt when retrieval is broken is rearranging deck chairs.

In multi-turn conversations and agentic systems, the conversation history is part of the context. And it grows with every exchange.

This creates two problems that context engineering must solve:

Problem 1: The context window fills up. At some point, the earliest messages fall out of the window. Important instructions given at the start get lost. The model contradicts itself because it cannot see what it agreed to ten messages ago.

Problem 2: Old content dilutes attention. Models pay more attention to content near the beginning and end of their context window. A long, unmanaged conversation history buries relevant recent information under a pile of older exchanges.

Context engineering solution: summarise and compress old history, keep recent history verbatim.

import anthropic import os client = anthropic.Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"]) class ConversationContextManager: """ Manages conversation history as context engineering. Keeps recent history verbatim, compresses older history into summaries. """ RECENT_TURNS_TO_KEEP = 6 # Last 6 exchanges verbatim SUMMARY_TRIGGER_LENGTH = 4000 # Summarise when history exceeds this token estimate def __init__(self): self.full_history = [] # Complete record self.summary = "" # Running summary of old history self.recent_messages = [] # Last N turns verbatim def add_turn(self, role: str, content: str): """Add a new message to the conversation""" message = {"role": role, "content": content} self.full_history.append(message) self.recent_messages.append(message) # Compress if history is getting too long if self._estimate_tokens() > self.SUMMARY_TRIGGER_LENGTH: self._compress_old_history() def _estimate_tokens(self) -> int: """Rough token estimate for current history""" total_chars = sum(len(m["content"]) for m in self.recent_messages) return total_chars // 4 def _compress_old_history(self): """ Move old messages from verbatim to summarised.

Keep only the last N turns verbatim. """ if len(self.recent_messages) <= self.RECENT_TURNS_TO_KEEP: return # Messages to summarise to_summarise = self.recent_messages[:-self.RECENT_TURNS_TO_KEEP] self.recent_messages = self.recent_messages[-self.RECENT_TURNS_TO_KEEP:] # Build text to summarise history_text = "\n".join( f"{m['role'].upper()}: {m['content']}" for m in to_summarise ) # Use the model to summarise — note: use a FAST, CHEAP model for this summary_response = client.messages.create( model="claude-haiku-4-5-20251001", # Haiku for summarisation — not Opus max_tokens=500, messages=[{ "role": "user", "content": f"""Summarise this conversation history in 3-5 bullet points. Capture: key decisions made, information provided by user, commitments made, unresolved issues.

Previous summary (if any): {self.summary} New history to add: {history_text} Return a concise bullet-point summary only.""" }] ) self.summary = summary_response.content.text def get_context_for_model(self) -> tuple[str, list]: """ Get the context to include in the next model call. Returns (summary_text, recent_messages_list) """ return self.summary, self.recent_messages # Usage manager = ConversationContextManager() # Simulate a long conversation exchanges = [ ("user", "I need help with my refund for order #12345"), ("assistant", "I can help with that. Can you confirm the email on the account?"), ("user", "It's emma@example.com"), ("assistant", "Found the order.

It was placed on July 1st for £49. You're within the 30-day window."), ("user", "Great, please process the refund"), #... many more turns ] for role, content in exchanges: manager.add_turn(role, content) # When making the next model call: summary, recent_messages = manager.get_context_for_model() system = f"""You are a customer support agent. {f"Conversation history summary: {summary}" if summary else ""} Use the conversation history and any retrieved context to help the customer.""" # The model gets: summary of old turns + last 6 turns verbatim # Not the entire unmanaged history Layer 4: Tool Results What the Model Has Discovered In agentic systems, the model calls tools, searches, database queries, API calls, code execution. The results of those tool calls become part of the context.

This is where agentic context engineering gets interesting. Tool results are often verbose, redundant, and poorly formatted for model consumption.

An API returns 50 fields when the model needed 3. A database query returns 200 rows when the question was about one customer. A web search returns 10 results, most irrelevant.

Context engineering for tool results means filtering and formatting before it hits the context window:

def format_tool_result_for_context(tool_name: str, raw_result: dict) -> str: """ Format tool results to be informative but not bloated. The model needs the signal, not the noise. """ if tool_name == "get_customer_account": # Raw result might have 30 fields.

Model needs 5. relevant = { "customer_id": raw_result.get("id"), "name": raw_result.get("full_name"), "subscription": raw_result.get("subscription_tier"), "account_status": raw_result.get("status"), "total_spent_gbp": raw_result.get("lifetime_value_gbp"), "member_since": raw_result.get("created_at", "")[:10] } # Strip nulls — they add tokens for zero information relevant = {k: v for k, v in relevant.items() if v is not None} return f"CUSTOMER ACCOUNT:\n{json.dumps(relevant, indent=2)}" elif tool_name == "search_transactions": transactions = raw_result.get("transactions", []) # If there are many transactions, summarise old ones if len(transactions) > 5: recent = transactions[:5] older_count = len(transactions) - 5 result = f"TRANSACTIONS (showing 5 most recent of {len(transactions)} total):\n" for t in recent: result += f" {t['date']}: £{t['amount']} — {t['description']} [{t['status']}]\n" result += f"... and {older_count} older transactions" else: result = "TRANSACTIONS:\n" for t in transactions: result += f" {t['date']}: £{t['amount']} — {t['description']} [{t['status']}]\n" return result elif tool_name == "search_knowledge_base": # Already handled by the retrieval layer above return raw_result.get("formatted_context", "No relevant information found") else: # Generic formatting for unknown tools return f"TOOL RESULT ({tool_name}):\n{json.dumps(raw_result, indent=2)[:500]}" Layer 5: Memory What the Model Remembers From Before This is the layer most developers add last, and most users notice first.

Memory is the mechanism that makes an AI feel like it knows you, because it actually does. It is information persisted from previous sessions that gets loaded into the context at the start of each new interaction.

Without memory, every session starts fresh. The model has no idea you told it last week that you prefer bullet points, that you are building a fintech startup, that your biggest pain point is AWS costs.

With memory, the context already contains that information before you type a word.

import boto3 import json from datetime import datetime, timezone dynamodb = boto3.resource('dynamodb', region_name='eu-west-1') memory_table = dynamodb.Table('user-memory') class UserMemory: """ Persistent memory for a user across sessions. Loads relevant memories into context at the start of each session. """ def save_memory(self, user_id: str, category: str, content: str, importance: int = 5): """ Save something worth remembering about a user. importance: 1-10, where 10 = always include, 1 = only if space permits """ memory_table.put_item(Item={ "userId": user_id, "memoryId": f"{category}#{datetime.now(timezone.utc).isoformat()}", "category": category, "content": content, "importance": importance, "createdAt": datetime.now(timezone.utc).isoformat() }) def load_memories_for_context(self, user_id: str, max_tokens: int = 500) -> str: """ Load the most important memories for this user.

Respects token budget — does not load everything. """ response = memory_table.query( KeyConditionExpression=boto3.dynamodb.conditions.Key('userId').eq(user_id), ScanIndexForward=False ) memories = response.get("Items", []) if not memories: return "" # Sort by importance — most important first memories.sort(key=lambda x: int(x.get("importance", 5)), reverse=True) formatted_memories = [] total_chars = 0 char_budget = max_tokens * 4 # Rough token to char conversion for memory in memories: memory_text = f"- [{memory['category']}] {memory['content']}" if total_chars + len(memory_text) > char_budget: break formatted_memories.append(memory_text) total_chars += len(memory_text) if not formatted_memories: return "" return "WHAT I KNOW ABOUT THIS USER:\n" + "\n".join(formatted_memories) # How this integrates into the full context assembly: memory_manager = UserMemory() def build_full_context(user_id: str, query: str, knowledge_base_id: str) -> dict: """ Assemble the complete context for a model call. This is context engineering in action.

""" # Layer 5: Memory — what we know from previous sessions user_memory = memory_manager.load_memories_for_context(user_id, max_tokens=300) # Layer 2: Retrieval — what's relevant to this specific question retrieved_context, sources = retrieve_context(query, knowledge_base_id) # Layer 1: System prompt — clean instructions, no embedded knowledge system_prompt = """You are a helpful customer support agent. Be accurate, concise, and friendly. Use retrieved context for factual information.

Use user memory to personalise. Never invent information not in the provided context.""" # Add memory to system prompt only if it exists if user_memory: system_prompt += f"\n\n{user_memory}" # Layer 2 goes into the user message, clearly labelled user_message = f"Question: {query}" if retrieved_context!= "NO_RELEVANT_CONTEXT_FOUND": user_message += f"\n\nRelevant context:\n{retrieved_context}" return { "system": system_prompt, "messages": [{"role": "user", "content": user_message}], "sources": sources } The Context Engineering Mindset Three Questions Prompt engineers ask: "how do I word this better?"

Context engineers ask three different questions:

Question 1: What information does the model need to answer this correctly?

This forces you to think about what is missing before you think about how to ask. Most AI failures are information failures. The model does not have what it needs. Better phrasing will not fix a retrieval problem.

Question 2: Where in the context window does this information live, and is that the right place?

Models pay more attention to the beginning and end of their context. Critical instructions and highly relevant information should be positioned accordingly. A policy buried in the middle of 50,000 tokens of context will be ignored. The same policy near the top will be followed.

Question 3: What is in the context that should not be there?

Every unnecessary token is a cost and a distraction. Old conversation history the model has already processed. Redundant retrieved documents. Tool results with 40 irrelevant fields. Bloated system prompts that could be tightened. Context engineering includes ruthless curation, removing what does not help, not just adding what might.

Retrieval pipelines, memory systems, context assemblers

Fix retrieval, add memory, curate context

Designed for multi-step, persistent systems

This table captures the relationship clearly: prompt engineering is still part of the picture. It is one layer inside context engineering, the instruction layer. The mistake is thinking that layer is the whole game.

Most AI application failures that get described as "the model is not following instructions" or "the model keeps hallucinating" are actually context failures. Here is how to diagnose which layer is broken.

The model gives outdated information → Retrieval problem. The knowledge base has stale documents. Or retrieval is returning old chunks over newer ones. Fix: update your knowledge base, add dates to chunks, add recency weighting to retrieval.

The model contradicts something it said earlier → History management problem. Old turns have been compressed or lost. The model is reasoning without context it needs. Fix: better conversation history management, summarisation, memory persistence.

The model "forgets" instructions after many turns → Context window management problem. The system prompt or early instructions have been pushed out. Fix: re-inject critical instructions periodically, or restructure context so key instructions appear near the user message.

The model makes up facts confidently → Retrieval failure or no retrieval at all. The model is filling information gaps from its training data. Fix: implement or improve RAG, add explicit "if not in context, say you don't know" instructions.

The model uses the right information but applies it to the wrong situation → Wrong chunks retrieved. Fix: improve chunking strategy, add metadata filtering, improve the query sent to retrieval.

The model ignores retrieved documents and uses training knowledge instead → Context structure problem. The retrieved information is not clearly labelled or positioned, so the model does not give it appropriate weight. Fix: restructure context to clearly separate retrieved information from instructions.

If you have an existing AI feature, here is the audit to run:

Audit Step 1: Map your current context. Print out the full context window for a real request. Look at exactly what tokens the model receives. Most developers have never done this. Most are surprised by what they see.

Audit Step 2: Identify what is missing. For each failure mode in your application, cases where the model gets the wrong answer, ask what information, if present, would have led to the right answer.

Audit Step 3: Identify what is irrelevant. Look at everything in the context window. For each element, ask: does this actually help the model answer this type of question? Remove what does not.

Audit Step 4: Check the structure. Is the most important information near the top or bottom of the context? Or buried in the middle? Restructure so critical content is positioned where the model is most likely to attend to it.

Audit Step 5: Test information presence, not prompt wording. Instead of testing "does rephrasing the instruction help," test "does adding the right information help." Inject the correct answer directly into the context and see if the model uses it. If it does, you have confirmed a retrieval problem, not a prompt problem.

Here is the career implication of this shift, the one that matters most if you are building AI professionally.

Prompt engineering was an individual skill. One person with a good intuition for language could make a model do impressive things. The barrier to entry was low. The ceiling was not high.

Context engineering is a systems engineering skill. It requires understanding data pipelines, retrieval architectures, memory systems, token budgeting, and how information flows through a complex system from source to model response.

These are not new skills for engineers, they are the same skills applied to a new kind of system. An engineer who understands distributed systems, database design, and data pipelines already has most of the mental models required. Context engineering is applying those models to the information environment that surrounds a language model.

This is why Karpathy named it the way he did. It is not "better prompting." It is engineering, systematic, architectural, measurable.

The developers building the most reliable AI applications in 2026 are not spending their time rewriting prompts. They are designing retrieval pipelines that return the right chunks. They are building memory systems that remember what matters. They are structuring context windows so the right information is in the right position. They are measuring what is in the context and what it produces, iterating on the information architecture rather than the instruction wording.

That is the shift. Prompt engineering is a tactic. Context engineering is the discipline that contains it.

Prompt engineering is about what you say to the model. Context engineering is about what the model knows when you say it.

Both matter. But in 2026, with capable models that follow instructions reliably, what the model knows has become the primary variable, and designing that knowledge environment is where the real engineering work lives.

Andrej Karpathy. Context Engineering the term that replaced prompt engineering. Twitter/X, mid-2025.

DEV Community / Gabriel HCA. Context Engineering: The Skill Replacing Prompt Engineering in 2026. https://dev.to/gabrielhca/context-engineering-the-skill-replacing-prompt-engineering-in-2026-3lgd

Neo4j. Why AI Teams Are Moving From Prompt Engineering to Context Engineering. September 2026. https://neo4j.com/blog/agentic-ai/context-engineering-vs-prompt-engineering/

MindStudio. What Is Context Engineering? Why It Matters More Than Prompt Engineering. https://www.mindstudio.ai/blog/what-is-context-engineering-vs-prompt-engineering

Atlan. Context Engineering vs Prompt Engineering: Key Differences 2026. https://atlan.com/know/context-engineering-vs-prompt-engineering/

daily.dev. What Is Context Engineering? The Skill Replacing Prompt Engineering in 2026. https://daily.dev/blog/context-engineering-skill-replacing-prompt-engineering/

JobsByCulture. Context Engineering Guide 2026: The Discipline That Replaced Prompt Engineering. https://jobsbyculture.com/blog/context-engineering-guide-2026

SurePrompts. Context Engineering: The 2026 Replacement for Prompt Engineering. https://sureprompts.com/blog/context-engineering-the-2026-replacement-for-prompt-engineering

Medium / Naisha Saxena. Why Context Engineering Matters More Than Prompt Engineering. https://medium.com/@naishasaxena2310/why-context-engineering-matters-more-than-prompt-engineering-92db85769d5c

Anthropic. Claude API Documentation System Prompts and Context Management. https://docs.anthropic.com/claude/

Emmanuela Opurum is a Solutions Architect and Cloud Engineer building AI-native cloud tooling and contributing to open source projects in the CNCF ecosystem. She writes about platform engineering, cloud architecture, and developer experience.

Building Production-Ready Multi-Agent AI Systems on Amazon EKS: The Complete Step-by-Step Guide