A Job Title That Quietly Disappeared
In 2023, "prompt engineer" was a real job posting. The skill it described — finding the specific magic phrasing that reliably got a model to behave — was valuable because models were inconsistent, and small wording changes produced large behavioural swings.
That skill has mostly evaporated, not because prompting stopped mattering, but because it stopped being the bottleneck. Modern frontier and near-frontier models follow clear, well-structured instructions reliably enough that hunting for the one magic phrase is rarely where an agent's problems actually live anymore.
What replaced it is a discipline with a less catchy but more accurate name: context engineering — the deliberate design of exactly what information an agent sees, from where, in what order, and at what point in its task.
Why This Is a Systems Problem, Not a Writing Problem
A prompt is one artifact. Context is everything the model actually sees at inference time: the system prompt, yes, but also retrieved documents, tool call results, conversation history, injected metadata, and the order all of it arrives in. For any non-trivial agent, the system prompt is a small fraction of the total context — and increasingly, it's not the part that determines whether the agent succeeds or fails.
What actually reaches the model at inference time:
+-------------------------------------------------------+
| System prompt (~5% of tokens, static) |
| Retrieved RAG chunks (~30%, dynamic) |
| Tool call results (~25%, dynamic) |
| Conversation history (~30%, dynamic) |
| Injected metadata/state (~10%, dynamic) |
+-------------------------------------------------------+
95% of what determines behaviour is decided
BEFORE the model ever runs -- by what your
application chose to assemble and in what order.Prompt engineering optimises the 5%. Context engineering optimises the other 95% — and it turns out that's where most production failures actually come from.
The Failure Modes Context Engineering Actually Fixes
We see the same handful of problems repeatedly when auditing agents that "worked in testing" but degrade in production:
Context dilution. A RAG agent retrieves 8 chunks when the answer only needed 2. The relevant information is now buried in noise, and the model's attention gets spread thin across irrelevant text. This looks like a hallucination but is actually a retrieval-and-assembly problem — exactly what our RAG chunking work addressed, but at the point of *injection*, not just retrieval.
Stale context ordering. Conversation history gets appended chronologically by default, which means the most relevant recent instruction can end up buried under older, less relevant turns. Models tend to weight recent and prominent context more heavily — put the important thing last, not first, and don't assume chronological order is the right order.
Tool result bloat. A tool call returns a 4,000-token JSON blob when the agent needed three fields from it. Every subsequent step now pays the token cost and the attention cost of that bloat. Structured extraction *before* the result re-enters context, not after, is the fix.
Missing negative context. Agents are told what to do but not what they already tried and failed at. In a multi-step or retry scenario, omitting a compact summary of prior failed attempts means the model repeats the same mistake with fresh confidence every time.
What Context Engineering Looks Like Concretely
In practice, this is less about clever prompt phrasing and more about a few boring, disciplined choices, applied consistently:
// Prompt engineering mindset (2023):
// "Let's try rephrasing the instruction to be more emphatic"
systemPrompt = "You MUST always cite your sources. This is CRITICAL."
// Context engineering mindset (2026):
// "Let's control what evidence reaches the model and how it's structured"
const relevantChunks = await retrieveTopK(query, { k: 3, minSimilarity: 0.7 })
const structuredContext = relevantChunks.map(c => ({
source: c.documentTitle,
claim: c.content,
id: c.chunkId, // model cites this ID, not free text
}))
// Citation becomes a structural requirement of the output schema,
// not a hope expressed in the system promptThe second version doesn't ask the model to be careful. It removes the opportunity to be careless by controlling what's available and what shape the answer has to take.
The Practical Checklist
When we audit an agent's context engineering on AgentDyne, we're checking a short, concrete list:
None of these are prompt-wording questions. All of them are pipeline and data-flow questions, which is exactly why this discipline sits closer to backend engineering than to writing.
Why This Matters for Multi-Agent Systems Specifically
Context engineering gets harder, and more important, the moment you move from a single agent to a pipeline or swarm. In a chained pipeline, each node's output becomes the next node's input context — which means every design choice above compounds across the chain. A verbose, poorly-structured output from Node 2 doesn't just cost Node 2 quality; it dilutes every downstream node that has to consume it.
This is the same underlying reason output schemas mattered more than system prompts in our pipeline reliability findings from last year — schemas are the mechanism by which good context engineering gets enforced structurally, node to node, instead of relying on every agent in the chain independently "writing a good prompt."
The Skill That Actually Transfers
If you spent 2023 getting good at prompt engineering, the good news is the underlying instinct — thinking carefully about what a model needs to succeed — was never wasted. What's changed is where that instinct needs to be applied: not in finding the right words, but in designing the right data flow. That's a more durable skill, and it's the one we'd invest in learning if you're building agents for the next few years, not the next few months.