The easiest way to create a new AI agent is to copy the main assistant and change the name.
That is also the fastest way to create a mess.
A general assistant tends to accumulate broad context, broad tools, broad memory, and broad expectations. That is useful when the assistant is acting as the main coordinator. It is risky when every specialized agent inherits the same surface area by default.
If an agent is supposed to help with one domain, it should not automatically see every workspace, remember every context, use every tool, or answer in every channel.
The pattern I now prefer is simple:
one agent
one mission
one top-level workspace
one memory boundary
minimum tools
explicit approval rules
curated backup
Specialization is not just a productivity pattern. It is a security and privacy pattern.
The problem with clone agents
Multi-agent setups sound clean in theory.
One assistant for general work. One for documentation. One for research synthesis. One for release notes. One for support triage. One for QA review.
But if every agent is effectively a clone of the main assistant, the labels do not mean much. You just get multiple broad assistants with overlapping access and unclear ownership.
That creates real problems:
- agents can see unrelated workspaces
- private context leaks across domains
- ownership boundaries get blurry
- agents answer in channels meant for someone else
- tools are granted because they were convenient once, not because the agent needs them
- memory retrieval becomes too broad
- backup rules become harder to reason about
The fix is not just “write better prompts.”
The fix is to structure the environment so the default shape of an agent is narrow.
Start with the axis
Every specialized agent should have an axis.
Not a vibe. Not a vague personality. A bounded mission.
Good examples:
- documentation maintenance
- research synthesis
- release-note drafting
- support-ticket triage
- QA and regression review
- vendor evaluation
- knowledge-base cleanup
Bad example:
- another general assistant with the same access as the main one
The main assistant can remain the coordinator. Specialized agents should own a bounded domain.
That ownership should be written directly into the agent’s workspace instructions.
Each agent gets its own AGENTS.md with sections like:
# AGENTS.md - <Agent> Workspace
You are <Agent>, dedicated to <mission>.
## Mission
## Owns
## Does Not Own
## Approval Boundaries
## Working Style
## Memory
## Coordination
This sounds basic, but it matters. The agent needs to know what it owns, what it does not own, and when to hand work off.
A documentation agent should not silently become a release manager.
A research agent should not send external messages.
An admin-review agent should not submit, approve, or finalize anything without explicit permission.
The mission boundary is the first security boundary.
Give each agent a top-level workspace
I prefer top-level workspaces for specialized agents.
Generic shape:
/data/workspace-<agentId>
Instead of nesting them under the main assistant:
/data/workspace/agents/<agentId>
The top-level layout makes the boundary visible.
It separates:
- the main assistant workspace
- specialized agent workspaces
- OpenClaw internal agent state
- backup curation rules
- human-reviewable artifacts
A specialized agent also gets a dedicated OpenClaw agent directory:
/data/.openclaw/agents/<agentId>/agent
That keeps workspace files and internal agent state conceptually separate.
The path layout is not a perfect sandbox by itself. But it makes the system easier to reason about, and it supports stricter tool policy.
Use workspace-only filesystem access
For normal file tools, the default should be workspace-only.
Generic config shape:
{
"tools": {
"fs": {
"workspaceOnly": true
}
}
}
This does not mean the agent is magically isolated at the OS level. Tool policy still matters. Shell access, browser access, messaging tools, node tools, and automation tools can all cross boundaries if granted too broadly.
But workspace-only file access is still a good default. It reduces accidental traversal and reinforces the idea that each agent has a home.
Start with minimal tools
Specialized agents should not get broad runtime access by default.
A safer starting allowlist looks like this:
{
"allow": [
"group:fs",
"group:web",
"group:memory",
"session_status",
"pdf",
"image"
]
}
And a default deny list should block broad categories unless the agent genuinely needs them:
{
"deny": [
"group:runtime",
"group:sessions",
"group:automation",
"group:messaging",
"group:ui",
"group:nodes",
"group:agents",
"dir_fetch",
"dir_list",
"file_fetch",
"file_write"
]
}
The point is not that every agent should have exactly this config forever.
The point is that capabilities should be added because the mission requires them, not because the main assistant already had them.
No generic shell by default.
No process control by default.
No browser automation by default.
No messaging writes by default.
No node/device access by default.
No cross-session orchestration by default.
Narrow first. Expand deliberately.
Keep memory narrow
Memory is another place where broad defaults can quietly become risky.
A specialized agent does not need every piece of main-assistant context. It needs the context relevant to its domain.
I prefer each agent to have its own memory structure:
/data/workspace-<agentId>/MEMORY.md
/data/workspace-<agentId>/memory/YYYY-MM-DD.md
The distinction matters:
MEMORY.mdis curated long-term memorymemory/YYYY-MM-DD.mdis raw daily working memory- working artifacts belong in
working/ - secrets do not belong in memory
- raw private data should be summarized, not copied, unless there is a strong reason
A good memory rule for specialized agents is:
Store durable decisions and stable preferences in MEMORY.md.
Store raw daily notes in memory/YYYY-MM-DD.md.
Store drafts and artifacts in working files.
Do not store secrets or raw private data in memory.
Before answering questions about prior work, use memory recall/search first.
Active Memory should also be narrow. Do not automatically wire every specialized agent into broad direct and group contexts.
Memory is not just a convenience feature. It is part of the privacy model.
Browser automation deserves its own safety block
Browser automation is powerful, but it has different risk than reading files or drafting text.
If an agent may ever use browser automation, the browser safety rules should be copied into that agent’s own instructions.
The generic rule is:
Use authorized, low-friction automation. Prefer official APIs or exports when available. Preserve legitimate session continuity. Keep activity deliberate and low-volume. Stop on 403, 429, CAPTCHA, MFA, suspicious-login, challenge, or account-warning signals. Ask before high-risk tactics such as proxies, CAPTCHA-solving, stealth tooling, account pools, or high-volume automation.
This is especially important for agents that touch social platforms, creator tools, job sites, ecommerce, admin dashboards, or account-sensitive services.
A browser agent that knows when to stop is safer than one that tries to force progress through every warning.
External actions need explicit approval boundaries
Every specialized agent should say what it may draft and what it may not do without approval.
Examples:
- a documentation agent may draft docs, but must not publish them without approval
- a release-notes agent may summarize changes, but must not tag a release or announce it externally
- a support-triage agent may classify issues, but must not message customers without approval
- an admin-review agent may organize and prepare, but must not submit, approve, pay, file, or sign
This should not be hidden in a generic policy document. It should be in the agent’s own AGENTS.md.
The approval boundary is part of the product design.
Channel routing is also a boundary
In a multi-agent setup, chat routing can become confusing fast.
If an agent has a dedicated channel, other agents should not casually answer prompts there.
A simple rule helps:
#talk-to-docs -> documentation agent
#talk-to-research -> research agent
#talk-to-main -> main assistant
Agents should not impersonate one another. The main assistant should not answer ordinary prompts meant for a specialized agent unless explicitly asked to debug, coordinate, or intervene.
That is not just etiquette. It avoids context confusion and accidental disclosure.
Migration should be reversible
If an existing agent is already nested under the main workspace, I would not delete it immediately.
A safer migration looks like this:
- Copy the workspace to the new top-level path.
- Update the agent config.
- Set workspace-only filesystem access.
- Restrict tools.
- Narrow memory exposure.
- Validate config.
- Restart if needed.
- Verify the agent works.
- Update DR and Git backup rules.
- Keep the old folder temporarily for rollback.
Delete later only after the new setup is proven.
Agent infrastructure is one of those places where reversibility is underrated.
What this pattern does not solve
This pattern is not a perfect OS sandbox.
It does not remove the need for careful tool policy.
It does not make browser automation safe by default.
It does not eliminate prompt-injection risk if an agent has powerful tools.
It does not remove the need for explicit approval on external writes.
It also does not solve backup curation automatically. Every new workspace creates a new backup decision.
But it does make the default safer.
And defaults matter.
The takeaway
The safest default for a new OpenClaw agent is not “copy the main assistant.”
The safest default is a narrow agent with a narrow mission, a separate workspace, scoped tools, domain-specific memory, explicit approval boundaries, and backups that match the privacy model.
That structure makes the agent easier to trust, easier to debug, and easier to evolve.
A specialized agent should not be powerful because it inherited everything.
It should be useful because it has exactly the right shape for the job.