Prompt engineering is dead. Context engineering is the job now.

Two years ago, "prompt engineering" was the skill everyone wanted on their resume. Get the wording right, add a few examples, maybe a system prompt with some stern instructions about staying in character, and the model behaved. That world is mostly gone. The prompt is still there, but it's the smallest part of what makes an agent reliable now.

What actually determines whether an agent works is context: what information it has access to, how that information is structured, and when it shows up in the conversation. Call it context engineering if you want the industry term, though the actual skill is closer to information architecture than anything to do with writing clever instructions. You're deciding what the model sees, in what order, and what gets left out — because leaving things out turns out to matter as much as including them.

The reason this became urgent rather than optional is a finding that's now well established: every frontier model gets measurably worse as its context window fills up, and it starts happening long before you hit the stated limit. Stuff sixty pages of tool definitions, retrieved documents, and conversation history into a single call, and the model doesn't fail loudly — it just gets quietly worse at the thing you actually asked it to do. We've watched this happen on client agent builds: accuracy that holds at 94% on a clean, short context drops into the low 80s once real production context — full conversation history, several tool schemas, a retrieved document or two — gets added, with nothing else about the task changing.

The fix isn't a bigger context window. Bigger windows just mean you can pack in more of the wrong stuff before things degrade. The fix is treating context as a budget you spend deliberately: retrieve only what's relevant to this specific turn, summarize or discard history that's no longer load-bearing, and give the model tool definitions for the two or three tools it might plausibly need right now, not the fifteen it might need across the whole conversation.

In practice that means building a context pipeline the same way you'd build any other part of a production system — with monitoring, not vibes. We log what actually went into context for every agent call in production, not just the final response, because when an agent gets something wrong the fastest way to find out why is almost always "what did it actually see when it answered." Most of the time the model wasn't wrong. It was reasoning correctly over context that was incomplete, stale, or so bloated the relevant fact was buried on page four of a document dump.

In practice, a context pipeline usually has four separate jobs, and treating them as one blob is where most implementations go wrong. Retrieval decides what's even a candidate for inclusion — a vector search, a keyword filter, a database lookup, whatever fits the data. Ranking decides which of those candidates actually earns a seat in this specific call, not just anything that matched. Compaction handles everything that's already in the conversation: summarizing a five-turn exchange into two sentences once the details stop being decision-relevant, dropping a tool result once its information has been acted on. And tool selection means the model gets schemas for what it might need this turn, not a standing catalogue of every capability the agent has ever had. Skip any one of those four jobs and the others end up doing double duty badly — ranking without compaction just means a slowly growing pile of "relevant" material that never gets smaller.

The other piece people underbuild is memory that actually persists across a session instead of resetting every conversation. A support agent that's talked to the same customer three times this month should walk into the fourth conversation already knowing what the first three were about, without replaying full transcripts into context every time. That means a short-term working memory — this conversation, mostly verbatim — separate from a long-term store that holds distilled facts: what this customer's actual issue pattern looks like, what's already been tried, what didn't work. Building that split is more engineering than most teams expect going in, but it's the difference between an agent that starts fresh every time and one that actually gets better at a specific relationship the longer it runs.

The obvious objection is that context windows keep growing, so isn't this a problem that solves itself in eighteen months? It doesn't, for two reasons. First, the degradation isn't primarily about hitting a hard token limit — it's attention dilution, the same model paying measurably less attention to any given fact as the volume of surrounding text grows, and a bigger window just moves the point where that starts, it doesn't remove it. Second, every token in context costs money and latency whether the model needs it or not, so "just include everything, the window's big enough" is also the most expensive and slowest way to run an agent even on the calls where it happens to still work. Engineering the context down to what's actually needed isn't a workaround for small windows. It's just better engineering, and it stays better engineering as windows keep growing.

A concrete version of this from a document-processing agent we built: early versions received the entire source document as raw text on every single tool call, because that was the simplest thing to wire up. Accuracy was fine on short documents and quietly degraded on anything past about fifteen pages, exactly matching the pattern the research predicts. The fix wasn't a smarter model or a longer prompt. It was chunking the document once, indexing the chunks, and giving the agent a retrieval tool instead of the raw text — so each call saw the two or three chunks actually relevant to the current step, not the whole document repeated every time. Accuracy on long documents went from noticeably worse than short ones to statistically indistinguishable, and the average call got cheaper and faster in the same change, because it was moving a fraction of the tokens per request.

None of this shows up in a demo. A five-turn demo conversation never gets close to the context pressure a real support agent hits by turn thirty, or that a document-processing agent hits an hour into a long queue. That gap — between what looks fine in a demo and what survives a real shift's worth of production traffic — is where most agent projects that "worked in testing" quietly start failing once they ship. If you're evaluating an agent before launch, test it at the context load it'll actually see in week three, not the clean slate it starts with in week one.

If you're starting from an agent that already exists and already misbehaves sometimes, the fastest diagnostic isn't a bigger model or a rewritten prompt — it's pulling the actual logged context from ten recent failures and reading it the way you'd read a stack trace. In practice, most of those ten will show the same shape of problem: a stale fact that should have been dropped, a tool result that was never summarized down, or a document chunk that got included because it matched a keyword but wasn't actually relevant to the question being asked. Fix the pipeline that let that context in, and the failure rate usually drops before you've touched a single word of the prompt itself.