One job each

My side projects each have their own Claude Code session, and one more session manages them, as I described in an earlier note. Lately a third kind has joined them: sessions that belong to no project, but to a job. A session for posts. A session that watches the chats. A session for the look and feel of my games. A session for photos and video.

Each one does one job across all the projects, and nothing else. They work because something keeps them organised, and that part is the subject of the second half.

Why not one agent for everything

I could ask the manager to draft a post, then to read the chat, then to judge a colour, then to develop a photo. It would do all four, badly, for the same reasons a person would.

• The context stays small and on topic. A session that only drafts posts has posts, the rules for posts and the last few posts in its head. Not the build log of a game, not the chat history of the week.
• The rules and the tool quirks are learned once, in one place. Every tool has habits that cost an afternoon to find. A role session writes them into its own notes the first time, and every later job starts from there instead of rediscovering them.
• The permissions fit the job. The chat watcher reads with tokens of its own that can only read. The look-and-feel session reads everything and writes only in its own folder. The media session works on copies. None of them can do what another one is for.
• The project sessions stay on their own work. A game’s session building a level is not interrupted to cut a video for the level it just built.
• Hand-offs go by message, through the manager. A role never steers a project session itself. It sends its result to the manager, and the manager briefs the project, so there is still one place that knows what was asked of whom.

The four roles

Posts and notes. It drafts my posts and these notes, and publishes nothing: every post needs my yes, given in that session, one at a time. On 3 November a product page it had drafted went to a second session for a fact check against the code that shipped. The check found one omission and two wordings broader than the facts, all fixed before the page went live.

The chat watcher. A small script polls the team chat and the code host’s notifications every five minutes and wakes the session only when something is new. The session sorts each item: needs me now, needs the manager, information, noise. It sends the manager one message per batch, and nothing at all when nothing happened. Set up on 2 November at 12:57 and live at 15:09, fenced by 14 allow rules and 83 deny rules, with 43 tests and 31 checks that must fail. Its first batch: three items, three sorted correctly, no false alarms. That evening it picked out a tester’s reply that a fix worked, and an open item moved on without me reading the channel.

The look and feel. A session I join to talk about how the games should look, sound and play, away from the code. Its first sitting, on 2 November, wrote a style guide from things I had actually said, with the source beside every point. Putting a source on each one brought up that a rule I had made about colours in my tools had been written up, by the manager, as a rule for the games. My verdict at 10:42 was “not yet sure”. By 12:27 I had played one of its changes, and the role stayed.

Photos and video. It develops raw photos, and cuts video when there is some to cut, with command-line tools, always on copies. Set up on 3 November at 14:07, after I noticed that my raw developer had a command-line tool. It learned the tool on a demo library before it touched any of my files, and developed my first raw at 14:15. By 14:35 a portrait was done, retouched with an open-source image editor it had learned the same afternoon. The exports carry no location data, although the raw did.

What keeps them organised

Four more sessions would be four more windows to watch, if each one worked on its own. They do not. They run on the same setup as everything else I do with agents: Steward, my guide and kit for running several Claude Code sessions under one manager. A role is set up exactly like a project:

• A line on the roster, with its folder, its name and a few aliases, so “start the media session” is enough. In the Claude desktop app the manager starts it on my words.
• Its own folder and rules: what it does, what it does not do, what it may read and where it may write. Every session in a group gets the group’s rules at start.
• Messages through the manager. A role reports to the manager, and the manager records it and briefs whoever needs it. That is how a direction from the look-and-feel session reaches a game, and how the chat watcher’s batch reaches me.
• One list of what needs me. When a role waits on me, it says so, and the item lands in the manager’s overview with everything else, most urgent first. I do not open four more windows to find out.
• A fence between groups, so that a role for my own projects never talks to sessions that belong to someone else’s work.

Each role began as a question and a trial, not a plan. The look-and-feel session started as a trial I could end with one sentence. The media session started the minute a tool turned out to have a command-line mode. With the roster, the rules and the manager already in place, starting one was a folder, a rules file and a line on the roster.

What the manager’s overview looks like in the desktop app is in another note.

The uncomfortable part

• More sessions to start and watch. On 3 November, after I switched accounts, none of seven sessions was running, and each had to be started again. The chat watcher stays in the mode that asks before it acts, as a guardrail, so after the app stops I restart it by hand.
• A new member changes the room. On 2 November the watcher’s read-only bot joined the chat channels. That changed who can read them, and a reply queued before it joined was refused when I pressed Approve, because an approval covers who will read the post, and the readers had changed. Nothing was sent; the reply was queued again. The check was right, but it was a surprise.
• Hand-offs cost time. A decision about the look of a game travels from me to the role, to the manager, to the game’s session. That is three hops where one agent would have none.
• Roles sit idle. The look-and-feel session waits for my next sitting, the media session for the next photo. An idle session costs nothing, but it is one more thing to remember is there.
• Context is duplicated. Every role reads the same records the manager keeps. The reading is cheap; the risk is a role working from yesterday’s copy.
• It only pays with enough work. With one project, a role session is ceremony. It earns its keep when several projects need the same kind of work.
• The kit does not ship these roles. Steward gives a role the same footing as a project; what each role does is mine to write. The chat watcher is not in the kit today: I am still measuring it.

Steward is a 24-page guide and a kit your own agent installs, 59 USD with free updates for every 1.x release: more about it, or on Gumroad.