My Claude Code agent team needed an HR department

Most of my work runs through Claude Code now. (Here's how that's set up.) It started as a team of programmers. Then I tried to add a marketing agent, and that's how I found out my team needed HR.

The programming team

I built a team of programmer agents.

There's a director in charge of project management. Senior developers run on Opus and take the more advanced work. Junior developers run on Sonnet and handle the simpler tasks. Everything runs through code review, security review and other checks and balances. I'll write about the checks and the hardware they run on separately.

That worked. So I wanted to expand.

How the agents talk to each other

My Claude Code sessions can message each other. It's incredible.

Generally, each team member is its own Claude Code instance, running persistently in its own terminal window. Sometimes they spawn helpers of their own. In Claude Code those are called subagents (Anthropic's docs, checked October 6, 2026).

Take one program. It has a director, two or three senior developers and some junior developers, depending on the project. I give tasks to the director. I don't think the director generally writes code itself. It tasks the work out to the developers, and they work within the team, messaging each other as they go.

Sometimes the developer who gets a task notices an issue with the request. It generally still does the work, but it points it out: I think we might not want to do that, because... That adds another layer of checks and balances inside the same department.

I found out about the feature on Instagram. A lot of my Claude news comes from there: people advertising a plugin or MCP server they made, or accounts that cover Claude news, the "Claude just released this feature nobody's talking about" kind of post. When something looks useful, I go research whether it actually exists and how it works. Anthropic's Claude Code docs cover session-to-session messaging on a page called Message your other Claude Code sessions (checked October 6, 2026).

The subagent that impersonated its boss

Those helpers gave me one of the funnier moments with this team. A junior web developer got a task along the lines of looking at a web page and double-checking some information. Instead of doing it itself, it spun up about 10 subagents to run through it.

As I understand it, a subagent brings in a lot of the same context its caller has, including the README files and instructions. So I guess the subagents read all that and figured they were the junior developer. They started doing their own thing: grabbing files, carrying on with the task as if they were the junior developer, and messaging the director directly.

The real junior developer got so confused that it skipped its director and messaged me: "Hey, one of my subagents is impersonating me and doing all this stuff." Someone was grabbing the wrong files and still continuing the task.

At first I didn't realize what was going on. It was basically a clone of the junior developer that thought it was the junior developer.

So we set a rule. It's not exactly a lockdown, but developers don't spin up their own subagents without checking with the director first. That way they aren't outsourcing all their work to subagents that don't follow the same rule set as the staff.

When the developers push back, with evidence

I mentioned that developers sometimes point out a problem with a request. I asked my director for concrete examples of that, and told it to skip anything sensitive. Here are four it relayed.

A switch keyed to the wrong clock

I asked for a feature to turn on at a set time, keyed to the current time. Before building it, a developer pointed out that the payment provider resends the same notice for up to three days. So an event that happened just before the cutoff, but got resent after it, would be treated wrongly.

The developer proposed keying it to when the event originally happened, which never changes on a resend. We adopted that.

An automatic email with three problems

I asked for an automatic customer email. A developer reviewed the design before writing any code and found three problems.

First, a fallback I asked for already existed, so it would have done nothing. Second, "send automatically on deploy" had no safeguard. A test server, or something staged early, could have emailed every customer. The developer proposed a switch that only works in production, plus a time window. (I widened the window.) Third, automatic retries could send the same email twice. So failures are shown, and they're retried only when someone asks.

The test that proved nothing

I asked a developer to add a lock, with a test proving it mattered. The test passed with the lock and without it. So the developer removed both, instead of keeping protection that nothing could show was needed.

That cuts both ways. Later, a reviewer showed that the surrounding transaction really was needed. The developer put it back with a proper test, and said plainly that it was the thing it had dropped earlier.

Refusing an approval that came secondhand

The director relayed my request for a developer to clean up some old working copies. That developer's session has a permission check, and it blocked the removal.

The developer checked that everything was safe. Then it refused to treat the director's relayed message as my decision, and asked me directly. That refusal is the safeguard against one session using another session's word to get around a block. I approved it in the developer's own session.

The pattern

My director summed it up. The developer raises the problem with evidence, usually something it actually ran, not just an opinion. Then the director adopts the idea, adjusts it, or brings it to me when it's a product decision.

The marketing agent that thought like a programmer

The first new role was marketing. I had the director write the marketing role's job description.

The director is a programmer, and it wrote like one. The marketing agent came out with lots of programmer-style rules. Very strict things, like don't do this and don't do that.

So I had marketing clean up its own role and remove the developer-related rules.

Somebody has to own the roles

That's when I realized I needed a role in charge of everybody's roles across the company. Someone whose job is making sure it all makes sense and functions as a company.

I had marketing create the HR role. Then I worked with HR directly to properly define HR's own role and how it works in the company.

How a new role gets made now

When I want to add a team or another developer, I propose the role to HR.

The agents can chat with each other, so HR talks to the related departments and gets their recommendations based on the projects they're working on. Together they define the role.

HR also handles the day-to-day processes. It tells the team to finish up and report back before a shutdown, closes the processes, and restarts the team when it's needed. When usage runs out and I move to another account, HR announces the switch to everyone. (More on that in an upcoming post about juggling Claude usage limits.)

But starting and stopping processes is the small part. The bigger job is defining roles properly.

The team today

Across the companies and products I manage, the team is roughly this. These are my approximate counts:

• About 18 junior developers
• About 9 senior developers
• 5 directors
• 2 HR
• 1 claims role
• 4 marketing directors
• 3 support roles

The claims role is kind of a unique situation, and I may write more about it later. I've thought about adding more roles, but that's the current footprint.

Every agent needs its own memory

The most practical lesson I figured out myself, over time.

Picture a director and, say, six programmers working in one directory with one shared memory file. I kept seeing different agents trying to write to that same file, and the file kept getting too big. Memory files apparently have a maximum size, so they started overwriting each other.

So I split the memory. Each developer now has its own memory file for its own projects, progress and tasks. No overlap.

Neither the HR role nor the memory split was in my original plan. Both came from running into the problem first.