Passing context to whoever comes next

The same document, four situations

Context has to cross a boundary in four common cases, and the artefact that carries it is the same shape in all four:

• Session to session. A task resumed tomorrow, in a fresh window.
• Subagent to parent. A worker finishes and reports back; the next module covers why this isolation is useful.
• Agent to agent. A pipeline where one stage’s output is another’s input.
• Assistant to human. A support conversation escalating to a person, which is the case where the quality of the note is most visible and most often terrible.

Write one function that produces this note, and use it for all four.

What a good note contains

Seven items, in this order, because the order is roughly how urgently the reader needs them:

1. Goal. What we are trying to achieve, in the requester’s own words. Not a paraphrase.
2. Status. What is done, concretely. “Refund of 4,050 INR issued, reference RF-2291.”
3. What remains. The next specific action, not a category of work.
4. Decisions and their reasons. What was settled, and why, so the next reader does not relitigate it.
5. What was tried and did not work. The highest-value item and the one most often missing.
6. Current state. Ids, files, links, artefacts: the things the next reader needs to touch.
7. Open questions. What is unknown, and what would resolve it.

Most handovers omit items 4 and 5 entirely, which is why the reader’s first act is to repeat something that already failed. If you cut the note for length, cut 1 and 6 (they can be recovered from the artefacts) and keep 5.

Why “what failed” is worth the most

A fresh context has no idea what has already been ruled out. Given a task and no failure history, a model will try the most obvious approach first, which is exactly the approach the previous session already tried and abandoned. The failure repeats, often several times, and each repetition consumes budget and produces a plausible report of progress.

This is the dominant waste mode in multi-session agent work, and the fix is one section of a document.

TRIED AND REJECTED
- Refund via store credit — customer declined (turn 5)
- Refund to card ending 4471 — card expired, payment gateway error 4102
- Manual adjustment in billing — no permission on this account type

Three lines. They save the next session three dead ends.

Facts as fields, prose for the rest

The same rule as the state lesson: anything that must not be paraphrased goes in a structure.

{
  "goal": "...", "status": "...",
  "artefacts": {"refund_ref": "RF-2291", "ticket": "T-88213"},
  "tried": [{"what": "...", "outcome": "..."}],
  "open": ["..."],
  "transcript_id": "c_4471"
}

The transcript_id is not decoration. A handover is a summary, and summaries lose things; a pointer back to the full record means the next reader can recover what the note omitted rather than guessing. Every handover should carry one.

The human handover has extra requirements

When the next reader is a person taking over a live conversation, three additions:

Say what the customer was told. Especially any commitment made: a promised timescale, an amount, an assurance. A human who contradicts a promise the assistant made turns a recoverable problem into a complaint.

Flag uncertainty explicitly. “I could not verify whether the second charge was captured” is more useful than a confident summary that turns out to be wrong.

Keep it short enough to be read. A support agent picking up a queue has thirty seconds. A 900-word note is not read; a 120-word note with the seven headings is. This is a real constraint and it should shape the format.

Generate it early, not at the end

A note written when a session is already out of context is written from a compacted, degraded view: the worst possible source. Maintain it incrementally instead: update the structured fields as decisions are made, so the note at any moment is a current record rather than a reconstruction.

This costs a little on each turn and it means a session that is interrupted (by an outage, a limit, a user closing a tab) still leaves behind something usable. Which is the whole point: a handover exists for the case where the thing that was holding the context stopped.