OpenChamber makes starting an agent session almost free, and my session list shows it.
I archive completed sessions aggressively, yet the active list keeps growing, and twice a week I find a session I forgot I had opened.
**Archiving is garbage collection, and no amount of garbage collection fixes an admission problem.**
The problem is not how sessions leave my list, it is how they enter.

## Why archiving cannot keep up

Think of the active session list as a queue and yourself as the single server that drains it.
Sessions arrive at the speed of one keystroke, and they leave only after the work finishes, the result gets reviewed, and somebody remembers to archive.
[Little's law](https://en.wikipedia.org/wiki/Little%27s_law) says the number of items in a system equals the arrival rate times how long each item stays.
Archiving attacks the exit, and the exit is capped by how fast work finishes and gets reviewed, while the entrance is unbounded.
As long as starting a session costs nothing and finishing one has no ritual, the list grows on schedule.

Every open session also has an ongoing cost.
The session remains an open loop that draws attention even when I am not looking at it, the [Zeigarnik effect](https://en.wikipedia.org/wiki/Zeigarnik_effect) applied to agents.
I wrote about the supervision side of running many sessions in [Managing Many Concurrent LLM Agent Sessions](../managing-many-llm-agent-sessions/index.md).
What was missing from my own practice was the other half: portfolio management, the habits that decide how many sessions exist in the first place.

## Cap work in progress

The single change that helped the most was a hard limit on active sessions.
Mine is five.
The exact number matters less than having one, because the number makes the list something I can remember.
**Starting a new session requires finishing or archiving an old one.**

This is the [personal kanban](http://personalkanban.com/pk/) practice, and it feels wrong at first.
The limit turns "can I start this" into "what am I willing to drop for this", and the limit's value comes from forcing that question.
It moves prioritization upstream, to the moment when comparing two pieces of work is still cheap.
Without a limit, the comparison happens downstream, late at night, across a list of forty half-remembered sessions.

## One session, one outcome

A session may not enter the list unless I can state its finish line in one sentence.
"Fix the OAuth callback failing on staging" has a finish line.
"Look into auth" does not.
When a session moves onto a second topic, that topic becomes its own session with its own name, once a slot frees up.
A session that cannot state a finish line is a scratchpad.
OpenChamber's session goals give the finish line a mechanical form: the agent keeps working until the goal completes, blocks, or runs out of budget.
**A session with a finish line can end, and a session that can end is the only kind worth starting.**

## Name sessions for their outcome

Once the list holds more than a screenful, names are the only index I have.
My convention is verb plus object, specific enough to act on: "fix-oauth-callback-staging", not "auth" and not "question".
A list of good names reads like a to-do list.
A list of bad names reads like noise, and I pay for the noise every time I scan.
[Managing Many Concurrent LLM Agent Sessions](../managing-many-llm-agent-sessions/index.md) treats naming as part of a uniform session protocol; my reason for naming here is narrower: with a list this full, the name is the index I scan.
Folders give the same benefit one level up: grouping sessions by project or by effort means every scan starts in the right neighborhood.

## Finish means archived

For years my definition of done for a session was "the work is finished".
The list disagreed.
Sessions whose work had already shipped sat active for weeks, because archiving was a separate chore that never became urgent.
The fix was folding archiving into done: **a session is done when its outcome exists and it has left the active list.**
Archive the moment the outcome lands.
The branch and pull request keep the work, the archive keeps the transcript, and the active list keeps only what still needs me.

When in doubt, archive anyway.
A session I wrongly archive costs one search to recover.
A session I wrongly keep costs a scan every day.

## Run a five-minute triage

Once or twice a day, I scan the session list and put every session into one of three buckets.
Needs me now: blocked, waiting on my decision, or mid-review.
Waiting: parked on CI, on another session, or on a person, with one line saying what it waits for, so "waiting" never means "mystery".
Dead: untouched for days, superseded by a later session, or no longer worth a slot, and dead sessions get archived on sight.
This is the [weekly review](https://en.wikipedia.org/wiki/Getting_Things_Done) from Getting Things Done shrunk to session scale, and the triage is what keeps the limits in force when the day gets busy.

## Keep the scratchpad out of the list

The biggest source of junk sessions, for me, is the passing thought.
"Quick question about this error" becomes a session, the question gets answered in ninety seconds, and the session joins the list forever.
The fix is a designated surface for thought: one scratch session per project, or plain notes, that absorbs whatever has no finish line.
Actual work still gets its own session, with a name, an outcome, and a slot the WIP limit protects.
**The list should contain work, and the notes should contain thinking.**

## The lifecycle at a glance

The practices above form one lifecycle, where the gate decides what enters and the triage decides what leaves:

```mermaid
flowchart TD
    A["Idea or task"] --> B{"Admission gate: WIP slot free and outcome stateable?"}
    B -- "no" --> C["Queue it in notes or drop it"]
    B -- "yes" --> D["Active session named verb + object"]
    D -- "outcome lands" --> E["Archive, part of done"]
    D -- "triage: dead" --> E
    D -- "blocked or parked" --> F["Waiting, with a note on what for"]
    F -- "unblocked" --> D
    F -- "stale for days" --> E
```

## What to Do Next

Pick a WIP number today (five is a fine start), count your active sessions, and archive down to the number in one sitting.
Adopt the naming convention for every new session from now on, and leave the old names alone.
Fold archiving into your definition of done: outcome exists, session left the list.
Put the five-minute triage at a fixed time, start or end of day, and let the dead bucket handle most of the archiving.
Then track one number for a week: active sessions at the end of each day.

**The target is a list you can recite from memory, because the archive stores everything, so the active list only has to tell you what needs you now.**

## See also

- [Managing Many Concurrent LLM Agent Sessions](../managing-many-llm-agent-sessions/index.md) - the supervision playbook for the sessions that remain active, and the ceiling on how many a human can track
- [Attention Engineering](../attention-engineering/index.md) - why every open session draws on attention, the scarcest resource
- [Six Months with OpenChamber](../six-months-with-openchamber/index.md) - where this workflow runs and why parallel sessions are worth their cost
- [You Are the Bottleneck](../you-are-the-bottleneck/index.md) - the same arrival-versus-service queue math applied to code review

## References

- [Little's law](https://en.wikipedia.org/wiki/Little%27s_law) - the arithmetic behind why faster cleanup loses to faster arrival
- [Personal Kanban](http://personalkanban.com/pk/) - the source of the WIP limit practice and "stop starting, start finishing"
- [Getting Things Done](https://en.wikipedia.org/wiki/Getting_Things_Done) - open loops and the review ritual the daily triage shrinks
- [Zeigarnik effect](https://en.wikipedia.org/wiki/Zeigarnik_effect) - why unfinished sessions keep drawing attention after I look away
- [OpenChamber](https://github.com/openchamber/openchamber) - the tool this workflow runs in