When an agent gives a bad answer, the instinct is to rewrite the prompt. Often the better question is: what did the model actually see? A well-worded instruction cannot compensate for a missing fact, a wrong document or a context full of noise.
That shift in attention is what people now call context engineering.
What the term means#
Anthropic's engineering team, in a post published on 29 September 2025, describes context engineering as choosing and maintaining the whole set of information a model sees when it runs, not only the wording of the prompt. The aim is to get the behaviour you want from it.
For a workflow builder, that is a concrete list. At any step where a model runs, the context is made of:
- Instructions: the role, the rules and the output format.
- The task input: the message, email or record that started the run.
- Retrieved knowledge: passages pulled from documents.
- Tool descriptions and results: what the agent can call and what came back.
- History: earlier turns, or earlier steps' outputs.
- State: values you carry from step to step.
You control all six. Most quality problems come from one of them being missing, stale, too long or contradictory.
The problem with more#
It is tempting to give the model everything, because windows are large. The same post describes "context rot": as the window fills, the model's ability to recall information tends to drop. Every token competes for attention, so context is a limited resource, even when the maximum size looks generous.
The practical rule: include what is needed for this step, and nothing the step does not need. A triage step that classifies an email does not need the whole policy manual. A drafting step does need the relevant section.
A checklist, step by step#
1. Say what the step is for#
Give each model step one job. "Classify this ticket into one of these six categories and give a one-line reason" will behave better than "handle this ticket". Small steps are also easier to test, and the run trace shows exactly what each one received.
2. Put stable rules in instructions, not in data#
Instructions are for things that stay true: tone, boundaries, output format, when to escalate. Facts that change, such as prices or opening hours, belong in a knowledge base or a lookup, so you can update them without editing the agent.
3. Retrieve, do not paste#
For a policy question, retrieval from a knowledge base returns the relevant passages instead of the whole document. In Cadrix, a knowledge base is built from sources, chunks, embeddings and a vector store, and you can preview the chunks and query the store before you attach it to an agent. The run trace shows what the agent was given, so you can check that the right passage arrived.
Anthropic describes a related idea, just-in-time retrieval: instead of loading all the relevant data up front, the agent keeps lightweight references such as queries or file paths and loads content with tools when needed. In a workflow, this is the difference between stuffing a customer's full history into the prompt and giving the agent a lookup tool.
4. Pass state explicitly#
Values that matter later, such as the customer ID, the order number or the decision so far, should be carried as named values and not left inside a long conversation. Explicit state is easier to read in a trace and harder to lose.
5. Trim tool output#
A tool that returns a 40-page JSON blob will drown the model. Add a step that selects the fields the next step needs. Anthropic lists clearing old tool outputs as a light form of compaction.
6. Summarise when a run gets long#
For long-running work, the post describes compaction: summarise the conversation when it nears the limit and continue in a fresh window with the summary. It also describes structured note-taking, where the agent writes progress to storage outside the window and reads it back later. In a workflow, the equivalent is an explicit step that writes a short summary, and later steps use that instead of the full history.
7. Split work across agents when the context diverges#
Another pattern in the same post is sub-agents: specialised agents handle focused tasks in clean windows and return condensed summaries to a coordinating agent. That is sensible when subtasks need very different information. It is also more complex, and more expensive. Start with one agent and split when you can show the context is the problem.
Retrieval versus memory versus state#
These get confused:
| Question | Use |
|---|---|
| "What does our policy say?" | Retrieval from a knowledge base |
| "What did this customer say last week?" | A lookup of a stored record |
| "What have we decided so far in this run?" | State carried between steps |
| "What does this user always prefer?" | A stored preference with an owner and an expiry |
If you cannot say which row your problem is in, you will probably build the wrong thing.
Debug by reading the context#
The best habit is cheap: open the run trace for a bad answer and read what the step received. Ask:
- Was the fact present at all?
- Was it correct and current?
- Was it buried among irrelevant material?
- Did two parts of the context contradict each other?
- Did the output format instruction survive, or get lost in the middle?
Fix the context, run again, and compare. That is a faster loop than rewriting prompts blindly.
If you want to measure whether a change helped, run a fixed set of test inputs before and after. Cadrix has datasets and evaluations for that; our evaluation guide covers how to build the set.
Where the human goes. The person who owns the content. Every knowledge source and every instruction block should have a named owner who updates it, because stale context is the most common cause of confident wrong answers. For consequential outputs, put a reviewer after the model and before the action.
What this will not fix#
Better context improves reliability. It does not make a model infallible, and it does not replace approval steps for actions you cannot undo. Treat it as the first thing to check when quality is poor, not the last word on safety.
Sources#
- Anthropic Engineering, "Effective context engineering for AI agents", 29 September 2025: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- Anthropic documentation, "Memory tool": https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool
