I Manage AI Agents the Way I Manage Teams

I run multiple AI agents across several projects. A site architect for this website. A content agent for editorial work. A sysadmin agent for infrastructure. An observability bot for monitoring. Each one has a defined role, documented standards, and clear boundaries.

At some point — I couldn’t tell you exactly when — I stopped thinking about this as “using AI tools” and started thinking about it as managing a team. Not in the Silicon Valley “AI teammate” marketing sense. In the actual management sense: the same principles I’d apply to a group of human engineers producing real work under real constraints.

The more I leaned into that framing, the more the system improved. Because it turns out the management disciplines that make human teams effective aren’t abstractions. They’re operational patterns that apply to AI agents without (much) modification.

Separation of concerns is just a job description

Each agent has a job, and it does that job. The site architect handles the website — layouts, components, performance, SEO, and editorial. I originally separated content into its own agent, but the editorial voice needed enough architectural context that splitting them created more coordination overhead than it saved — so I consolidated. That’s the methodology working as designed: the right boundary isn’t always more boundaries. The sysadmin agent handles infrastructure — AARs, topology documentation, environment configs. My PM agent manages tasks and responsibilities in Asana.

They don’t freelance into each other’s domains.

This sounds obvious, but the default approach most people take with AI is the opposite: one chat, one agent, everything. Code review and creative writing and data analysis and debugging, all in the same conversation. It works the way having one employee handle engineering, marketing, and customer support “works.” You get output. But you get inconsistent output, because the agent’s context is split across too many domains to maintain depth in any of them.

Separation of concerns for AI agents is the same principle as separation of concerns for human teams. Defined roles reduce cognitive load, prevent context pollution, and produce better work — because the agent’s entire context window is focused on the domain it’s responsible for, not half-occupied by the residue of a different conversation about a different problem.

The loose catch-all still exists. For me, it’s the core Claude chat interface — the equivalent of walking over to someone’s desk for a quick question that doesn’t belong in anyone’s formal workflow. Not everything needs a scoped agent. But the work that matters does.

Clear guidelines are just an employee handbook

Every agent has governance documents. CLAUDE.md, ARCHITECTURE.md, ROADMAP.md — the governance layer that defines standards, patterns, boundaries, and institutional memory.

This is onboarding. You wouldn’t hire a developer and say “just go build.” You’d hand them the style guide, the architecture overview, the deployment process, the list of things not to touch. You’d give them context before expecting output.

AI agents need the same thing — except they need it more, because they can’t compensate for missing context the way humans can. A human developer who doesn’t know the naming convention will ask a colleague, read the existing code, or make a reasonable guess based on experience. An AI agent without documented conventions will make a different reasonable guess every session. Monday it’s camelCase. Tuesday it’s snake_case. Wednesday it’s whatever it inferred from the three files it happened to read first.

The governance documents aren’t overhead. They’re the mechanism that produces consistency — the employee handbook that every agent reads at the start of every session, ensuring that today’s work is compatible with yesterday’s.

Focus and respect are just professionalism

This might surprise people, but it matters: I interact with my agents the way I’d interact with professional colleagues. Focused. Respectful of their time (which in this case means their context window). No off-topic tangents unless the situation genuinely warrants it.

This isn’t sentiment. It’s practical. Every message in a context window consumes tokens. Off-topic chatter, excessive small talk, or rambling prompts pollute the context with irrelevant information. For a human colleague, that’s an interruption that costs focus. For an AI agent, it’s worse — it’s permanent context noise that degrades every subsequent response in the session.

Respecting the agent’s context window is the same principle as respecting an employee’s cognitive bandwidth. You wouldn’t ask your database architect to weigh in on your marketing copy. You wouldn’t CC everyone on every email. The same instinct applies: keep the interaction focused on the domain, and the output stays focused on the domain.

When to hire: the spinoff pattern

The management parallel that convinced me this wasn’t just a useful metaphor — but an operational truth — was the first time I had to restructure.

My sysadmin Claude Code instance manages infrastructure context: AARs, topology documentation, and environment configs. Straightforward scope. At some point, I had it build a small Telegram notification bot as a utility — a quick way to monitor the overall health of the systems I am responsible for.

The notification bot worked. Then it proved useful enough that I started expanding it. More alert types, better formatting, scheduling logic, error handling. Before I knew it, the “small utility” had grown into a legitimate standalone project sitting inside an agent whose job description was completely different.

The signal was the same one any team lead recognizes: the context required to do the work well had grown beyond what a single entity could reasonably hold. The agent’s CLAUDE.md was bloated with two domains’ worth of conventions. Half the context window was consumed by scope that wasn’t relevant to whichever task was actually in front of it.

So I did what I’d do with a human team member whose role had quietly split into two distinct jobs: I restructured. New repository. New governance documents. New architecture spec. New agent. The observability bot got its own development track, its own context, its own focused governance. The sysadmin agent went back to doing what it was actually scoped for.

The alternative — and this is the part that maps directly to organizational dysfunction — is letting scope accumulate until the agent is doing five things adequately instead of one thing well. That’s not an AI problem. That’s a management problem, and every team lead has seen it happen with humans. The person who’s in every meeting, owns every escalation, and somehow has three job titles on their email signature. The fix is the same in both cases: increase HR. It’s not a performance problem; it’s an organizational design problem.

Good management doesn’t depend on the medium

The argument I keep coming back to is simple: good management is good management. The medium changes — from a human team to an AI team — but the principles don’t.

Defined roles prevent confusion. Documentation prevents context loss. Focus prevents scope creep. Restructuring when the scope outgrows the role prevents degradation.

These aren’t AI-specific insights; they’re management fundamentals that happen to apply perfectly to AI agents — because the failure modes are structurally identical. An overloaded AI agent degrades the same way an overloaded employee degrades. Not through incompetence, but through insufficient structure around the work.

The people getting inconsistent results from AI aren’t writing bad prompts. They’re practicing bad management. And the fix isn’t a better prompt template or a more capable model. It’s the same fix it’s always been: clear roles, documented expectations, and the discipline to restructure when the scope outgrows the container.

---

This post builds on the management framework running through everything on this site. For the governance methodology: What Is Pass@1? and The Governance Documents. For the architectural argument: Governance Is Architecture.