What context engineering is

Why the prompt is not enough

In a chat, the instruction is almost everything the model reads. In an agent system, it is a small part. The rest is context: loaded files, session history, tool descriptions, project rules and what other agents produced earlier.

More context does not mean a better result. CL-Bench, cited in experiment #007, indicates that 76% of the context loaded into LLMs is ignored. The problem is rarely a lack of instruction. It is almost always too much material.

The four ways context fails

1. Poisoning. A wrong piece of information enters the context and is treated as truth in the answers that follow.
2. Distraction. The context is so large that the model loses sight of the current task.
3. Confusion. Irrelevant material changes the answer, even though it has nothing to do with the request.
4. Clash. Two parts of the context say different things, and the model picks one without saying so.

All four were validated in the same experiment, from a Gemini 2.5 study. Each calls for a different fix, so it is worth knowing which one is happening before changing anything.

What a well-designed context has

1. Only what the step needs. If the answer does not change without an item, it goes.
2. Separate context per agent. Each agent works with its own context, and one error does not contaminate the rest of the system.
3. Rules as limits. Saying what never to do tends to hold better than listing what always to do.
4. Verification outside the model. What needs to be right is checked by a test, not by the model's own opinion.

How this shows up in my systems

In ATHENA OS, each worker agent runs with its own context. In the context engineering squad from experiment #007, the architecture rule was "agents think, skills execute": fewer agents, each with its full frameworks and no external references. In experiment #009, a single voice file with explicit limits kept 10 agents writing in the same voice across 9 pages.