What should the assistant carry into the next turn?

The assistant remembers a plan that has changed

The visit was North on Friday. Now it is South on Monday, but the assistant still has a North access note and a summary mentioning Friday. None of those pieces was invented; they describe different versions of the job. Asking the model to read the whole conversation more carefully leaves it to decide which version became current. The application can make that decision much easier by supplying the accepted plan directly.

I would first inspect what enters the next request. Which decisions were accepted, which suggestions remain open and which facts belong only to an earlier visit? The conversation explains how the plan developed; a small durable record can say what the plan is now. That lets the colleague correct an actual site or date instead of repeatedly asking the assistant to remember the correction it already received.

Anthropic’s September 2025 context-engineering article describes curating the material supplied to a model over an evolving task. That framing is useful beyond any particular product: the next response depends on the information and instructions actually presented at that moment. A larger window can hold more history, but it does not resolve contradictions in the history or tell us which proposal became authoritative.

The maintenance briefing here is fictional. Its current task needs an accepted site and visit date, applicable equipment material and a way to keep open questions visible. A suggested move should remain a proposal until the workflow accepts it; an accepted move should create a revision and refresh site-dependent evidence. That distinction gives the application something definite to assemble for the next request, without asking the model to turn every earlier suggestion into a scheduling decision.

Separate the decision record from the conversation

A modest task record could contain a job identity, revision, current site, visit date, requested output and unresolved questions. When the colleague changes the site, the application records a new revision and marks site-dependent evidence for refresh. The next model request is assembled from that current record, rather than trusting the model to discover the latest instruction among every message that led there.

This does not require turning natural conversation into a rigid form. The assistant can propose an interpreted change and ask for clarification when necessary. The important boundary is what counts as accepted state. “Perhaps Monday would be easier” is not the same as “move the visit to Monday”. A system that silently resolves that ambiguity is making a scheduling decision under the cover of summarisation.

That record must remain open to correction. If a colleague says the displayed date is wrong, repeating the stored value on the next turn only makes the application reliably wrong. Interpret the correction, seek acceptance where its consequence requires it and assemble the next request from the resulting revision. The record earns its authority by representing agreed decisions, rather than winning every disagreement merely because it happens to be stored in a database.

Keep the task record intelligible to the colleague. Show the current site and date near the generated briefing, with a route to correct them. If the person cannot inspect the state the application used, an error looks like random model behaviour even when it came from a stale database field. Visible state also reduces the need to repeat established information in every prompt.

There is a trade-off between convenient inference and explicit confirmation. A harmless draft preference may be updated directly. A changed destination or action with operational consequences may need a deliberate acceptance step. Choose that threshold according to the decision, not according to whether the change happened to arrive in a chat message.

Every useful memory needs a scope

Not all remembered information has the same lifetime. A preference for concise summaries may remain useful across jobs. The fact that site North has an access restriction belongs to that site. A temporary instruction to exclude an unconfirmed component may belong only to one briefing revision. A single undifferentiated memory store makes these distinctions difficult to preserve.

Carry the source identity, scope and observed time with a retrieved fact. North’s access restriction belongs to North; similar equipment at South does not make it applicable there. A general product fact may survive the move after an applicability check. A summary from an old job needs to remain recognisable as a summary, too. Reusing it can save reading, but it must not quietly acquire the status of an independent product source.

Do not let a past guess become a fact

Writing every statement into long-term memory can preserve a speculative diagnosis without the uncertainty that originally qualified it. Later retrieval may then present that statement as an established fact. Store confirmed decisions with their authority, and retain origin and uncertainty for material still under consideration. The memory design needs that distinction if repeated retrieval is to add useful continuity rather than reinforce an earlier guess.

Expiry is not always a clock. A memory may become invalid because the site changes, the task revision advances or the source is withdrawn. Represent those dependencies where the application can act on them. A thirty-day time-to-live is an imperfect answer to an item that became irrelevant thirty seconds after the customer changed the appointment.

Compress history without compressing away the reason

Long tasks often need summaries. A useful handover summary should preserve the current objective, accepted decisions, outstanding uncertainties, evidence references and work already completed. It should distinguish a recommendation from an approval. The summary is a compact working aid; its authority should come from links to the decisions and evidence it represents.

Suppose an earlier investigation rejected replacement because the serial number did not match. A summary saying replacement considered has saved words by losing the reason the next step must stop. At the other extreme, twenty abandoned wording options do little to help the Monday briefing. Keep the decisions and the conditions that make them intelligible. Shortening a transcript is easy to observe; preserving the right constraint is what makes the handover useful.

For site South revision 4, the working packet might contain Monday’s confirmed visit, the South access note, the applicable equipment manual and one unresolved serial-number question. The previous North note remains in the history but is excluded from the active evidence packet. This is a proposed design with concrete inputs; it is not a claim that every model will then behave correctly.

To investigate a disputed briefing, retain enough revision and reference information to reconstruct the packet used, within the relevant privacy and retention limits. Copying every confidential document into diagnostic logs is not required to identify the task revision, selected sources and summary version. Those records can locate an assembly defect while allowing the underlying material to remain in its authorised storage and retention system.

Find out which part of the context caused the answer

When the assistant produces the wrong visit date, inspect the assembled request before rewriting the instruction. Did the current task record contain Monday? Did the summary still say Friday? Did a retrieved document introduce an unrelated date? These are different defects with different repairs. A more forceful sentence about accuracy may leave the underlying assembly bug untouched.

Use a small set of controlled variations. Supply the correct current record with a stale historical note, then remove the note. Change the task revision while retaining the same product evidence. Introduce a genuine unresolved question and check that the answer preserves it. The purpose is to see whether the output follows the intended sources of authority, not merely whether one final response looks plausible.

A clean context packet can also omit something necessary. If removing history loses the colleague’s reason for excluding a component, the concise version is not better. Review the boundary against actual decisions and failures. Minimal context means enough relevant information, not the smallest token count that still produces a grammatical answer.

For South revision 4, show the colleague Monday’s accepted visit, the applicable South material and the still-unconfirmed serial number. Keep North’s plan in history without making it compete as a current instruction. If the briefing gives Friday again, the team can inspect the packet that produced it and the colleague can correct the visible decision record. That is a tractable fault to investigate, rather than another occasion to tell the assistant that accuracy is important.