Context Engineering Is Risk Engineering

Context Engineering Is Risk Engineering

Prompt engineering was the warm-up.

For agents, the harder problem is context: the full operating state the model receives across instructions, tools, memory, retrieval, files, message history, MCP servers, examples, summaries, and prior decisions.

Anthropic’s context-engineering framing is useful because it names the real shift. Agent behavior is not shaped by a single clever prompt. It is shaped by a constantly changing universe of information selected into a limited context window.

That is an engineering problem. It is also a risk problem.

Context decides what the agent treats as real

An agent acts on what it can see.

If the context includes stale policy, the agent may enforce yesterday’s boundary. If the context excludes critical constraints, the agent may optimize past them. If retrieved material is polluted, the agent may faithfully summarize bad evidence. If tool descriptions are too broad, the agent may overestimate what it should do. If memory is noisy, the agent may carry forward the wrong assumption.

None of those failures require the model to be malicious.

They emerge from the context architecture.

This is why “the model hallucinated” is often too narrow. A production agent can fail because its context was too large, too stale, too compressed, too contaminated, too permissive, or too poorly separated between trusted and untrusted material.

Context rot becomes operational drift

Long-horizon agents need to manage state over time. They summarize. They compact. They write notes. They call sub-agents. They retrieve old decisions. They infer continuity from partial traces.

Each move can be useful. Each move can also create drift.

A summary may drop the exception that mattered. A memory note may preserve an outdated assumption. A retrieval system may surface the most semantically similar source rather than the most authoritative one. A tool list may include capabilities irrelevant to the task but available to the agent anyway.

Over time, the agent’s effective operating state can diverge from the organization’s intended policy.

That is context rot as a governance failure.

Trusted and untrusted context need different lanes

The most important context distinction is not short versus long. It is trusted versus untrusted.

A policy file, a user message, a webpage, a support ticket, an email, a tool description, a vendor document, and an internal approval record should not enter the agent’s reasoning with the same authority.

They may all be text. They are not all commands. They are not all evidence. They are not all policy.

A mature agent architecture should preserve those distinctions:

If everything becomes one blob of helpful text, the agent inherits a confused world model.

• durable policy separate from user-provided content;
• tool permissions separate from model suggestions;
• retrieved evidence labeled by source class;
• memory entries with provenance and freshness;
• summaries that preserve constraints and unresolved exceptions;
• context compaction that does not erase control boundaries.

The bottom line

Context engineering is not just about getting better answers. It is about deciding what an AI system is allowed to know, trust, remember, and act on.

That makes it part of enterprise risk architecture.

The companies that deploy agents successfully will not merely write better prompts. They will build context systems that preserve provenance, authority, policy, freshness, and evidence under pressure.

The agent fails where its context rots.