Context Engineering for Agents That Run for Hours

Chat history works fine as memory for eight turns. It falls apart at eighty. Logs pile up, older instructions start competing with newer ones, and the decision that mattered most gets buried inside a two-thousand-line tool response nobody will ever read again.

Context engineering is the discipline of deciding three things on every turn: what the model needs in front of it right now, what belongs in durable state outside the context, and what can be compressed without losing the ability to finish the job.

Separate the working set from the record

Two different jobs get conflated constantly. The working set is what the model reasons over this turn — the objective, the constraints, the current plan, the last few observations. The record is everything the task has produced: files, fetched source material, completed results, audit evidence.

The record does not belong in context. It belongs in storage the agent can query. A well-built agent retrieves the one artifact it needs rather than dragging the entire history forward on every call, which is both cheaper and dramatically more accurate — a model asked to find one fact in fifty pages of its own transcript will find something, and it may not be the right thing.

• A concise objective and an explicit definition of done
• A plan with completed and pending steps, updated as work progresses
• Durable artifacts for any output that must survive compaction
• A decision log covering assumptions, approvals, and irreversible actions
• Checkpoints that let a fresh worker resume without reconstructing hidden reasoning

Compact facts, preserve uncertainty

Naive summarization has a specific and dangerous failure mode: it launders a guess into a fact. A tentative “the auth service might be rate limiting us” becomes “the auth service is rate limiting us” after one compaction pass, and the agent spends the next hour fixing a problem that was never diagnosed.

A good summary keeps verified facts, unresolved questions, hard constraints, and identifiers — record numbers, file paths, ticket IDs, anything the next step needs to act on. It marks what is confirmed and what is still an inference. Confidence is information; do not throw it away for token savings.

Plans are state, not preamble

Most agents write a plan in their first response and then never look at it again. Make the plan a real object the agent reads and updates every turn. It gives you three things at once: the model reorients without re-reading history, a human can look at the current state without parsing a transcript, and a resumed run starts from the actual position instead of guessing.

Design for interruption on day one

Long-running agents will hit time limits, unavailable tools, data that changed underneath them, and approval gates that sit until someone gets back from lunch. Every one of those is a normal state transition, not an exception to handle later.

“Resumability is not an operations concern you bolt on before launch. For anything running longer than a few minutes, it is a core product behavior.”