What is context engineering and is there a better alternative?

What Context Engineering Actually Involves

In practice, context engineering covers a range of decisions made at the moment an agent is deployed to a task. Which system prompt instructions take priority when they appear to conflict. How to format retrieved documents so the agent attends to the right parts. What background context to include to prevent the agent from making false assumptions. How to signal constraints without burying them in a block of text the agent will partially ignore.

Done manually, this is painstaking work. Each agent deployment requires a version of it. When the task changes, the context engineering changes. When the model changes, the assumptions underlying the engineering change. The people who do it well develop intuitions about how specific models respond to specific prompt structures — intuitions that are largely non-transferable and rarely documented.

At scale, it becomes a significant organisational overhead. Teams build internal prompt libraries, context templates, and retrieval heuristics — infrastructure for a problem that doesn't yet have a standard solution.

What Context Engineering is Compensating for

Most context engineering effort is doing work that would be unnecessary if the upstream knowledge layer were well-populated.

The decision about which constraints to include and how to phrase them is a consequence of those constraints not existing as structured, retrievable knowledge — they're in someone's head, or in a sprawling system prompt that predates the current task. The effort spent compressing background context into a token window is a consequence of that context not being organised in a form designed for agent consumption. A team building a proposal agent spends two weeks tuning the system prompt: which approval thresholds to include, how to phrase the risk appetite boundary, whether to embed pricing exceptions inline or retrieve them as an appendix. The underlying knowledge exists — distributed across a policy document, a pricing spreadsheet, and the head of the commercial director. The context engineering is doing the work of assembling it. Nobody asked whether it could be authored into a form that didn't need reassembling every time.

The iteration cycles spent tuning prompt structures are largely cycles spent compensating for the absence of authored context that would make the intent clear without tuning.

This isn't a criticism of context engineering as a practice. In systems where the upstream layer doesn't exist, it is the right response. The question is whether it's the best place to put the effort — because the work done at the assembly layer doesn't compound. A well-tuned prompt for today's task doesn't make tomorrow's task easier. It produces a template that will need tuning again when the model changes, the task changes, or the knowledge the prompt was built around becomes outdated.

Where the Effort Compounds instead

Upstream authorship compounds in a way that prompt-level engineering doesn't.

When the knowledge an agent needs is authored into a structured knowledge base before any prompt is written, the context assembly problem shrinks. The relevant knowledge surfaces to the context window because it was put there intentionally, in a form designed to be retrieved and used. The prompt becomes simpler because the context is already structured. The iteration cycles shorten because the agent is starting from a richer, more explicit brief.

Context engineering still exists in this model. Token limits are real. Retrieval relevance still needs calibration. Instruction structure still matters. But the manual labour of constructing context from scratch at the point of deployment — the part that doesn't scale and doesn't compound — is reduced by the quality of what was authored upstream.