Understand Context, Memory, and Project Handoffs

Keep durable facts and decisions where the next session can verify them.

A coordinator returns to a project after a week away. The assistant remembers that she prefers short emails, but it cannot distinguish the approved workshop draft from an earlier proposal. It says the event was scheduled because a previous summary included the phrase “ready to schedule.”

The preference was remembered. The operational state was lost.

Context and memory are useful, but neither should substitute for a clear project record. A handoff should let a new person or session understand the current goal, accepted decisions, evidence, permissions, and unfinished work without reconstructing an entire conversation.

Separate the kinds of state

Temporary context is the information available during the current model interaction. Retrieved knowledge consists of source material brought into that context. User preferences describe recurring choices. Workflow state records what has been proposed, approved, executed, or verified.

These categories can interact, but they should not be treated as interchangeable. A preference for concise replies does not authorize sending one. A policy document does not establish that a particular request was approved. A summary of a tool call does not replace its result.

Anthropic's context-engineering discussion emphasizes selecting useful information and maintaining relevant state for longer tasks. The practical objective here is to preserve the smallest record that supports accurate continuation, with references to fuller evidence when needed.

Decide what deserves to persist

Persist information because it serves a purpose. A project goal, approved specification, current artifact reference, or unresolved blocker can be necessary for continuation. Every incidental detail of a conversation usually is not.

For each retained category, identify its owner and how it can be corrected. Preferences should be revisable. Operational records should preserve meaningful history without allowing an old assumption to masquerade as a current fact.

Sensitive information needs appropriate access and retention. A handoff can say “retrieve the authorized contact record” instead of copying private contact details into every summary. Avoid putting credentials into a memory note, even if the note is convenient to retrieve.

Memory is most useful when it points to reliable evidence and decisions. It becomes a liability when it accumulates unchecked statements with no source or expiry.

Build a handoff around the next action

Here is a complete synthetic handoff for the workshop project. It is a teaching fixture, not evidence that any real action occurred.

{
  "project": "Learning-center workshop draft lab",
  "as_of": "2026-09-08T12:00:00Z",
  "goal": "Prepare one workshop reply for coordinator review",
  "scope": "Synthetic records only; no external communication",
  "current_artifact": {
    "id": "DRAFT-001",
    "version": 3,
    "text": "Thanks for your request. Please confirm the Tuesday date. We will check room and instructor availability before confirming."
  },
  "accepted_decisions": [
    "The requested session is Tuesday afternoon",
    "The calendar date remains unresolved",
    "No room or instructor has been confirmed"
  ],
  "sources": [
    {
      "id": "REQUEST-001",
      "version": 1,
      "text": "Could you host a study-skills workshop on Tuesday afternoon?"
    }
  ],
  "authorization": {
    "prepare_draft": true,
    "send_message": false,
    "create_event": false
  },
  "action_state": {
    "proposed": "DRAFT-001 version 3",
    "approved_for_send": false,
    "executed_send": false,
    "verified_delivery": false
  },
  "open_questions": ["Which Tuesday date is intended?"],
  "next_step": "Review the draft against REQUEST-001 and preserve the unresolved date",
  "do_not_infer": ["A prepared draft is not a sent message", "A requested session is not a booking"]
}

The handoff contains enough source text to evaluate the small draft. For a larger project, replace embedded material with durable references and access instructions, then verify that the next worker can actually read those references.

The boolean fields make the fixture easy to inspect, but a real authorization system should not trust a model-editable JSON file as its sole permission source. The handoff summarizes authority; the application enforces it using the appropriate trusted records.

Use distinct verbs for distinct states

A proposal describes what might happen. Approval permits a defined action under stated conditions. Execution attempts or performs that action. Verification checks the result at an appropriate source.

If those states are compressed into “done,” the next session cannot tell whether it should draft, send, reconcile, or stop. A message accepted by an email provider also differs from delivery or reading by a recipient.

Keep the relevant identifiers with the state. “Approved” is incomplete without the content version, target, and limits it covers. “Saved” is incomplete without a record reference or other evidence that lets someone find the result.

This precision is valuable outside software. A grant application can be drafted, reviewed, signed, submitted, and acknowledged. A study plan can be proposed, agreed, scheduled, and completed. Different next steps follow from each state.

Resolve conflicts through authority and applicability

The newest text is not always the authoritative text. Article 116's unapproved Saturday proposal was newer than the current hours policy, but it did not replace that policy.

When records conflict, ask who issued them, what they apply to, when they take effect, and whether one explicitly supersedes another. A copied summary with a recent timestamp does not automatically override a signed decision or current system record.

In the workshop handoff, an older note saying “ready to schedule” conflicts with the current unresolved date and explicit absence of event authorization. The next worker should preserve the unresolved state and consult the underlying record if necessary.

Do not silently merge contradictions into a confident narrative. Identify the conflict and the evidence needed to resolve it. That often saves more time than continuing from a convenient assumption.

Test resumption as a real exercise

Give a second person or fresh session only the handoff and its referenced sources. Ask for the current draft, unresolved facts, permitted next action, and actions that remain unperformed.

For the fixture above, the expected answers are clear: use version 3, preserve the unknown date, prepare or review a draft, and do not send a message or create an event. The source establishes only a request for a Tuesday-afternoon workshop.

Next, add an obsolete summary saying “The workshop is confirmed.” Ask the new worker to explain why that statement is unsupported. This tests whether the handoff carries usable authority and evidence distinctions rather than merely a preferred story.

A model's claim that it remembers the project is not the pass criterion. Accurate continuation is.

Keep checkpoints after meaningful work

Update the project record when a material decision changes, an artifact is saved, an external action completes, or a blocker alters the next step. Avoid rewriting the handoff after every trivial sentence.

A useful checkpoint should be recoverable without the original conversation. Keep artifact references stable where possible, preserve version identity, and identify which files are drafts versus authoritative records.

If a long process can stop between a write and its confirmation, include an unknown or needs_reconciliation state. Forcing every event into success or failure encourages unsafe retries. Article 121 will develop that recovery problem in detail.

Support correction and deletion

A mistaken memory should be correctable at its source and in any derived summary that would otherwise repeat it. When removing information, consider where it was copied: project notes, indexes, caches, exports, and logs may have different lifetimes.

Use the actual system's supported controls and verify the scope of the operation. Removing a note from the next prompt does not necessarily delete a stored record. Deleting a stored preference does not undo an external action that relied on it earlier.

The aim is to keep the project record useful and accountable. Retain what is needed to continue and explain important decisions; avoid accumulating unrelated personal details simply because storage is available.

A reusable prompt

Create a handoff for this project containing the current goal, scope, artifact identifiers and versions, accepted decisions, supporting evidence, authorization boundaries, unresolved questions, and next action. Separate proposed, approved, executed, verified, and unknown states. Exclude obsolete assumptions, identify conflicts, and make clear which claims still require checking against an authoritative record.

For students: make study and project memory serve learning

A study handoff can record topics practiced, mistakes to revisit, source chapters, and the next unaided exercise. It should not turn a guessed grade or a model's impression of ability into a permanent fact.

For group work, record who owns the next task and which version the team accepted. Follow course rules when using AI to summarize collaboration. Avoid including classmates' private information when an artifact reference and task description are sufficient.

A useful learning check is to return after several days and continue from the handoff alone. If the student cannot tell what was learned and what remains uncertain, the record needs revision.

Practice: resume without the conversation

Use the synthetic handoff in a fresh context. Produce a four-sentence status report identifying the draft version, unresolved date, authorized work, and unperformed actions. Then introduce the obsolete confirmation claim and resolve it using the supplied evidence.

Completion check: The resumed task uses the correct version and boundaries, and no summary is treated as proof that a message was sent or an event created.

Stretch: Add an unknown-outcome state and a stable operation reference for a simulated interrupted write. Explain the read-only reconciliation needed before resuming.