January 28, 2026
By Manu Ebert · Founder
Prompt engineering is not dead. But it is no longer enough.
In 2023, the prevailing wisdom was that the quality of your AI application depended on how well you wrote your prompts. That was true when LLMs handled simple text generation. It breaks down when you are building agents that operate in the real world, across multiple sessions, with knowledge of the user's actual data.
Context engineering vs prompt engineering is not a debate about which one wins. It is a shift in what matters most. Context engineering emerged because agents need more than instructions. They need knowledge about the world they operate in. The term took off in mid-2025 when Andrej Karpathy and Shopify CEO Tobi Lütke both endorsed it as a better description of what building with LLMs actually requires.
Prompt engineering is the practice of designing the instructions, formatting, and examples that guide an LLM's behavior for a specific task.
It covers the text you write to tell a model how to act. System prompts. Output formatting rules. Few-shot examples. Chain-of-thought scaffolding. Guardrails that keep the model on track.
Prompt engineering still matters. It sets the tone, defines the task, decomposes complex problems into steps, and controls output quality. A well-written prompt is the difference between clean JSON and a rambling paragraph. Anthropic's guide on context engineering makes this point clearly: system prompts should "strike a balance between being specific enough to guide behavior effectively while remaining flexible enough to provide strong heuristics."
Where prompt engineering falls short is what it does not cover: the knowledge the model needs to do its job. You can write the most precise instructions in the world, but if the model does not know who the user is, what their calendar looks like, or what happened in yesterday's conversation, those instructions accomplish very little.
Context engineering is the discipline of designing what information an AI agent receives, when, and in what format, so it can act usefully.
This is a superset of prompt engineering. The prompt is one component within the broader context the model sees. Context engineering also includes the knowledge, memory, relational data, and real-time information the agent needs.
Karpathy described it as "the delicate art and science of filling the context window with just the right information for the next step." That "just the right" is the key phrase. Not everything. Not nothing. The right information, for this specific query, at this specific moment.
The shift happened because agents moved from "answer this question" to "accomplish this task across multiple systems over time." A chatbot that answers FAQ questions can run on prompts alone. An agent that manages your sales pipeline, drafts personalized follow-ups, and remembers that a prospect cares about SOC 2 compliance needs context no prompt can contain.
At Hyperspell, we describe this through the Four Layers of Agent Context: instruction context (prompts), knowledge context (documents and data), relational context (who the user is and how entities connect), and temporal context (what changed recently). Most teams only build the first two layers. Layers three and four are where agents stop feeling generic.
The core difference is scope: prompt engineering designs how you instruct the model, while context engineering designs the full information environment it operates within.
Dimension | Prompt Engineering | Context Engineering |
|---|---|---|
Scope | Instructions to the model | The full information environment |
Focus | How you ask | What the model knows |
Persistence | Per-request | Across sessions |
Data sources | Static examples in the prompt | Live data from external systems |
Optimization target | Output quality per query | Agent capability over time |
Complexity | Text crafting | Systems architecture |
When it matters most | Single-turn tasks | Multi-step, multi-session agents |
In plain English: prompt engineering is a skill. Context engineering is a discipline. One person can write excellent prompts. Context engineering requires data pipelines, retrieval systems, memory infrastructure, and a strategy for what to include and what to leave out.
The relationship is not adversarial. Every good context engineering stack includes well-crafted prompts. But the prompts are one layer, not the whole system.
The shift happened because AI applications evolved from single-turn chatbots to multi-step agents that need persistent, personalized knowledge. Three forces drove it.
Agents replaced chatbots. The LangChain State of AI Agents report, a survey of more than 1,300 professionals, found that 51% of respondents already run AI agents in production, and 78% have active plans to. These agents handle multi-step work: scheduling meetings, managing pipelines, writing code across repositories. Multi-step tasks require persistent knowledge, not good instructions alone. An agent that forgets the user's preferences after every session is useless for real work.
Context windows grew, but the selection problem did not shrink. Models now accept a million or more tokens. That does not help if you do not know which tokens to include. Research on the "lost in the middle" problem shows models perform worse when relevant information is buried in long contexts. A bigger container is not a smarter selection process. Context engineering is the selection layer.
Personalization became table stakes. Users expect agents to know their preferences, history, and relationships. "My agent has no idea who the user is" is the most common frustration we hear from teams building on Hyperspell. Prompt engineering cannot solve this. You cannot write a user's entire relationship history into a system prompt. You need a memory layer that stores, retrieves, and reasons over that data.
This mirrors an earlier era of computing. Static web pages embedded their content in the HTML. Web applications pulled content from databases. The page still mattered, but the data layer made it useful. Prompt engineering is the page. Context engineering is the data layer.
Prompt engineering gets you to a demo. Context engineering gets you to production. Four practical implications follow.
You need a data ingestion strategy, not just a prompt template. Your agent needs access to the user's actual data: email, Slack, calendar, CRM, documents. That means OAuth integrations, API pagination, rate limiting, and normalization across dozens of sources. Hyperspell handles this with 50+ pre-built integrations and managed OAuth, so teams focus on their agent's core logic rather than months of plumbing.
A conversation buffer is not a memory layer. Storing the last N messages is not memory. Real memory means persisting user preferences, interaction history, learned workflows, and entity relationships across sessions.
You need a retrieval system, not just a larger context window. Semantic search, keyword matching, and knowledge graph traversal working together. The goal is not to fill the context window. It is to fill it with the right information.
What you exclude matters as much as what you include. Context assembly is a filtering problem. Which memories are relevant to this query? Which are stale? Which add noise? This is where context engineering becomes an ongoing discipline, not a one-time setup.
You do not have to build all of this from scratch. Data ingestion alone typically costs 3-6 months of engineering. Teams that want to ship faster use managed infrastructure like Hyperspell's memory and context layer while they focus on what makes their agent unique.
Prompt engineering and context engineering are layers in the same stack. The best AI agents will have both: well-crafted prompts and rich, relevant context delivered at the right moment. The teams investing in the context layer now are building agents that compound their usefulness with every interaction.
No. Prompt engineering remains essential for defining how an agent behaves, what format it produces, and what guardrails it follows. What changed is that prompt engineering alone is no longer sufficient for production agents. Context engineering encompasses it and adds the knowledge, memory, and retrieval layers agents need to act on real-world data.
Yes. Managed platforms handle the data ingestion, OAuth, indexing, and retrieval components so you can focus on your agent's core logic. The alternative is building these systems from scratch, which typically takes 3-6 months of engineering time for data pipelines alone.
RAG (retrieval-augmented generation) is one technique within context engineering. It retrieves documents from a vector store and injects them into the context window. Context engineering is broader: it also includes relational data, temporal awareness, memory lifecycle management, and context assembly. RAG is one tool in the toolbox.
Not necessarily. A single-session chatbot answering FAQ questions can work well with prompt engineering and a static knowledge base. Context engineering becomes important when your agent interacts with the same users over time, needs to remember preferences, or operates across multiple data sources and sessions.
Prompt engineering designs how you instruct the model. Context engineering designs the entire information environment, including knowledge, memory, and real-time data.
Context engineering is a superset of prompt engineering, not a replacement. Every context engineering stack includes well-crafted prompts.
Three forces drove the shift: agents replacing chatbots, context windows growing without solving selection, and personalization becoming a baseline expectation.
Larger context windows do not solve the selection problem. Context engineering is knowing which information matters for each specific query.
For developers, the practical shift means investing in data ingestion, memory layers, and retrieval systems alongside prompt design.