From OpenClaw to Claude Code Agent Teams: What Actually Migrates

· 5 min read

I ran a 14-agent AI team on OpenClaw for months.

It handled startup ops across finance, marketing, engineering, customer support, daily standups, and even personal coaching. Each agent had its own Telegram bot, persistent memory, scheduled tasks, and MCP integrations.

Then Anthropic cut off Claude access through OpenClaw. Overnight, a large chunk of OpenClaw users lost their main LLM provider.

So I evaluated Claude Code Agent Teams as a replacement, mapped what carries over, identified what breaks, and built an open-source migration tool to make the switch easier.

What OpenClaw gives you

If you use OpenClaw actively, you already know the model:

  • Isolated agents
  • Persistent memory
  • Scheduled tasks
  • MCP integrations
  • Inter-agent coordination

The real issue is not the orchestration layer. It is losing Claude as the LLM behind it.

Since then, Anthropic has launched Agent Teams and a few other features that make a multi-agent setup inside Claude Code much more viable. It is not the same as OpenClaw, but it does recreate a meaningful part of what made OpenClaw powerful, with its own pros and cons.

What Claude Code Agent Teams gives you

Anthropic launched Agent Teams as an experimental feature in Claude Code v2.1.32.

One Claude Code session acts as the lead and spawns teammates. Each teammate gets its own context window, can message other teammates, and coordinates through a shared task list.

That is much closer to OpenClaw than I expected.

At a high level, the mapping looks like this:

  • OpenClaw agents → Claude Code agent definitions
  • Isolated sessions → separate teammate contexts
  • Inter-agent messaging → maps reasonably well
  • Scheduled tasks and MCP integrations → mostly carry over
  • Persistent memory → exists, but in a simpler form

Four things I learned during the migration

1. One agent definition can be used in two ways

In Claude Code, agents are markdown files with YAML frontmatter in ~/.claude/agents/.

The same file can be used as:

  • A subagent for one-off delegated work
  • A teammate in an Agent Team with coordination and persistence

You define the agent once. The runtime model changes how it behaves.

2. memory: user is the persistence mechanism

OpenClaw has much richer memory:

  • SQLite
  • Vector search
  • Daily notes
  • Long-term memory files

Claude Code is simpler. If you set memory: user in agent frontmatter, the agent gets a persistent memory directory under ~/.claude/agent-memory/{name}/.

It is not a full replacement, but it is enough for agents that need continuity across sessions.

3. Use teammates for recurring roles, subagents for one-off tasks

My OpenClaw setup had 14 agents. Translating that directly into 14 always-active Claude Code teammates would be wasteful.

The better model is:

  • Teammates for recurring roles where memory matters
  • Subagents for one-off tasks where persistence adds little value

A finance agent that remembers past reviews and outstanding invoices should be a teammate. A quick formatting or scripting task can stay a subagent.

You do not need every agent active all the time. The lead can spawn the right ones for the task at hand.

4. Per-agent messaging channels do not translate

This is the biggest workflow gap.

OpenClaw lets you assign separate Telegram bots to separate agents. I could message marketing directly, or finance directly, from my phone.

Claude Code gives you one inbound channel to the lead session. The lead routes work internally.

You keep the team structure, but lose direct access to individual agents from chat.

What migrates and what does not

Migrates well

  • Agent roles, identity, and responsibilities
  • Org hierarchy and delegation patterns
  • MCP server configs
  • Scheduled tasks
  • Long-term memory content
  • Inter-agent coordination patterns

Does not migrate cleanly

  • Per-agent Telegram or WhatsApp bots
  • Vector or semantic memory search
  • Always-on daemon behavior (though a persistent tmux session gets part of the way there)
  • Daily notes (usually not worth carrying over)

The migration tool

I built claw-to-claude, an open-source migration tool for this.

It runs in three phases:

Phase 1: Analyze

Reads your OpenClaw config, workspace files, skills, MCP servers, cron jobs, and agent hierarchy.

Phase 2: Plan

Generates a migration plan with agent mappings, MCP config, scheduling setup, skill consolidation, and a clear list of what will not migrate.

Phase 3: Execute

Creates agent files in ~/.claude/agents/, generates shared skill files, seeds persistent memory from existing MEMORY.md files, and prints setup steps.

Install

claude plugin marketplace add tkhattar14/claw-to-claude
claude plugins install github:tkhattar14/claw-to-claude

Run

/claw-to-claude:migrate --path ~/openclaw-snapshot

Or:

/claw-to-claude:migrate --ssh user@your-openclaw-host

Is it a full replacement?

No.

OpenClaw is built for always-on, multi-channel AI assistants. Claude Code Agent Teams is built for collaborative work inside Claude Code sessions.

If your workflow is “message my finance agent from Telegram and get a P&L update,” OpenClaw still fits better with a different LLM provider.

If your workflow is “break down a feature across agents, let them coordinate, and ship it,” Claude Code Agent Teams works well.

My current split is simple:

  • Daily operations stay on OpenClaw
  • Complex collaborative work that benefits from Opus 4.6 moves to Claude Code

The migration tool is at github.com/tkhattar14/claw-to-claude. It is MIT licensed. Issues and PRs are welcome.

tags: ai-agents · open-source · claude