Context Engineering Is Factory Design

Teams often treat context as a writing problem. They keep polishing the system prompt, add another page of instructions, and paste in more background when the agent misses something. That can rescue a session. It does not create a dependable way to decide what every future session should know.

The real problem begins before the model receives a token. Somebody has to decide which rules always apply, which product decisions are current, which files matter to this change, what the last attempt proved, and what the worker may discover on its own. Those are routing decisions. Burying them inside one heroic prompt only hides who made them and whether they will happen again.

Our position is that context engineering belongs in the factory architecture. It should be versioned, selected, tested, and observed like any other production dependency. If a person has to remember the perfect bundle for every run, that person is still the context system, and the agent is waiting on manual assembly.

Not every fact deserves the same route. A security boundary should arrive as a stable rule the worker cannot quietly discard. A product decision belongs to the task state and needs an owner and a version. A large design reference can stay outside the working window until retrieval finds the relevant section. Test output and tool errors should arrive as fresh evidence, not be rewritten into permanent instructions after one bad run.

Flatten those inputs into one document and their authority disappears. An old example can contradict a new rule. A summary can erase the exception that matters. A tool result can look like policy. The model receives plenty of text but no honest way to tell which statement governs the decision in front of it.

Give each class of context a job, a source, and a lifetime. Stable controls should be small and unavoidable. Task facts should expire with the work. Reference material should be fetched when a known question calls for it. Runtime evidence should stay attached to the attempt that produced it. Structure is what keeps more information from becoming more ambiguity.

A large context window tempts teams to skip selection. Put everything in, let the model sort it out, and call the extra consumption insurance. That trades one visible decision for several invisible ones. Irrelevant material competes with the requirement, stale material can outrank the current state, and nobody can explain which input caused the answer.

A factory should assemble the smallest defensible package for the route. Start with the outcome, the permitted surface, the current constraints, and the evidence required at the exit. Let tools retrieve additional material through named interfaces. Record what they returned. When the route cannot resolve a conflict or find an authoritative source, it should stop or escalate instead of asking the model to manufacture certainty.

That selection policy should change with consequence. A reversible formatting repair needs little product history. An access-control change needs current architecture, threat boundaries, ownership, and stronger proof. Sending both through the same giant context bundle is not consistency. It is refusing to design the route.

When an agent produces the wrong result, the useful question is not whether the model is good. Ask what it was allowed to know. Did the current rule reach the run? Did retrieval choose the right source? Did a compressed summary remove a qualification? Did the tool return stale state? Did two instructions disagree without a precedence rule? Those failures demand different repairs.

Keep enough trace to answer them. You do not need to publish private prompts or preserve every token forever. You do need the identities and versions of the inputs, the retrieval decisions, the tool evidence, and the acceptance result. Without that record, the team can only add more prose and hope the next run behaves differently.

Then make the correction durable. Fix the selector when the wrong material arrived. Add an owner and expiration when stale guidance survived. Tighten the interface when a tool returned an ambiguous shape. Turn a repeated acceptance failure into a check. The factory should learn by changing the route, not by depending on one operator to remember a better incantation.

Models will keep changing, and larger windows will keep arriving. Neither removes the need to decide what is true, current, permitted, and relevant. Better models may tolerate a messy bundle for longer. They do not make stale policy fresh or give an owner to an unresolved product decision.

This is also where jobs change. People who spend their days finding the same documents, repeating the same background, and carrying decisions between tools are performing coordination the factory can absorb. Human judgment moves higher: deciding which sources are authoritative, which conflicts require a person, what consequences demand stronger evidence, and when a rule should retire.

Stop treating context as the paragraph before the request. Build it as a governed supply chain that can serve a new task, a new model, and a failed attempt without starting from memory. The model is one worker at the end of that line. The durable advantage is the machinery that delivers the right material and can prove why it belonged there.