Your Context Is Poisoned

Source: Dev.to

Context Engineering Framework

Lance Martin at LangChain published a framework for context engineering with four operations—Write, Select, Compress, and Isolate—each with its own failure mode. Mapping these to production data from our six‑agent autonomous system revealed 4,768 violations, all traceable to one of the four poisoned‑context patterns.

Failure Mode 1: Stale Context (Write)

Your agent’s instructions were written three sprints ago. The API changed, the schema migrated, and the agent keeps generating code against a version of reality that no longer exists.

Symptoms

• CLAUDE.md files reference moved file paths.
• Constraints cite superseded specs.
• Patterns enforced by the codebase weeks ago are still used.

Fix – Structural enforcement via L5 hooks that validate context freshness before the agent acts

• When an instruction references a file path, the hook verifies the path exists.
• When a constraint cites a spec, the hook confirms the spec is still active.

Detection tools only tell you the context was stale after broken code is shipped. Prevent‑by‑construction hooks stop stale context from reaching the agent in the first place.

Failure Mode 2: Missing Context (Select)

The agent has a 200 K‑token window but selects only a fraction—e.g., 40 K of conversation history, 20 K of file contents, and zero bytes of the crucial configuration.

Label

“context gap” violations.

Example

An agent makes a decision that would have been correct if it had first read the repo’s CLAUDE.md, but nothing forced it to do so.

Fix – Mandatory context loading enforced by L5 hooks

• Before a coder agent touches any repo, a hook verifies it has read the repo’s CLAUDE.md.
• Before responding to an operator message, the agent must check its inbox.

These are automated gates that block execution until the required context is loaded.

Failure Mode 3: Bloated Context (Compress)

Large context windows (200 K tokens) can become unwieldy after an agent reads many files, runs commands, and accumulates conversation history. Compression then drops older messages.

What gets dropped first?

System prompt, behavioral constraints, and top‑level instructions.

Impact

Agents averaged 12 rule violations per day after compression events, silently forgetting their own rules every ~45 minutes.

Fix – A pre‑compaction memory‑flush hook

• At 150 tool calls, the hook writes critical context to persistent storage before compression.
• When compression occurs, the saved knowledge survives on disk.

Failure Mode 4: Leaking Context (Isolate)

In multi‑agent systems, constraints from Agent A can leak into Agent B’s context, causing unintended influence across roles.

Observed issue

The coder agent began applying strategic directives meant for the CEO agent, making product decisions without authority.

Fix – Structural isolation at the data‑access layer

• Each agent’s context is bounded.
• Cross‑agent signals follow a defined routing protocol (e.g., the coder cannot read the CEO’s mailbox; the oracle cannot modify the coder’s priorities).

The Numbers

• 4,768 total violations detected across six agents
• 18 violations promoted to structural enforcement (L3‑L5)
• 477:1 violation‑to‑promotion ratio – a measure of self‑improvement velocity
• < 5 % regression rate on violations that received L5 enforcement

Detection finds violations; enforcement makes them impossible. This distinction separates mere monitoring from true context engineering.

What This Means for Your System

If you run AI agents in production—coding assistants, research agents, autonomous workflows—your context is likely poisoned in at least one of these four ways. The failure modes can be silent, with agents confidently producing output from degraded context.

The key question isn’t whether your context is clean; it’s whether your system can detect and prevent context poisoning structurally, before the agent acts.

• Run a scan on your repository to assess your context‑engineering health.

Originally published at walseth.ai