Context engineering starts with your processes, not your prompts

The field moved from prompt engineering to context engineering for a good reason. A clever prompt gets a model to behave once. It does not get an agent to act correctly across thousands of real cases, each with its own conditions. So the attention shifted to what goes in the window: instructions, memory, retrieved documents, tool outputs, all fit inside a budget. That was the right move. It just stopped one layer short of the thing that matters most.

What the common framing gets right, and where it stops

The standard account of context engineering has three pillars. Memory: what the agent remembers from earlier turns and sessions. Retrieval: what it pulls from your documents when a query matches. Token budget: how you fit the useful parts into a finite window without drowning the model in noise. All three are real, and teams that manage them well get better agents than teams that do not.

But notice what all three treat as given: the process. Memory assumes the agent already knew the right procedure and just needs to recall the conversation. Retrieval assumes the correct route is sitting in a document waiting to be matched. Token budgeting assumes the hard part is fitting the context in, not deciding what the context should be. In regulated operations, none of those assumptions holds. The process is often the least legible thing in the whole stack, and it is the thing the agent most needs.

The most durable context is the process

Sort the kinds of context by how long they stay true. Chat memory is true for one conversation. A retrieved document is true until it drifts, which no one gets a signal about. The process, done right, is true across every case and every session: this is how the work goes, this is who owns each step, this is what must hold before the next one, this is what changed last month and who signed it off. That is the stable spine everything else hangs on.

Which means the order most teams use is backwards. They engineer memory and retrieval to reconstruct a process the agent never had cleanly, then wonder why it acts plausibly and wrong. Give the agent the current, governed process directly and most of the retrieval evaporates, because the agent is no longer scraping ten pages to infer the route. It is reading the route. This is the same reason a process record is the piece AI agents actually need: the model was rarely the bottleneck, the missing legible process was.

Why more retrieval is not the fix

The instinct when an agent acts wrong is to feed it more: a bigger window, more retrieved pages, a richer memory store. That makes the core problem worse. Retrieval fetches prose, and prose is exactly where the ambiguity hides. Pull the SOP library into context and the agent now holds the current route, the stale paragraph, and the retired exception side by side, with no marker for which is live. You have not added clarity. You have added confident-sounding noise for the model to average over.

A legible process record does the disambiguation before the window. It resolves the case to one governed route: the steps that apply here, current and signed off. That is fewer tokens carrying more certainty. Prompt engineering could not close this gap because it worked on how the agent asks, not on whether a true answer existed to be asked for. The fix is upstream of the prompt, in whether the process is legible at all.

How to engineer process context in practice

Concretely, the agent should not receive a document. It should query a process and hand over the conditions of the case: dangerous goods, a specific lane, an excursion in transit. What comes back is a resolved route, the ordered steps with owners, constraints, and sign-offs, current by construction. That resolved route is the context the agent acts on. Because it comes from the process system of record, exposed over an API, a CLI, and an MCP tool, the agent consumes it like any other capability rather than parsing a wiki. The prompt becomes small: here is the case, give me the route, here is what I did. The weight moves from prompt wording to a governed process that stays true. See how that surface works in the product.

Where to start

If your agent context strategy is a stack of retrieval tricks and a growing system prompt, you are tuning the approximation. Start with the process instead. Pick the operation you most want an agent to touch, and ask whether the process for it is legible, current, owned, and resolvable to a route. If it is not, no amount of context engineering downstream will save the agent, because there is no true answer for retrieval to find. Make the process legible first. The prompts get short and the agent gets right.

Common questions