The Forward Deployed Playbook · EP02
Context engineering: turning business rules into agent behavior
Context engineering is the work of deciding what an AI agent sees at each step of a task: its instructions, the domain rules, retrieved data, tool definitions, earlier results and memory. Anthropic defines it as curating the optimal set of tokens during inference. In a deployment it is how a customer’s business knowledge, rules and permissions become the behavior of the system, and it decides more of the outcome than the choice of model.
What goes into an agent’s context?
Six layers, each with a different owner and a different rate of change. When an agent misbehaves in production, the cause is usually one layer missing or one layer doing another layer’s job.
| Layer | What it holds | Changes |
|---|---|---|
| Standing instructions | Role, goal, tone, what “done” means | Rarely |
| Domain rules | The business’s policies, definitions and exceptions, written down | When the business changes |
| Retrieved knowledge | Documents and records fetched for this task only | Every task |
| Tools and permissions | What the agent can call, on which data, as whom | Per deployment |
| Working state | Results of earlier steps, summarised as the task runs | Every step |
| Memory | Notes kept between sessions | Over weeks |
How do you turn a customer’s domain knowledge into context?
By watching the work before writing anything. The documented process is the version people describe in meetings; the real process lives in the exceptions they handle by hand. A practical sequence:
- Observe users doing the task for a few days, and log every case where they deviate from the written procedure.
- Question the requirements until each one is testable. “Flag risky invoices” becomes a list of conditions someone can check.
- Investigate exceptions with the person who handles them, and write down the rule they apply and why.
- Write the rules file in plain language, versioned beside the code, owned by a named domain expert.
- Turn each exception into a test case, so the next change to the context is checked against it.
Which business rules belong in context, and which in code?
Put judgment in context and hard limits in code. A model reads its context as guidance and can weigh it against everything else it sees, so an instruction like “never refund more than $500” is a request, not a control. A tool that cannot issue a refund above $500 is a control. The decision rule I use:
- In context: definitions, tone, priorities, how to handle ambiguous cases, examples of good output.
- In code and permissions: money limits, data access, who the agent acts as, anything a regulator or auditor would ask about.
- In both: the rule in context so the agent plans around it, and the enforcement in code so it cannot break it.
Our own editorial intake follows the same split. Agents that suggest article ideas get a token that can only create ideas, and the server stores only a hash of it. The context tells them what a good idea looks like; the permission makes sure that creating ideas is all they can do.
How do you keep the context small enough to work?
By loading information when the task needs it instead of up front. Anthropic’s guidance names the main techniques, and they match what holds up in production:
- Just-in-time retrieval: give the agent references such as file paths or saved queries, and let it load the data when a step needs it.
- Compaction: near the limit, summarise the task so far and continue from the summary.
- Structured notes: the agent writes progress to a file outside the window and reads it back later.
- Sub-agents: hand a focused subtask to an agent with a clean window, and take back only its summary.
What does context engineering look like in our own deployments?
Every content site we run carries a voice file that agents must load before drafting, a pinned shared vocabulary, and an agent instructions file with a grounding block that points to both. This page was written that way. The publishing rules themselves are a context file too: one shared document that every editorial repository imports, so a change to the rules reaches every site’s agents at once.
The exceptions taught us the most. When we pointed an agent at public Instagram profiles to collect story ideas, the documented behavior held for a few profile loads and then hit a login wall. No requirements document would have contained that. The fix went into the agent’s rules as a constraint: read the posts embedded in a single profile load, and stop.
How do you test a change to the context?
The same way you test code: a fixed set of real tasks, including the exceptions you logged in discovery, run before and after every change. If the pass rate drops on any exception, the change does not ship. Our guide to AI agent evaluation covers how to build that set. What context engineering adds is ownership: each rule has a named owner in the customer’s business, so when the business changes, someone knows which line of context to change with it.
Measured against what? Against the outcome metric from EP01. Context that passes every test but does not move the business number is still wrong context.
Sources: Anthropic, “Effective context engineering for AI agents” (29 September 2025) · examples from our own agent operations, November 2026.
Context engineering: common questions
What is the difference between context engineering and prompt engineering?
Prompt engineering is writing a good instruction. Context engineering is deciding everything the model sees at each step of a task: the instruction, the domain rules, the retrieved documents, the tool definitions, the results of earlier tool calls and any memory. For a one-shot answer the two are nearly the same. For an agent that runs dozens of steps, the prompt is a small part of the context.
Is context engineering the same as RAG?
No. Retrieval-augmented generation is one technique inside context engineering: fetching relevant documents into the context. Context engineering also covers what you leave out, how you write the standing rules, which tools the agent gets, how earlier steps are summarised and how memory is stored between sessions.
Who does context engineering in a company?
Whoever understands the business process and can write it down precisely. In an AI deployment that is usually the forward deployed engineer or the internal AI engineer, working with the domain experts who know the exceptions. It is engineering work because the context is versioned, tested and changed like code.
Does a bigger context window remove the need for context engineering?
No. Anthropic’s engineering team describes context as a finite resource with diminishing returns: recall gets worse as the window fills, an effect often called context rot. A larger window lets you include more, but the agent still behaves best on the smallest set of high-signal information that covers the task.
