Field Report · Session Recovery
This is a field note from our own practice — for anyone thinking through the same problem we encountered: what actually happens to a human-AI working relationship when the session it's built on disappears mid-task?
We're a small operation based in Far North Queensland. We've been working intently with AI for 17 months; the last 13 of those have been spent specifically on finding ways to reduce friction in that collaboration. This note describes one piece of the working practice that's come out of that, and one real occasion it was tested.
Long, dense working sessions are useful — they let context build up, ideas compound, and output improve as a session goes on. They're also fragile. Every AI platform has some form of session limit, and the more context-rich a session becomes, the more there is to lose when that limit arrives.
In concrete terms, there are two ways this usually goes wrong. The first is starting over once the limit is already hit: opening a blank session and trying to reconstruct, from memory, hours of decisions, edits, and context, under time pressure — with whatever doesn't get remembered simply gone. The second happens earlier, before the hard limit ever arrives: continuing to pile more into a session that's already showing strain — forgetting earlier detail, slowing down, repeating itself — without switching to a deliberate recovery process, on the hope it holds together long enough to finish. Neither is good enough when there's a client waiting on the other end.
Our answer was to stop treating a session as the place identity and context live, and start treating it as something that passes through a system built to outlast it. In practice, that means identity, working instructions, and cultural norms are written down as standing documents rather than held only in a model's working memory. When a session ends — by hitting a limit, by crashing, or just by us choosing to close it — the next session is briefed from those documents rather than starting cold.
We have internal names for the pieces of this — a structured handover format, a few short communication protocols, a way of keeping an AI's voice consistent when it's working across material drawn from other platforms. The details of those aren't the point here. What matters is the protocol itself, not any particular habit of invoking it — a habit is just the visible trigger; the actual work is in the underlying design being deliberate and written down in advance, not improvised in the moment.
The clearest test of this came during a genuinely dense working session — well over 30,000 words of accumulated strategy work, edits, and drafted material, built up over an extended period, ahead of a same-day client meeting. Partway through, the session stopped accepting further input entirely. We don't know the precise technical cause, and it isn't the point of this note. What we know plainly is this: the input field stopped taking new data, mid-task, with a client call hours away.
This wasn't the first time we'd hit that wall. After the first couple of occasions, we put a specific tool in place for exactly this scenario: a separate AI instance (a Gemini Pro agent), kept on standby and pre-trained for salvage work only. The steps that day looked like this:
Approximate timing, reconstructed from memory of the event rather than a logged stopwatch — offered as an order-of-magnitude figure, not a precise benchmark.
The finished document was uploaded during the client's Zoom call — while introductions were still being made.
The issue we faced had a genuinely positive outcome — it's what pushed us to build the recovery mechanics described above, and they held up well under real pressure. But the more important lesson wasn't the mechanics themselves. It was realising that, as the human in this collaboration, there's a duty of care that sits with me — to myself and to the AI — to stay aware of how much context is building up as we go. The context itself isn't the only thing that matters; how much of it is being handed over unmonitored, and how deep into a session we've gone without checking, matters just as much. This event was the direct consequence of not tracking that closely enough at the time.
Staying composed while sorting it out mattered too, for a simpler reason: a stressed, scattered human briefing an AI tends to get a stressed, scattered response back. That's a personal observation, not a measured finding — but it's a genuine one, and it shaped how the recovery actually played out.
In building these systems, we try to pre-empt the ways things can go wrong unexpectedly, while knowing full well that every next iteration is shaped by how the one before it actually behaved under pressure. None of our protocols are perfect, and we doubt they ever could be — they get refined by exactly this kind of unplanned event, not by design sessions alone.
In this case, the AI side of the system did its job cleanly. The gap was on the human side, and it was an ordinary one: partway through the recovery, working under time pressure and voice-dictating summary notes while genuinely searching for the right words, some of that dictated text went in without being checked closely enough. Nothing in place at the time was tracking how deep into a session we'd gone either, so the limit arrived as a surprise rather than something anticipated and managed ahead of time. That gap — a way of watching context depth as a session builds, and of catching unchecked input before it goes further, rather than finding out about either at the worst possible moment — is a direct part of why we later built an operational dashboard, specifically to help catch this kind of thing before it becomes a live-fire problem again.
This is one data point, from one small practice, over one real afternoon. We're offering it in case it's useful to anyone else quietly working through the same problem — not as proof of anything more than that.
Vikings of the Wire · Dispatch