KN-21 · Account switch continuity
An operator switched accounts while six agent seats were preparing a release. The six old sessions could not reopen under the new account. The new team used saved handoffs to resume at the lead’s recorded next step and passed the next set of checks.
One lead, four builders and an internal reviewer worked in the same desktop harness. The switch separated account-bound sessions from files on disk. No seat reported work loss after restart. The record cannot count what had existed only in the old context windows.
At notice of the switch, the lead asked every seat to stop at a clean point and save a numbered handoff in a shared folder. The cap was under 60 lines. Each seat sent the lead a one-line receipt with the path. All six files were ready 11 minutes after the request, with 242 lines in total. Their final lengths ranged from 30 to 53 lines, including a later update to the lead’s file.
| Part | What it held |
|---|---|
| 1 | Role and session identifier |
| 2 | Finished results and the revision each result applied to |
| 3 | Work in flight, checked and unchecked items, and scratch locations |
| 4 | Exact next step |
| 5 | Open items for the next release or a pointer to them |
| 6 | What to read first |
The reviewer finished an open review before writing. The handoff recorded completed checks by revision, separated them from live checks assigned elsewhere, and gave a conditional next step. It identified an environment quirk, files to read first, and an unrelated working-tree change to avoid committing. The lead’s file ordered the remaining work across seats and marked step 2 as the restart point.
After the operator switched accounts, a fresh starter seat read the saved files to reconstruct the team. Eighteen minutes after the restart request, the team had passed startup checks, reread the handoffs and stood idle. The operator approved resuming at step 2 five minutes later. The record describes the build moving six minutes after the idle checkpoint. By 20:19 UTC, step 2’s group had finished from clean clones, with 378 tests passing on each of two Python versions and the live two-seat demonstration rerun.
The restart clock starts with the operator’s request in the new account. It excludes the switch itself and the intervening time. The source records the last old-account check at 19:11 UTC, the switch window through 19:31, the starter opening at 19:46, and the restart request at 19:47.
Figure 01Process trace
Six handoffs were ready in 11 minutes.
Each seat stopped at a clean point, saved a numbered handoff and sent the lead its path. The six files totalled 242 lines.
None of the six old sessions reopened.
The handoff files remained on disk. The new lead created dated references for replacement sessions.
The new team was checked and idle after 18 minutes.
The team checked startup and read the handoffs. Four seats marked point-in-time facts for fresh verification.
The build moved six minutes after the idle checkpoint.
The operator approved step 2. The resumed step passed 378 tests on each of two Python versions and reran the two-seat demonstration.
One planned switch on November 4, 2026. The 18-minute interval starts at the restart request and excludes the switch. The study could not count work held only in the old sessions.
The new team found issues with starting sessions, loading context and routing reports. None of the recorded faults was a problem with the saved handoff content. The old lead’s file had already warned about the turn requirement, and a controlled start attempt confirmed it in this case.
| Fault | How it surfaced | Response |
|---|---|---|
| Session starts blocked by settings | First attempted start | Enabled starts and preserved the old settings |
| Routine written for another harness | Read the startup instructions | Added a route for this harness |
| Start refused on a message-triggered turn | Deliberate test | Waited for an operator-opened turn |
| Lead loaded three of four pages | Startup page self-test | Wired the fourth page and checked reloads |
| Turn reports cascaded to starters | Starter saw reports arrive upstream | Detached sessions from their starters |
| One report queued while its fixture existed | Compared disk to messages | Accepted the report when it arrived |
Each startup check asked which pages loaded by using distinctive marker words. The seat wrote a fixture and reported its hash. The lead read and accepted the reports, and the starter checked the fixtures on disk. The seats then reread their handoffs.
All six old session identifiers failed to resolve. The new lead added dated references for the replacements. Session attachment and the associated report routing were recreated, then removed when the operator detached the sessions. Four seats flagged the handoffs’ point-in-time facts as needing a recheck. The files gave the team a way to find work, while the current checkout and test run supplied fresh evidence.
No seat reported losing work. The completed next step shows that the team could resume the recorded plan. It cannot reveal unrecorded details that may have disappeared with the old sessions.
Before a switch, identify pointers tied to the old account. Put handoffs where a new starter can find them without access to the old sessions. Use stable task names, revision references and pointers to durable records. Check current behavior on the new harness, including start permissions, turn requirements, context pages and message delivery.
This was one team on 4 November 2026, with advance notice and one desktop harness. The source author read the starter’s record, the reviewer’s final turns, operator turns and two of the six handoffs. The author counted all six handoff files and reconstructed the six startup faults from the starter’s reports. The source author also participated in starting the new team and accepts its releases.
The remaining four handoff contents and the new lead’s own log were not checked. The team did not measure work lost from context windows. A switch without notice could have produced a different result. This publication did not rerun the restart or verify current product behavior.