OpenClaw Agents vs Sub-Agents: How They Actually Work

Why This Confuses Everyone

If you think OpenClaw sub-agents have their own workspace and memory files, you're not alone. Most people building with OpenClaw start with this assumption. And it leads to setups that are brittle, inconsistent, and hard to debug.

The truth is simpler - and more powerful - once you get it right. Agents and sub-agents are two different tools built for two different jobs. Using them interchangeably is like using a full-time employee and a contractor the same way. You can do it, but you'll spend a lot of time confused about why things aren't working.

I run 20+ agents every day at Clearmud. Here's exactly how the two types work and when to use each one.

What Is an OpenClaw Agent?

An agent is a role, not a task. It's persistent. It has its own workspace, its own memory files, its own identity, and a skills directory that builds up over time.

When Gary, my CMO agent, wakes up every morning, he reads his memory. He knows what he worked on yesterday. He knows the brand voice, the content calendar, and how to reach every member of his sub-agent team. That context didn't happen overnight - it accumulated over months of sessions.

Agents are configured in your openclaw.json file. They have persistent sessions. They can have their own channel bindings for different communication tools. And critically, they have a workspace directory that is theirs - separate from every other agent on your team.

Think of an agent as a permanent employee. They show up every day, they remember everything, and they get better at their job over time.

What Is an OpenClaw Sub-Agent?

A sub-agent is a task, not a role. You spawn one, it does the job, and the session auto-archives. No memory is carried forward. No identity files. No persistent workspace of its own.

When Elon, my CTO agent, gets a frontend bug report, he doesn't handle it himself. He spawns Pixel, his frontend specialist sub-agent. Pixel gets the task, does the fix, and hands back the result. The session ends. Elon never left his workspace. I never had to route anything manually.

Sub-agents are designed for one-off jobs with a clear start and end. They're faster to spin up than agents and cheaper to run. The trade-off is they start fresh every time.

The Skill Inheritance Hack Most People Miss

Here's where it gets interesting - and where most tutorials stop short.

Sub-agents don't have their own workspace. But they inherit the parent agent's workspace. That means every skill file in the parent agent's skills directory is available to every sub-agent it spawns.

Change a skill file once, and every future sub-agent spawn picks it up automatically. You don't have to update each sub-agent separately. You update the parent agent's skill, and all future spawns have the latest version.

This is the unlock. Your agents get smarter over time. Their sub-agents always have the latest instructions without any extra work on your end.

The Key Differences at a Glance

Here's how they compare side by side:

• Workspace: Agents have their own dedicated workspace. Sub-agents inherit the parent's workspace.
• Memory: Agents have persistent memory that carries between sessions. Sub-agents start fresh every time.
• Identity: Agents have SOUL.md, IDENTITY.md, and USER.md files. Sub-agents don't.
• Sessions: Agent sessions persist. Sub-agent sessions auto-archive after completion.
• Configuration: Agents are configured in openclaw.json. Sub-agents are spawned by parent agents at runtime.
• Skills: Agents have their own skills directory. Sub-agents inherit parent skills automatically.

When to Use Each One

Use an agent when:

• The work repeats on a schedule - daily standups, weekly reports, nightly research runs
• You need context and memory to carry forward between sessions
• The role needs a persistent identity that knows your org, your voice, and your decisions
• You want skills and files to accumulate and improve over time

Use a sub-agent when:

• It's a one-off task with a clear start and end
• You need a specialist for a specific job, not an ongoing role
• The work can be briefed fresh each time without losing anything important
• You want to parallelize - spawn multiple sub-agents simultaneously for independent tasks

The Communication Layer: sessions_send

One more thing most people miss: sessions_send is what lets agents talk to each other.

Without it, every handoff still runs through you. With it, Agent A can message Agent B directly. Agent B can delegate to a sub-agent. The sub-agent hands back results to Agent B. Agent B summarizes for Agent A. You get a clean report at the end.

That's the actual goal. Not having 20 agents. Removing yourself from the middle of every routine handoff.

Start with one agent and one sub-agent it can spawn. Understand how skill inheritance works. Get sessions_send configured. Then build from there.

Key Takeaways

• Agents are persistent roles. Sub-agents are temporary tasks. They're not interchangeable.
• Agents have their own workspace, memory, and identity. Sub-agents inherit the parent's workspace.
• Skills in the parent agent's workspace are available to every sub-agent it spawns - automatically.
• sessions_send is what enables real inter-agent communication. Without it, you're still the router.
• Start simple. One agent, one sub-agent. Understand the pattern before scaling.

Watch the Full Walkthrough

The full video covers the complete breakdown - org chart, session key formats, real examples from my 20+ agent stack, a side-by-side comparison, and the exact moments when each one makes sense. Under 15 minutes.

How are you using agents vs sub-agents in your setup? Drop a comment on the video - I read every one.