Count the agent sessions you have open right now. If you work the way most people I talk to work, it is somewhere between six and fifteen, and you could not tell me what is in more than half of them. You will not close them either, because one of them might contain something: a decision you talked yourself into, a file you never committed, a piece of reasoning you would have to rebuild from scratch. So they sit there, and the pile grows, and every one of them is a small unpaid debt.
The question that sorts this out is short enough to keep in your head:
Could you delete this session right now and lose nothing?
If the answer is yes, close it, and feel nothing about it. If the answer is no, that is not a reason to keep the session. It is a signal that something inside it is sitting in the one place in your entire setup that has no backups, no history, no review, and no way for anyone else to reach it.
A session is another working copy
There is a whole genre of question forming around this, and once you notice it you see it everywhere. How do I back up my sessions? How do I restore one from last month? How do I move a session from the terminal into the desktop app? There are now tools whose whole purpose is to persist session history into your repository so none of it is ever lost.
And every few weeks comes the story that gives the genre its urgency: someone lost two days of work because a session was flagged, or expired, or was killed for looking like a security risk, and the post is a complaint about the vendor doing that to them.
The sympathy is genuine, losing work is horrible, and I have been there. But the conclusion being drawn is the wrong one. If two days of work can be destroyed by one session ending, the problem is not that the session ended.
We solved a version of this before. Everyone has lost a day to a dead laptop or a bad rebase, and the response was never to work out how to back up a working directory. It was to commit early, push often, and keep as little irreplaceable state in the working copy as possible, until the discipline became invisible and we stopped calling it a discipline at all. A session is another working copy, and right now it is the one part of the setup with no history, no remote, and no way for anyone else to reach it.
Widen that back out to the genre and the same thing is true of all of it. Compaction squeezes the session so it can live longer. Summarisation writes a shorter version of it. Handoff skills dump it to a file so a new one can pick it up. Backup, restore, migrate, resume, and agent memory all work to keep the artefact itself alive and portable. Some of these are genuinely useful and I use a couple of them, but taken together as an answer they share an assumption I think is wrong, which is that the session is a thing worth preserving at all.
I do not want better session management. I want sessions I do not care about. The only ones that should hold any value are the ones currently open and in progress, and even those should be one quick status check away from being closed and forgotten. If you find yourself asking how to back up a session, the more useful question is what is in there that you would miss, and why it is still in there.
A session should do one thing
We already know how to handle this, we just have not applied it here yet.
A function should do one thing. A class should have one responsibility. A module should have one reason to change. We hold these not because small is aesthetically nicer but because a small, scoped thing is easy to reason about, easy to replace, and cheap to throw away.
A session is the same kind of unit, and it should follow the same rule. One session, one job, and the first prompt is where you set it. When the job is done, the session is done, and you close it without ceremony because there is nothing in there that you did not already put somewhere better.
The reason people end up with a five-hour session holding four unrelated threads is exactly the reason people end up with a two-thousand-line god class: nobody drew the boundary at the start, and then every new thing had somewhere obvious to go. It happens by drift, not by decision.
And this is genuinely hard, harder than the principle makes it sound. A good session with an agent constantly throws off side thoughts. You go in to fix a caching bug and come out having realised something about your deployment pipeline. That is one of the best properties of working this way and I would not want to suppress it. But those side thoughts are the exact material that turns a single-purpose session into a container of unfinished business, so they have to be routed somewhere rather than parked in the scrollback where they will die.
The work is building the homes
Which is where the real effort goes, and it is not the effort people expect.
Getting things out of the session is exactly the goal, so the question is only ever when and where to. Left as one lump at the end, it fails, because at that point you are tired, the session is long, and you have to invent a location for each thing before you can move it. You will do it three times out of ten, and the session becomes a store of record by default, because that was the path of least resistance.
So the work is upstream. Your repositories and your projects have to already have a home for every kind of thing a session can produce, so that landing it is a reflex rather than a decision. A thought that is not ready yet goes into a technical note, which is a system built precisely so that parking a half-formed idea costs nothing. A decision goes into a decision record. Work in progress goes into a commit on a branch. A thing you should do later goes into the tracker. None of this is novel, and that is the point: the homes are ordinary, they just have to exist and be cheap to reach before you need them.
Get that right and disposability stops being a discipline you impose on yourself at the end of each session. It becomes a property you already have, because everything worth keeping went out of the session as it was produced, continuously, and what is left in the window is genuinely just conversation.
Seeing what a session is holding
I still need to see that, though, because I am not a machine and I do not route everything perfectly, and some of these sessions have been sitting for four days.
So I built a small skill called flight status , and it is on GitHub if you want it. It is a read-only snapshot of the current session that flags anything the session has produced but not yet put anywhere durable. It sorts what it finds into the two ways this work actually gets lost:
🔴 Only in the chat. A decision, a draft, a conclusion, a follow-up that exists nowhere but the conversation. Gone the moment the session closes.
🟠 On disk, but not landed. Uncommitted changes, untracked files, unpushed commits, stashes, files written to a scratchpad outside the repo. It survives the session, but it is not durable and nobody else can see it.
It prints a banner, one line per outstanding item. Here is that caching session from earlier, the one that went looking for a bug and came back with opinions about the deploy pipeline:
────────── 🛬 FLIGHT STATUS 🛬 ──────────
🔴 cache invalidation approach — settled on TTL plus explicit purge, not in any ADR
🔴 deploy pipeline race — spotted mid-session, not raised as an issue
🟠 cache-key refactor — uncommitted in service-api
🟠 load test numbers — written to scratchpad, outside the repo
──────────────────────────────────────────────
Or, on a good day:
────────── 🛬 FLIGHT STATUS 🛬 ──────────
🟢 All captured. Safe to close.
──────────────────────────────────────────────
This is not a handoff. It does not extract the session, summarise it, or write anything at all; it is strictly read-only, and the whole design goal is that it tells you the truth about the session rather than making a copy of it.
I run it in three situations. Coming back cold to a session I opened on Tuesday and have no memory of, where it answers the only question I have, which is whether I can just close this. Before stepping away from something, as a last check. And, increasingly, in the middle of a session that feels like it has got away from me, because if flight status comes back with four unrelated things in flight, the session has quietly taken on more than one job and the honest fix is to land them and start again with a smaller scope. That last use is the one I did not expect when I wrote it. It turns out to be a scope-creep detector as much as an exit check.
Closing has to be as cheap as opening
Opening a session is essentially free now, and the tooling has gone a long way to make it so. Closing one has had less attention, and that asymmetry is what produces the graveyard of tabs.
The friction of closing is not effort, it is doubt. You cannot remember what is in there, so the safe move is to keep it, and then you keep the next one, and now you have eleven open and you are afraid of all of them. Removing that doubt is most of the work, which is really all flight status does.
To be clear about the nuance: long-lived is fine. Sessions sit for days because you got pulled onto something else, and age is not the problem. A three-day-old session with everything already landed is free to delete at any moment, which is precisely the point. The problem is never how old a session is, it is whether it is holding state that exists nowhere else.
That is the whole thing, and it fits in one question. Could you delete this session right now and lose nothing? Build your workflow so that the answer is always yes.
