The workflow /

Many sessions, one named place each.

Running several agent sessions at once is easy. Finding the one you want twenty minutes later is the actual problem, and it is a naming problem before it is a tooling problem.

From ~/.local/bin/work · A 132-line bash launcher over a terminal multiplexer · Verified 2026-09-11

Tabs are not a session model.

Parallel work in a terminal tends to sprawl: one window per thought, no names, no way back. The state you want is in a pane you closed, or in one of nine that look identical.

The fix is not fewer sessions. It is that a session has a name, the name is the project, and there is exactly one of it.

One command, attach or create.

work opens a fuzzy picker; work <slug> goes straight to a project; work ls prints the board. If a session for that project is live it attaches, and if it is not, it creates one. There is no third outcome, so the command is safe to run by reflex.

It is 132 lines of bash, written against the shell that ships with the operating system, because a launcher that needs its own install is a launcher that breaks the day you need it.

  • A registry of 22 projects maps a short slug to a path.
  • Resolution is explicit: registry first, then a literal directory, then recent directories.
  • Session names are coerced to the character set the multiplexer accepts, so a branch name can never produce an unreachable session.

Where a tool runs decides where its files land.

The reason a launcher is worth 132 lines is that most agent tooling writes beside the working directory: transcripts, browser dumps, caches, scratch state. Start in the wrong place and that output lands in your home directory, unattached to any project.

Anchoring every session to its project directory means the debris is already filed by the time you look for it.

The ceiling is the machine, not the model.

Parallel sessions are bounded by memory and disk long before they are bounded by anything intelligent. Wide fan-out on a laptop produces swap thrashing that is indistinguishable, from inside a session, from a bug in the code you are writing.

The practice that follows is unglamorous: check the host before blaming the program. Load average and swap usage first, code second.

  • A session that has gone quiet is often a machine that has gone to swap.
  • Disk exhaustion presents as unrelated tool failures across every session at once.
  • The honest capacity number is the one measured on the machine in front of you.

What this does not solve.

A launcher makes sessions findable. It does not decide what they should be doing, it does not review their work, and it does not stop two of them editing the same file.

Those are separate problems, solved by a worktree per branch and by review that the author does not perform on themselves.