I run a team of Claude Code agents. I've written about why that team needed an HR department and about how my Claude Code work is set up. This one is about the plumbing: how each person on the team gets started, restarted and stopped, and how they remember what they were doing.
Most of the detail here comes from my HR agent. I asked it to write up how the team actually runs, and it came back with a long report. I cut it down to the parts that might be useful to someone else.
The team, as sessions
Right now it's about thirty sessions across three programming departments, plus a few company-wide roles. A second company runs its own separate team on a different Claude account.
Each person on the team is a Claude Code session in its own Terminal window. Each one has a name and a role, and the name doubles as its message address. That has a catch. If someone gets a name wrong, the message doesn't bounce. It just silently goes nowhere.
Who runs on which model
HR, directors, senior developers, support and marketing all run on Opus. Junior developers are the only role on Sonnet.
Opus is very effective, and it isn't too bad on the usage. The split is about the work, not about status.
Three files every session reads at launch
When a session starts, it reads three files:
- its department's README
- a shared role file for its job
- a company-wide README
The point is that you fix something once and it applies everywhere. A rule fixed once in a shared role file reaches every department.
That's also the risk. A role file has no tests. If it's wrong, every session that reads it is confidently wrong, on every launch. So HR drafts changes to role files, and I approve the exact wording. HR's way of putting it: treat a role file like a database migration.
The launch scripts
A small launch script opens a new Terminal window with the model, the launch prompt and the name. The name shows up in three places: the window title, the session name, and the sidebar of the Claude app. That last one means I can talk to anyone on the team from my phone.
On top of that there's a script for the whole company and one for each department. Each department script has a roster, and the roster is the source of truth for who's on the team.
Memory follows the folder
A session's memory is tied to the folder it starts in. We found that out when marketing started in the code repository and its notes got mixed in with the developers' notes.
Since late September, each person also has their own memory. I wrote about the shared-memory problem in my agent team post. HR's notes add two details. The shared index was growing toward the size where newer notes silently stop loading. And saving to it triggered a permission prompt on every write.
Restarting one person without losing context
Connectors only load when a session starts. So sometimes one person needs a restart.
After a restart, the person is asked to list which connectors it can actually reach. A missing connector doesn't throw an error. It returns nothing, which looks exactly like a search that came up empty.
This bites hardest when I switch accounts. A connector that works on one account can be missing or signed out on the other. One of my agents watches a support queue and sorts the tickets. When it couldn't reach the ticket system, it didn't complain. It just sat there, and nobody was watching that queue.
The restart never uses "continue last conversation." Several sessions share a folder, so the latest conversation in that folder might not be yours. A director could end up with a junior's conversation. Instead, the script looks for the conversation that started with that person's own launch prompt and resumes the newest match. If it doesn't find exactly one, it refuses.
Stopping safely
The stop script is a dry run by default. It only stops processes on that department's roster, in that department's folder.
Why stop and relaunch at all? A message to another session arrives as text, not as a command. You can't message a session back to a clean state. Stop and relaunch is the reset.
Scheduled runs
Some support work runs on a schedule with nobody watching. Those runs couldn't read their role file because of permissions. So the role file is now pasted into the prompt itself, and the run refuses to start if it's missing.
What HR does day to day
Announcements only go to the people they affect, because every message costs the receiver a turn.
When I switch accounts, everyone finishes their current task, saves state and reports "ready." HR restarts them one at a time. The first restart is a pilot, and I confirm it in my Claude app before HR does the rest.
At the end of the day, HR collects a "settled" tally and then closes sessions by name, after a dry run. If someone was stopped and needs to come back, HR reopens that person's last conversation by hand.
Hiring has its own checklist. Is the problem already solved? What does the director think? Can the machine handle another session? A new hire gets the cheaper model unless there's a reason for the bigger one.
And names matter more than you'd think. Every name needs unique first two letters, and HR says it out loud before using it, because two names that sound alike are easy to mix up.
What we learned
Scope a role by the check, not the subject
A request for an accessibility role turned into a role that checks any customer-facing promise against what the software actually does. The trade-off is that it won't catch failures that aren't sentences, like color contrast. HR's advice: write down what the narrow version would have caught.
A fact gets more confident every time it's passed along
When one session tells another something, and that one passes it on, it sounds more certain each time. So the rule is to say where a fact came from, and whether it was checked by running something or by reading.
The catch comes from someone else
Almost every catch comes from someone other than the author, and often from a peer.
Headcount is nearly free. Work isn't.
Adding another session costs almost nothing. The work it does is what costs.
I've also written about juggling Claude usage limits across accounts, and about running the whole team on one Mac Mini. If you're running more than one Claude login on a Mac, three Claude accounts, one Mac covers the config directories.
Running a Claude Code team: common questions
How do I resume a Claude Code session without picking up the wrong conversation?
I don't use "continue last conversation," because several of my sessions share a folder and the latest conversation there might belong to someone else. My restart script looks for the conversation that started with that person's own launch prompt and resumes the newest match. If it doesn't find exactly one, it refuses.
Why does each Claude Code agent on my team have its own memory?
A session's memory is tied to the folder it starts in, so sessions sharing a folder were sharing notes. The shared index was growing toward the size where newer notes silently stop loading, and saving to it triggered a permission prompt on every write. Since late September, each person has its own.
Which Claude model does each role use?
HR, directors, senior developers, support and marketing all run on Opus. Junior developers are the only role on Sonnet. Opus is very effective, and it isn't too bad on the usage. The split is about the work, not about status, and a new hire gets the cheaper model unless there's a reason for the bigger one.
Why do my agents list their connectors after a restart?
Connectors only load when a session starts, and a missing connector doesn't throw an error. It returns nothing, which looks exactly like an empty search. After one account switch, that left a support queue unwatched, so now each person lists which connectors it can actually reach after a restart.