Once you have more than three or four AI agents running, naming them stops being the interesting problem.
The real question is where one agent should end and another should begin.
I run OpenClaw on my own infrastructure across several businesses, projects and groups of people. The obvious setup was one agent per business: a Memox agent, an Autonomous agent, a personal agent, then more agents for individual clients.
That looked organized.
It was the wrong boundary.
Projects and businesses are only one dimension. The two boundaries that actually matter are audience and capability.
Audience determines isolation
Some agents exist because different people are in the room.
A family agent, a client agent and an internal team agent may all answer similar questions. They still need separate contexts because the audience changes what information is safe to expose.
I do not want a client conversation pulling in internal pricing decisions. I do not want team members reaching family context. I do not want one client's history shaping an answer inside another client's channel.
These are audience agents.
Their boundary exists for isolation. Different people, different trust level, different context.
The agent should know enough to serve that audience and no more than the audience should be able to reach.
Capability determines specialization
Other agents exist because the work requires a different kind of thinking and different tools.
Flux is my engineering agent. It works across repositories, reviews code and can use powerful development tools.
Scribe is my writing agent. It reads notes, extracts ideas and writes in my voice. It does not need the same host access or engineering context as Flux.
A QA agent needs test strategy and adversarial behavior. A DevOps agent needs infrastructure access and operational context.
These are function agents.
Their boundary exists for specialization. Different job, different tools, different judgment.
The important part is that function agents should cross project boundaries intentionally. My engineering judgment does not become a different capability because the repository belongs to Memox instead of another project.
Splitting engineering into one agent per business would fragment context that is useful precisely because it travels.
Why one agent per project breaks down
Per-project agents feel tidy because they mirror the folders and companies you already have.
But agents are heavier than folders.
Each new agent creates another persona, context store, permission set, routing decision and maintenance surface. Every time you ask a question, you now have to decide which agent owns it. Every time a project changes, you have another boundary to rebuild.
Worse, useful knowledge gets trapped.
The review pattern Flux learns in one Django codebase may prevent a bug in another. The infrastructure mistake found in one deployment may be relevant everywhere. The editorial pattern Scribe learns from one post should influence the next post regardless of which company produced the underlying experience.
Creating an agent per project turns shared judgment into isolated memory.
The two-axis model
The structure I use now has two independent axes:
- Audience agents isolate people and private context.
- Function agents concentrate capability and judgment.
An audience agent can call on a function without becoming that function. A team conversation may need engineering work from Flux. A personal conversation may produce an idea for Scribe. The audience boundary decides what context may cross. The function boundary decides who is equipped to do the work.
This also makes permissions easier to reason about.
Audience tells me who can trigger the system and what information they should see.
Function tells me which tools the work actually requires.
Those are separate security questions. Treating them as one “project agent” hides both.
When a new agent is justified
Before creating another agent, I ask three questions:
- Is there a different audience that requires context isolation?
- Is there a genuinely different capability requiring its own tools, permissions or persona?
- Or is this merely another project for an existing function agent?
The first answer may justify an audience agent.
The second may justify a function agent.
The third usually does not justify anything new.
There are exceptions. A function can become large enough that its context starts polluting unrelated work. Tool access may differ enough to require a split. A client may require dedicated isolation even when the capability is familiar.
But the split should solve an observed boundary problem, not satisfy an organizational diagram.
Fewer agents, clearer boundaries
The goal is not to create the most granular agent system.
Every additional agent adds routing overhead, duplicated configuration and fragmented context. The modularity penalty is real.
The useful structure is the smallest one that preserves two things:
- Isolation where different people and trust levels require it
- Specialization where the work and tools genuinely differ
Businesses change. Projects end. Capabilities and trust boundaries last longer.
That is what the agent structure should follow.