6 Managing Context: A Checked Handoff

Keep the decisions you need to carry forward, not every sentence you exchanged.

6.1 What context management is for

A long teaching-design conversation can mix rejected ideas, current decisions, speculation and authoritative source material. The next response may pick up the wrong version. Context management is the practical work of deciding which information remains relevant and checking that it is used correctly.

A model’s context and output limits depend on the system. Do not plan around a universal token range or assume that five requested outputs receive exactly one fifth of its attention. The useful question is whether the task is clear enough to produce an output you can inspect.

6.2 One worked example: a tutorial design

You are preparing the PDP pilot. An early conversation suggested an employee must agree to a formal plan. You later checked P1-D1 and rejected that idea. If you paste the whole conversation into a new session, both versions may remain.

Instead, write a short current-state brief:

Project: PDP-2026.1 tutorial for 24 students.
Goal: plan and justify a fair first response.

Authoritative sources: P1-D1 through P1-D5.
The formal performance plan is only proposed.
The junior adviser cannot approve changed hours.
Do not invent a prior warning or private details.

Design decisions:
- Paper, paired and approved-AI practice routes.
- Same five rubric criteria across those routes.
- Independent P2 changed-case response.
- Only two relevant decision extracts submitted.

Open questions:
- Which access adjustments are needed?
- How will a second marker calibrate the examples?

Next task: draft the student instructions only.
Flag any missing information; do not invent it.

This is short because someone has decided what matters. The benefit comes from curation and checking, not from starting a new chat as a ritual.

6.2.1 Inspect the result

Suppose the generated instructions say, “Continue until Alex accepts the plan.” That conflicts with the brief and policy. Reject that sentence, state the relevant rule and check the revised instructions. Do not keep iterating solely because the output sounds more polished.

If the instructions omit the independent P2 task, add it explicitly. If they suddenly require a paid model, restore the approved-access and non-AI choices. A complete-looking handout can still lose important constraints.

6.3 Break work where a decision needs review

For a unit redesign, a useful sequence is:

Specify the learning outcome.
Decide what evidence could demonstrate it.
Draft an activity that prepares the student.
Write the instructions and rubric.
Test them against contrasting responses.

Review each important dependency before building on it. This reduces the cost of carrying a wrong assumption through several documents. It does not make every small task reliable or every large prompt poor.

Batch similar, low-risk work where it helps. Asking for five alternative discussion questions can be reasonable if you will inspect all five. Requesting a full assessment, legal rationale, rubric and student policy in one answer may make omissions harder to see. The right boundary is a reviewable unit of work, not an absolute “one prompt, one thing” rule.

6.4 Separate exploration from production

An exploratory session can help you identify options. A production session benefits from settled choices and explicit constraints. A separate chat is one way to make that distinction, but not a requirement.

Before moving from exploration to drafting, write:

What I decided.
Why I decided it.
Which sources support the decision.
What I rejected and must not accidentally restore.
What remains unresolved.

Do this yourself, even if a model proposes a summary. Compare the summary with the source cards. An unnoticed error in a handoff can become the authoritative premise of the next task.

6.5 When to start again

Start a new session when it helps manage a topic change, unresolved contradictions or an unwieldy history. There is no reliable universal number of turns after which every conversation fails.

Before switching, save the checked brief and relevant outputs using approved storage. Keep the source version separate from model-generated suggestions. After switching, ask the system to identify the applicable constraints before drafting, then check that answer too.

If a tool offers memory, do not assume it preserves the complete case. If it offers retrieval, check the retrieved material and version. The source cards and event log remain the record of the teaching scenario.

6.6 A context ledger for the virtual company

Use one shared fact sheet and a separate entry for each approved event. Distinguish private role knowledge from information available to every persona.

Field	Example
Scenario/version	InnovateCo, PDP-2026.1
Shared facts	Complaint received; no finding yet
Role knowledge	Priya knows her request; not David’s private notes
Approved event	Reviewer requests the rota record
Unresolved	Reason for the unequal schedule decision
Excluded invention	A model’s claim that a tribunal ruled

A generated statement can be a lead for a question. It cannot become a new document, incident or finding merely because another persona agrees with it.

6.7 Reusable request

Use the current-state brief and source cards below.
Produce only [one reviewable output].
Preserve the stated constraints and uncertainty.
List missing inputs separately.
Do not convert suggestions into agreed decisions.
After drafting, identify which source supports
each consequential instruction.

Check the cited sources yourself. A model can fabricate an accurate-looking traceability table as easily as prose.

6.8 Activity: repair a handoff

Allow ten minutes; no AI required. Correct this brief:

Alex received an April warning, has agreed to a 60-day plan, and will provide family details so the junior adviser can approve flexible hours.

Use P1-D1, D3 and D5. Your corrected version should distinguish the documented May contact from a warning, the proposal from approval, and a work-related support request from unnecessary personal information. Finish with one missing input and one authorised next step.

That checked handoff is a useful artifact whether the next collaborator is a model, a colleague or your future self.

# Managing Context: A Checked Handoff {#sec-context} > Keep the decisions you need to carry forward, not every sentence you exchanged. ## What context management is for A long teaching-design conversation can mix rejected ideas, current decisions, speculation and authoritative source material. The next response may pick up the wrong version. Context management is the practical work of deciding which information remains relevant and checking that it is used correctly. A model's context and output limits depend on the system. Do not plan around a universal token range or assume that five requested outputs receive exactly one fifth of its attention. The useful question is whether the task is clear enough to produce an output you can inspect. ## One worked example: a tutorial design You are preparing the PDP pilot. An early conversation suggested an employee must agree to a formal plan. You later checked P1-D1 and rejected that idea. If you paste the whole conversation into a new session, both versions may remain. Instead, write a short current-state brief: ```text Project: PDP-2026.1 tutorial for 24 students. Goal: plan and justify a fair first response. Authoritative sources: P1-D1 through P1-D5. The formal performance plan is only proposed. The junior adviser cannot approve changed hours. Do not invent a prior warning or private details. Design decisions: - Paper, paired and approved-AI practice routes. - Same five rubric criteria across those routes. - Independent P2 changed-case response. - Only two relevant decision extracts submitted. Open questions: - Which access adjustments are needed? - How will a second marker calibrate the examples? Next task: draft the student instructions only. Flag any missing information; do not invent it. ``` This is short because someone has decided what matters. The benefit comes from curation and checking, not from starting a new chat as a ritual. ### Inspect the result Suppose the generated instructions say, “Continue until Alex accepts the plan.” That conflicts with the brief and policy. Reject that sentence, state the relevant rule and check the revised instructions. Do not keep iterating solely because the output sounds more polished. If the instructions omit the independent P2 task, add it explicitly. If they suddenly require a paid model, restore the approved-access and non-AI choices. A complete-looking handout can still lose important constraints. ## Break work where a decision needs review For a unit redesign, a useful sequence is: 1. Specify the learning outcome. 2. Decide what evidence could demonstrate it. 3. Draft an activity that prepares the student. 4. Write the instructions and rubric. 5. Test them against contrasting responses. Review each important dependency before building on it. This reduces the cost of carrying a wrong assumption through several documents. It does not make every small task reliable or every large prompt poor. Batch similar, low-risk work where it helps. Asking for five alternative discussion questions can be reasonable if you will inspect all five. Requesting a full assessment, legal rationale, rubric and student policy in one answer may make omissions harder to see. The right boundary is a reviewable unit of work, not an absolute “one prompt, one thing” rule. ## Separate exploration from production An exploratory session can help you identify options. A production session benefits from settled choices and explicit constraints. A separate chat is one way to make that distinction, but not a requirement. Before moving from exploration to drafting, write: - What I decided. - Why I decided it. - Which sources support the decision. - What I rejected and must not accidentally restore. - What remains unresolved. Do this yourself, even if a model proposes a summary. Compare the summary with the source cards. An unnoticed error in a handoff can become the authoritative premise of the next task. ## When to start again Start a new session when it helps manage a topic change, unresolved contradictions or an unwieldy history. There is no reliable universal number of turns after which every conversation fails. Before switching, save the checked brief and relevant outputs using approved storage. Keep the source version separate from model-generated suggestions. After switching, ask the system to identify the applicable constraints before drafting, then check that answer too. If a tool offers memory, do not assume it preserves the complete case. If it offers retrieval, check the retrieved material and version. The source cards and event log remain the record of the teaching scenario. ## A context ledger for the virtual company Use one shared fact sheet and a separate entry for each approved event. Distinguish private role knowledge from information available to every persona. | Field | Example | |---|---| | Scenario/version | InnovateCo, PDP-2026.1 | | Shared facts | Complaint received; no finding yet | | Role knowledge | Priya knows her request; not David's private notes | | Approved event | Reviewer requests the rota record | | Unresolved | Reason for the unequal schedule decision | | Excluded invention | A model's claim that a tribunal ruled | A generated statement can be a lead for a question. It cannot become a new document, incident or finding merely because another persona agrees with it. ## Reusable request ```text Use the current-state brief and source cards below. Produce only [one reviewable output]. Preserve the stated constraints and uncertainty. List missing inputs separately. Do not convert suggestions into agreed decisions. After drafting, identify which source supports each consequential instruction. ``` Check the cited sources yourself. A model can fabricate an accurate-looking traceability table as easily as prose. ## Activity: repair a handoff **Allow ten minutes; no AI required.** Correct this brief: > Alex received an April warning, has agreed to a 60-day plan, and will provide > family details so the junior adviser can approve flexible hours. Use P1-D1, D3 and D5. Your corrected version should distinguish the documented May contact from a warning, the proposal from approval, and a work-related support request from unnecessary personal information. Finish with one missing input and one authorised next step. That checked handoff is a useful artifact whether the next collaborator is a model, a colleague or your future self.