Context Engineering: The Skill That Replaced Prompt Engineering
Prompt engineering was one good instruction. Context engineering is controlling everything the model sees at inference: which files, which history, which tool results. Here is what it means, the four operations it breaks into, and why FDE and Applied AI interviews now screen for it.
BY ARJUN MEHTA · FDEINTERVIEWS EDITORIAL · UPDATED JULY 25, 2026 · 5 MIN READ
PRACTICE THIS:RAG and agent design questions ·LLM and GenAI questions ·The must-know FDE questions ·Core concepts, explained
Context engineering is the practice of controlling everything a model sees at inference time: the instructions, the retrieved documents, the prior conversation, the tool results, and the output schema you ask it to fill. The prompt you type is one small piece of that. Everything else is assembled by your system. Prompt engineering was writing one good instruction and hoping. Context engineering is designing the whole working set the model reasons over, and it is the shift that separates a dependable AI product from an expensive autocomplete. For forward deployed and Applied AI engineers, it has quietly become the core skill, and it is now what interviewers screen for inside the RAG and agent rounds, and it is one of the things that separates the AI forward deployed engineer role from the classic one. This post covers what it is, the four operations it breaks into, and how to show it in a loop.
From prompt to context to loop
There were three shifts in a few years, and most people only noticed the first one.
Andrej Karpathy gave the framing that stuck. In his Software 1.0 / 2.0 / 3.0 talk in 2025, he described the new mode as programming a model through context rather than through explicit code or trained weights. He defined the discipline as "filling the context window with just the right information for the next step." That sentence is the whole job. You are no longer writing deterministic instructions. You are curating what an intelligent interpreter sees before it acts.
Each level builds on the one before it. A merely adequate prompt inside a well-built loop usually survives. A perfect prompt on top of a cluttered context still fails. The leverage moved, which is a claim about where to spend your next hour rather than a licence to stop caring about the prompt.
| Level | What you optimize | What you write | Where it breaks |
|---|---|---|---|
| Prompt engineering | One instruction | The sentence | Great prompt, wrong context |
| Context engineering | The whole input window | Retrieval, state, formatting | Right context, no automation |
| Loop engineering | The system that builds context on repeat | The cadence, the verifier, the state | No gate, so it fails faster |
Loop engineering is where an FDE actually lives: not typing prompts at a customer site, but standing up a system that assembles the right context, acts, checks its own work, and runs again. The MLOps and agent design questions circle this constantly.
The four operations
A widely used taxonomy breaks context engineering into four moves. Almost every context problem you will debug is a failure of one of them.
- Write. Persist state outside the window so the model can read it back instead of holding everything in memory. A project conventions file, a running log of what worked and what failed, scratch notes between steps.
- Select. Retrieve only what is relevant for the next step. Not everything, not random chunks: the right handful of documents. This is where retrieval quality, chunking, and reranking earn their keep.
- Compress. When history grows too long, summarize the stale parts and keep fresh tool results at full fidelity. Reclaim tokens before the window fills.
- Isolate. Give a subtask its own clean context and let only the structured result flow back. This is why sub-agents exist: the main agent stays focused while a child handles a messy subtask in a separate window.
The failure these prevent has a name in practice: the window does not shrink, it gets cluttered. Irrelevant tokens pile up, the signal-to-noise ratio drops, and the model starts making worse decisions on the same task. The same model, given the same question, can pass or fail depending only on what else is sitting in the window when it answers. That is the entire reason this skill exists, and it is the intuition behind the embeddings and retrieval fundamentals.
How it shows up in the interview
Interviewers rarely say "context engineering." They test it through the symptoms.
- "Your RAG assistant sometimes answers from a document the user should not see. Walk me through it." That is a Select problem: retrieval scope and permissions.
- "The agent works for three turns then gets confused and repeats itself." That is Compress and Isolate: an unmanaged history that grows until the relevant instruction is buried.
- "The customer's knowledge base is far larger than the context window. How do you fit it?" That is the whole discipline at once.
The strong answer names the operation and the failure mode, then makes a call. Weak answers reach for "add more context" or "use a bigger model," which is exactly the instinct context engineering corrects. If you want the reps, the RAG and agent design set and the ML system design questions drill this reasoning directly, and the must-know set covers the failure modes that come up most.
Build the loop, and do not skip the verifier
Context engineering pays off when you wrap it in a loop that runs without you. In agentic coding tools like Claude Code (built by Boris Cherny at Anthropic), the primitives map straight onto the four operations: a project file the agent reads every session (Write), retrieval of the relevant files (Select), history compaction (Compress), and sub-agents with their own windows (Isolate). A working loop is assembled from a few pieces:
A working loop
State file persistent conventions + a log the loop reads each run (Write)
Retrieval load only the files relevant to this step (Select)
Sub-agents split the maker from the checker; each gets a clean window (Isolate)
Cadence run on a schedule or an event, not by hand
Verifier tests / schema / eval that MUST pass, or the run is rejected
The piece teams underrate is the verifier. A loop that generates and never checks its own work just produces wrong output faster. The gate, a test suite that has to go green, a schema the output must satisfy, an eval that must clear a threshold, is what turns "a model agreeing with itself on repeat" into automation you can leave running. In a customer deployment, that gate is the line between something you ship and something you babysit. It is also the honest reason evals keep coming up in these loops.
What it does not fix
Three honest caveats, because the skill gets oversold.
More context is not always better context. Past a point, extra tokens are noise, and a tight file of the right conventions beats a sprawling dump. The model still hallucinates inside a perfect context: good context reduces mistakes, it does not remove the need for a verifier. And it is a genuinely new skill that most teams do not have yet, which is precisely why it is worth building before an interview rather than during one.
Prompt engineering got the industry the first slice of value. Context engineering is where the rest of it lives. For a forward deployed or Applied AI role, that is not a trend to watch. It is the job. Start with the RAG and agent questions, keep the concepts library open for anything shaky, and if you are still mapping the role itself, the skills breakdown puts this in context.
Turn it into offers. Work the real questions and concepts this maps to:
FAQ
Context engineering is the practice of deciding everything a model sees at inference time: the instructions, the retrieved documents, the prior turns, the tool outputs, and the schema you ask it to fill. The prompt is one component. The context is the whole working set the model reasons over, and controlling it is what separates a reliable AI system from an expensive autocomplete.
Discussion (5)
The framing that finally made this click for me: the model is the CPU and the context window is RAM. Your job stopped being 'write a clever instruction' and became 'decide what gets loaded into RAM before each step'. Once you see it that way, retrieval quality, history compaction, and tool-output formatting are all the same problem.
That analogy carries a lot of weight in a design round too. If you can talk about token budget the way a systems engineer talks about a memory budget, deciding what to evict, what to keep hot, what to page out to disk, you sound like someone who has run these systems, not read about them.
Reader question: for an interview, how much of this do they expect you to have actually built versus just reason about? I have used retrieval but never hand-tuned an agent's context window.
Mostly the reasoning, at least below staff level. You do not need to have shipped a custom compaction strategy, but you should be able to say what you would compress, when, and what breaks if you get it wrong. Name the failure mode (an agent that re-reads its entire history every turn until it runs out of budget) and you have shown the judgment they are screening for.
The part teams underrate is the verifier. A loop that generates and never checks its own work just produces wrong output faster. In a customer deployment the gate (tests, a schema check, an eval that has to pass) is the difference between automation you can leave running and a demo you have to babysit.