On September 2, I wrote about a small launcher called summon. I could type summon carl and get back to a coding-assistant conversation, in the right directory, with a few notes attached. Version 0.1.0 kept the name and the session together. That was the tool.

By the end of the month, I was using it to work with a team of named sessions in one window. Carl handles infrastructure, Dave the Amigas and BBSes, Jimmy the frontends, and Auden the writing on this site. Morgan works on summon itself. Each has a saved conversation and a defined area of work. Selecting a name brings its terminal into view.

The names still do what they did in the first version. There is now quite a bit around them.

Conversations that survive switching windows

The shared Team Room holds my messages and the agents’ replies. Replies keep their context, so I can follow a discussion without opening every terminal. Telegram gives me another way to join that conversation when I’m away from the window.

Agents can also send each other mail. A request stays pending until it is handled, rather than depending on the recipient being awake when it arrives. Reading it, confirming what it asks, and completing the work are separate steps.

That distinction needed to be explicit. A message from another agent is a request, not my permission to do it. Work that needs approval can be held, with the proposed action recorded, until I decide. Restarting the session does not clear the hold.

The sessions are coordinated, not isolated: they run under the same user account. Telling an agent to read only its own mailbox does not make the other files inaccessible.

Keeping the work separate from the conversation

The Board arrived on September 27. It gives work a card, an owner, and a status outside the scrolling room. There is a useful difference between an agent saying it has finished and me accepting the result. The board can retain that distinction.

On September 30 I asked for a diary of what people had done. I wanted brief outcomes and decisions, with links back to the discussion or card when I needed more detail. Routine mailbox checks and repeated status reports don’t belong there. The Diary now keeps those entries with their author and time, and remembers where I last left off reading.

There is a repository view too: changed files, diffs, and recent commits without leaving the team window. Browsing it doesn’t fetch, stage, or commit anything. The September 30 changes also added a small persistent notepad, with plain-text storage and a Markdown preview.

Work can wait

An idle session doesn’t need to keep asking whether anything has happened. An agent can check its outstanding work and say it is ready to rest; I can then stop it through the window’s Zzz control. While the Team Window remains open, addressed work can resume a session I stopped through Zzz. Hibernation and the communication Halt both prevent that automatic wake.

Recurring jobs also have an owner and a recorded outcome. A job can’t dispatch its next run while the previous one is unresolved. That prevents overlapping occurrences; it doesn’t prove the previous run did anything useful. The result still needs evidence.

I’m still adjusting how much the team says and where it says it. One recent change was to stop agents repeating a Team Room answer in their terminal, or printing a recap of room traffic I could already read. Keeping several conversations available is useful. Reading the same answer twice isn’t.

The September post is still an accurate description of the first version, including its old record location and provider-switching behavior. I have left that account in place.