An agent's context is assembled, not accumulated

For COO/CIO — ask whether your agent stack has a POLICY for three flows (what enters the window, what leaves it, what gets remembered and in which kind of memory) or whether all three happen by accident; the four memory kinds need different handling, and dumping everything into chat history is the d

A selected working window is assembled from a much larger archive.

Watch a good analyst take on a hard case. They do not read everything ever written about the client. They pull four things onto the desk, leave the rest in the cabinet, and start. An hour later the desk has changed: two documents went back, a fresh one came out, a page of their own notes sits in the middle.

That is context management, and every professional does it unprompted. For a simple request you hold everything in your head and put nothing on the desk. For a complex one you assemble deliberately, and the difference between a senior and a junior on the same case is often not raw intelligence. It is what ends up on the desk.

We give our agents the opposite. The common mental model of a context window is a bucket: it fills as the conversation goes on, and everything said stays in it. Few professionals would work that way by choice.

The working model is the desk, re-set before every turn. In a multi-turn dialogue something decides, turn by turn, what sits in front of the model. Nothing stays in view by default; it stays because something chose to keep it. For a defined piece of work, the sharper move is assembly under the task: the agent distils what it found into a research note and a plan, then works in a clean window seeded by those, instead of dragging the whole conversation behind it.

Two disciplines follow, and teams practise only the first. Adding: pull in the slice this turn needs. Removing: clear the stale logs, the superseded decisions, the resolved threads. Left in place they don’t just cost tokens, they degrade the answer. The goal, the locked constraints and the next step survive every clean-up.

Which raises the question the analyst answers instinctively: where does it go when it leaves the desk? Into memory. One practical way we separate it, because the kinds need different handling:

  1. Working notes: what this task cannot lose. The analyst’s own page, not the archive.
  2. Records: what was done and why, with a receipt. The file the auditor will ask for.
  3. Knowledge: durable facts about the business that the next case inherits.
  4. Procedures: how things are done here, the standing rules nobody re-derives.

It is easy to collapse all four into “history” and call it memory. History is the form that rots fastest: it grows without limit and files a superseded decision next to a standing rule as if they weighed the same.

Operstead, our execution harness for agent work, is designed around that split: to make the record side first-class through receipts, and to treat a run’s window as assembled input rather than accumulated chat.

The question worth putting to your team is not which model you run. It is whether anyone owns the policy: what enters the window, what leaves it, and what gets remembered, in which kind of memory. If nobody owns it, all three happen by accident, and your agent works at a desk you would never tolerate from a person.

A context policy specifies what enters the working window, what leaves, and what is remembered elsewhere.
01 / A context policy specifies what enters the working window, what leaves, and what is remembered elsewhere.