From OpenClaw to FastClaw: How to Design a Great Multi-Agent Architecture

After building Agent infrastructure for a year and stepping on countless pitfalls, I finally came to one realization: A good Agent architecture isn’t about cramming everything into a single process — it’s about letting each layer evolve independently.

Preface

In early 2026, OpenClaw went viral — a self-hosted AI assistant. At its core, it’s an Agent gateway that runs on your own machine, connected through chat apps you already use like Telegram, Discord, Slack, Feishu/Lark, and it can actually get things done: send and receive emails, manage schedules, automate browsers, execute commands.

OpenClaw supports multi-platform access, a memory system, a skill marketplace (ClawHub), multi-agent collaboration, and even A2A (Agent-to-Agent) — feature-rich.

To use OpenClaw, I bought a Mac Mini, controlled it daily from my phone, built many projects, and became very productive.

To let others use OpenClaw too, I built a hosted service that deployed dedicated lobsters (the mascot) for over 500 users, running on a K8s cluster in the cloud.

While using it myself and running the managed service, I grew to understand OpenClaw’s architecture deeply — and also discovered many problems. To solve them, I realized I had to start from scratch with a new underlying architecture, not just modify OpenClaw.

I decided to build a better Agent framework: FastClaw — designed for cloud-native multi-tenant scenarios, faster, lighter, and easier to use.

This article captures my understanding of OpenClaw’s architecture and the lessons I learned while designing FastClaw’s architecture.

1. What OpenClaw Got Right

Although OpenClaw has many issues, its exploration in product direction was ahead of its time. Looking back, several innovations are truly valuable.

1. Multi-platform access: Interact with your Agent anytime, anywhere

OpenClaw supports an extremely wide range of IM integrations — Telegram, Discord, Slack, WhatsApp, Signal, iMessage, Feishu/Lark, Matrix, Microsoft Teams, plus Web Chat and CLI. Users can talk to their Agent from anywhere.

The core insight behind this design: An Agent should not be trapped inside a single app. When you code, you’re in the terminal; in meetings, you’re in Feishu; while slacking off, you’re on Telegram — your Agent should be everywhere.

2. SOUL mechanism: Give the Agent “personality”

OpenClaw introduced the concept of SOUL.md — a configuration file that defines the Agent’s persona, tone, and values. Not a cold system prompt, but a carefully tuned “soul.”

This brought two unexpected benefits:

• Soaring user stickiness: When an Agent has a fixed persona, users form an emotional connection, leading to retention rates several times higher than purely utilitarian Agents.

• Replicable Agents: The same SOUL file can be used with different models — swap the model, keep the persona.

3. Memory retrieval: It understands you better the more you use it

OpenClaw’s memory system has two layers:

• Long-term summary: MEMORY.md — a concise long-term memory summary injected as project context into prompts.

• Daily details: memory/YYYY-MM-DD.md — daily files that normally stay out of context, retrieved on demand via memory_search/memory_get tools, saving tokens.

Together with SOUL.md (persona), USER.md (user info), and others, the Agent can remember your preferences, habits, and frequently used tools — truly “better the more you use it.”

4. Proactive notifications: From reactive to proactive service

Traditional Agents are “you ask, I answer.” With cron jobs and heartbeat mechanisms, OpenClaw Agents can:

• Send you weather and schedule reminders at 8 AM every day.
• Monitor GitHub PR status and notify you of updates automatically.
• Periodically check blog comments and surface valuable feedback.

This is a critical step in evolving from tool to assistant.

5. Conversational installation: An onboarding experience

Installing a Skill in OpenClaw isn’t “go to the app store and download.” Instead, you simply say in conversation “help me install a translation skill,” and the Agent searches, installs, and configures it itself.

This conversation-as-interface paradigm lowers the barrier to entry and gives the Agent a feeling of growth — you’re training it, equipping it with new abilities.

6. Multi-Agent collaboration: Team mode

OpenClaw supports running multiple Agents simultaneously, each with different specialties:

• One writes code.
• One writes documentation.
• One does code review.
• One handles deployment.

These Agents run in isolation within a single Gateway process, each with its own workspace, state directory (agentDir), and conversation history. Messages are dispatched to the appropriate Agent via multi-agent routing.

2. OpenClaw’s Architecture

OpenClaw uses a Node.js monolithic architecture. Core components include:

• Configuration: A single ~/.openclaw/openclaw.json file manages everything — LLM Providers, Channel Tokens, Plugin config, Skill list, default parameters… all in one JSON file.
• Storage: File-system based. Sessions stored as JSON files, Memory as Markdown, Skills as directories.
• Operation: openclaw start launches a single Node.js process. The Gateway mounts all Channels and Plugins — all for one and one for all.

3. OpenClaw’s Shortcomings

As a personal assistant tool, OpenClaw is sufficient. But as a production-grade, multi-user Agent platform, it has fatal flaws.

1. Lack of platform-level multi-tenancy: Isolation granularity is too coarse

OpenClaw’s isolation is centered around “Agent” — Sessions and Memory are isolated per agent/workspace, but there’s no “account” abstraction. For true isolation, you need “one Agent per person.”

This means the same Agent cannot safely serve multiple mutually untrusted users — hosting it requires spinning up separate instances for each user, which is costly and wasteful. What’s missing isn’t session isolation, but platform-level multi-tenancy.

2. Gateway is a single point of failure

All Channels, all Plugins, and all Agent runtimes hang from the same Node.js process. A single Plugin memory leak crashes the entire Gateway; a single Channel API timeout blocks all Channels.

No isolation means no reliability.

3. Heavy default context, token runaway

Every turn, OpenClaw injects a set of bootstrap files — SOUL.md, MEMORY.md, AGENTS.md, tool descriptions — into the prompt. As files pile up and conversations lengthen, the system prompt keeps growing.

Optimizations exist (on-demand retrieval from memory/*.md, isolated sessions for cron keeping each turn to ~2–5K tokens), but the default configuration is not token-conscious, the bootstrap is verbose, and the bills add up. It hurts to see the cost.

4. High resource consumption

Node.js + a pile of npm dependencies + file system I/O — idle memory usage is over 500 MB. Add Sandbox (Docker containers), and a small 4GB machine struggles to keep up.

5. Unfriendly to cloud-native

• Configuration and state live on the local file system (~/.openclaw/) — multiple Pods can’t share the same config and sessions. Inherently single-machine.
• Storage is file-system based — cannot scale horizontally.
• Deployment model is “a stateful process” — scaling down, migrating, or doing rolling updates has to carefully preserve local data.

6. Bloated npm dependency tree

node_modules takes up 800 MB+, build time 3 minutes+. Every dependency update feels like opening a blind box — you never know which package will break.

7. Poor Web UI experience

OpenClaw’s Control UI and CLI actually share the same ~/.openclaw/openclaw.json (both go through config.get/config.set/config.apply, with base-hash guard against concurrent overwrites) — that part is fine.

The problem is the experience: the Web UI looks rough, configuration items are buried deep, and completing a full Agent setup through the web interface is not intuitive. For a product meant to be used by others, “it works but I don’t want to use it” is a dealbreaker.

8. Security model designed only for “single-machine single-operator”

OpenClaw’s security boundary assumes “the operator is trusted,” not “isolate between untrusted users.” Defaults follow this premise:

• Host execution is wide open by default: exec defaults to full with no approval, sandbox is off by default. The Agent can run arbitrary commands and read/write files directly on the host — the docs admit it’s “intentional UX for single-operator scenarios.”
• Prompt injection not addressed: The system prompt is just a soft hint — one malicious message could make the Agent dump files or run commands.
• API keys in plaintext, sessions unencrypted, plugins run in the main process, no per-user RBAC.

Fine for personal use on a single machine. But to turn it into a multi-user platform, every layer — exec sandbox, key encryption, tenant-level RBAC, injection defense — must be built from scratch.

4. How to Design a Better Agent Framework

FastClaw’s design principles are clear: Lightweight, fast, cloud-native.

1. Cloud-native first

• No local configuration files: Bootstrap parameters are all environment variables. Runtime configuration goes through the Dashboard or CLI into the database.
• SQLite → Postgres: A single FASTCLAW_STORAGE_DSN environment variable switches storage backend — SQLite for local, Postgres for production.
• S3 object storage: FASTCLAW_OBJECT_STORE_* environment variables connect to S3, allowing multiple Pods to share Skills and files.

2. Multi-tenancy and RBAC

OpenClaw is “a tool for one person.” FastClaw is “an Agent platform for many.”

Four-layer configuration inheritance:

Inner layers automatically override outer layers. Same-name Provider configurations are fully replaced. This means:

• An admin configures a default OpenAI key — all users can use it immediately.
• A user wants to use their own key — just override one layer.
• A specific Agent needs a certain model — override another layer.
• No interference, naturally multi-tenant.

3. Session isolation

Each Session is keyed by a quadruple (user_id, agent_id, channel_type, chat_id). One hundred users can interact with the same Agent, and each sees only their own memory and history.

The X-Fastclaw-End-User header allows SaaS layers to pass through the end-user identity. FastClaw automatically creates an isolated internal user for each (api_key, external_id) pair. Zero code changes — multi-tenancy right out of the box.

4. High concurrency

Go’s goroutines are naturally suited for high-concurrency scenarios. FastClaw’s Session Manager can handle thousands of concurrent sessions without blocking each other.

Key design: Sessions are stateless; state lives in the database. Each request loads context from the DB, processes it, and writes back. This means:

• Any Pod can handle any request.
• Horizontal scaling is just adding more Pods.
• If one Pod goes down, other sessions remain unaffected.

5. Single binary distribution

No node_modules, no runtime dependencies, no build steps. Download, chmod, run — three steps and you’re done.

6. Low memory footprint

Comparing OpenClaw (Node.js) and FastClaw (Go) idle memory usage:

Go compiles to native machine code — no GC pauses, no JIT warm-up. With the same hardware, you can handle 10× the traffic.

7. Plugin isolation

OpenClaw’s Plugins run inside the main process — one crashes and the whole Gateway goes down.

FastClaw’s Plugins run as JSON-RPC subprocesses in isolation:

• A Plugin crash doesn’t affect the Gateway; the subprocess auto-restarts.
• Plugins have no file system access unless explicitly authorized.
• Also provides openclaw-plugin-bridge for compatibility with OpenClaw’s TypeScript Plugin ecosystem.

8. Tool Provider fallback mechanism

FastClaw unifies external tools (Web Search, Image Gen, TTS, etc.) with a single Provider + Fallback Chain architecture.

For example, if Web Search has Tavily as primary and SerpAPI as backup, when Tavily is rate-limited, it automatically switches to SerpAPI — the user experiences no interruption.

5. FastClaw’s Architecture Design

Overall Architecture

1. Separation of compute and storage

FastClaw’s most fundamental architectural decision is separating compute from storage:

Compute layer (Gateway):

• Stateless, can scale horizontally.
• Handles LLM calls, tool execution, Session management.
• Any Pod can handle any request.

Storage layer (Database + Object Store):

• SQLite (single machine) or Postgres (cluster).
• S3 stores Skills, Agent files, and other binary data.
• The database is the single source of truth.

This means:

• Data persistence doesn’t depend on process lifecycle.
• Storage backends are swappable (SQLite → Postgres with one config line).
• Multiple Pods share the same database, naturally supporting horizontal scaling.

2. Scope-based configuration inheritance

FastClaw implements chained inheritance of configuration through Scopes.

This gives extreme flexibility:

• Admin sets the global default model to gpt-5 — all new users can use it immediately.
• User A prefers claude-opus — override one layer.
• User A’s “Writing Assistant” Agent needs claude-fable5 — override another layer.
• No code changes, no restart, no extra config files required.

3. Fallback fault tolerance

FastClaw provides fallback for every external dependency:

LLM Provider fallback:

Tool Provider fallback:

Sandbox fallback:

Each fallback layer is transparent to the layers above — the LLM doesn’t know which Provider was actually used, and the user doesn’t need to care.

6. FastClaw’s Positioning and Use Cases

FastClaw is more than just a “better OpenClaw.” It has four progressive roles:

1. Assistant: A better personal assistant

You can install FastClaw on your computer with a single command👇

curl -fsSL https://raw.githubusercontent.com/fastclaw-ai/fastclaw/main/install.sh | bash

Configure FastClaw visually, replace OpenClaw or Hermes Agent for daily use.

Connect the usual IM channels:

Suitable for: Personal AI assistant, Telegram Bot, Discord Bot, Feishu/Lark bot, WeChat ClawBot.

2. Factory: An Agent manufacturing factory

Create your own Agents on the cloud.fastclaw.ai cloud platform.

Customize each Agent’s SOUL, skills, and model.

Suitable for: Skill creators, prompt engineers — build personalized Agents for personal use or to share with friends.

3. Runtime: An Agent runtime

Use FastClaw as an Agent runtime by exporting its API for other Agent products.

For example, weclaw.im uses FastClaw as its backend — only a frontend was needed, and it was deployed in one hour.

Suitable for: Developers wanting to quickly build Agent products without implementing Agent Loop, Sandbox, or other runtime logic.

4. Platform: An Agent collaboration platform

Use FastClaw as a team version of OpenClaw — build an Agent collaboration platform with shared knowledge bases and Skills for your team.

Suitable for: Enterprises that need a privately deployed Agent platform. Just one internal server, quick deployment, infinitely many Agents.

7. Experience Summary for Multi-Agent Framework Design

Throughout the process of building FastClaw, I distilled several lessons.

1. Start single-tenant, but architect for multi-tenant

OpenClaw began as single-tenant, but when the need to add multi-tenancy arose, so many things had to change that it was essentially a rewrite. FastClaw included (user_id, agent_id) isolation in the first line of code — even when only one person uses it, scaling later requires no architectural changes.

Multi-tenancy is not a feature; it’s an architectural decision. The sooner you build it in, the easier it is.

2. Storage determines everything

OpenClaw stores data on the file system — simple and direct. But when you need multi-instance deployment, horizontal scaling, and data backups, the file system becomes a nightmare.

FastClaw uses a database as the single source of truth (SQLite for local development, Postgres for production). The file system only holds Skills directories (which can be shared via S3).

Always store state in a database. Use the file system only for “content” (code, docs, config files), not “state” (Sessions, users, permissions).

3. Isolation is the prerequisite for reliability

OpenClaw runs everything in one process — one component fails, everything fails. FastClaw isolates Plugins via subprocesses, isolates code execution via Docker/E2B, and isolates concurrent writes via database transactions.

If two components have different fault domains, do not let them share a process.

4. Fallback is not optional, it’s essential

LLM APIs get rate-limited, go down, raise prices. Web Search APIs time out. Image Generation queues up. If your Agent becomes completely unusable when any external dependency fails, your Agent is a toy.

Every Tool Category in FastClaw has a Fallback Chain. When the primary Provider fails, the backup kicks in automatically — the user doesn’t notice.

Production-grade Agents must have fallbacks for every external dependency. No exceptions.

5. Tokens are money, context is gold

OpenClaw dumps all context into every request, leading to high token consumption. Later I learned:

• Keep SOUL files lean: 500 tokens is enough — you don’t need to stuff in an entire manual.
• Retrieve memory on demand: Don’t inject everything; use embeddings to fetch relevant memories.
• Summarize Sessions: Periodically compress long conversations, retaining key information and discarding redundancy.
• Layer tool descriptions: Fully describe frequently used tools; just list names for rarely used ones.

Context management is a core competitive advantage for an Agent. An Agent that knows how to save tokens will survive.

Conclusion

The journey from OpenClaw to FastClaw is essentially a shift in mindset from “building a cool open-source project” to “building a platform that runs reliably in production.”

OpenClaw validated the direction — multi-platform access, SOUL mechanism, memory system, multi-agent collaboration — all of those are right.

FastClaw solves the engineering problems — single tenancy, single point of failure, resource waste, lack of scalability — all of which needed fixing.

Great architecture isn’t designed; it’s iterated. But if you get the three things right — separation of compute and storage, multi-tenant isolation, and fallback fault tolerance — before you start iterating, you’ll save yourself a lot of time.

If you’re also building Agent infrastructure, I hope this article helps you avoid some detours.

Welcome to try fastclaw.ai — it’s free and open-source.

https://github.com/fastclaw-ai/fastclaw

Fork it, give it a star — you’re welcome.