AI Agent Frameworks Compared: The Claw Family

February 2026

Six projects, six approaches to the same problem: a personal AI agent that lives on your machine and talks to you through chat platforms. I built all six as experiments in different languages, architectures, and security models. Here's how they compare — and what I learned building each one.

The Landscape

Each framework takes a different stance on what matters most:

• TinyClaw — Bash + TypeScript. Delegates all tool execution to Claude/Codex CLI. The simplest approach: ~20K LOC, file-based message queue, and the best multi-agent team collaboration of the group.
• ZeroClaw — Rust. The most secure foundation with 1,017 tests, but tools aren't wired up yet — it's a well-secured chatbot, not an agent.
• PicoClaw — Go. A complete agent on minimal hardware. Single binary, <10MB RAM, runs on a Raspberry Pi. 10+ channels.
• Nanobot — Python. 3,500 lines, full ReAct loop, easy to hack on. The quickest prototype path.
• OpenClaw — TypeScript. The most feature-complete platform: 38 channel plugins, 53 skill plugins, mobile apps, web dashboard.
• BearClaw — TypeScript. The best architecture of the group: ~4,600 lines, 2 runtime dependencies, parallel tool execution, defense-in-depth security, and the only one that combines team orchestration with subagent delegation.

At a Glance

How They Handle Messages

All six follow the same basic pattern — channel → agent → channel — but the plumbing differs significantly.

TinyClaw uses a file-based queue with atomic fs.rename(). Messages are JSON files moved through incoming/ → processing/ → outgoing/ directories. No central process manages the conversation — the queue processor polls every second and chains messages per-agent using JavaScript promise chains. Simplest approach, easiest to debug (ls queue/incoming/), but single-machine only.

ZeroClaw uses Rust's mpsc::channel (multi-producer, single-consumer) as an in-process message bus. All channels feed into one bus, and the agent consumes from it. Fast and type-safe, but everything lives in one process — a crash takes down all channels.

PicoClaw uses a pub/sub message bus — similar to ZeroClaw but in Go. Channels publish InboundMessage, subscribe to OutboundMessage. Clean decoupling.

Nanobot uses async queues (Python asyncio) — two queues (inbound + outbound) with subscriber callbacks for routing responses back to the right channel.

OpenClaw uses a WebSocket-based gateway server as the central hub. Channels connect as clients, the gateway routes to agent workspaces. The most "enterprise" architecture — hot config reload, session routing, and an auto-reply pipeline with buffering and deduplication.

BearClaw uses an async message bus with an async waiter pattern — consumers block on a promise until a message arrives, so there's no polling. Two queues (inbound + outbound) with the daemon's main loop consuming inbound and dispatching outbound to channels. The message tool lets agents publish directly to the outbound bus from within the agent loop.

How They Call Tools

This is where they diverge the most.

TinyClaw: Delegation

TinyClaw doesn't implement tool calling at all. It shells out to claude or codex CLI with --dangerously-skip-permissions and captures stdout. The CLI handles the entire agentic loop internally. TinyClaw only sees the final text response.

There is no tool registry, no tool interface, no agentic loop. This is a deliberate tradeoff — it gets the full power of Claude Code's tools without reimplementing any of it, but has zero visibility into what the agent does.

PicoClaw: Go Interfaces + Dual-Channel Results

Clean Go interface with a full agentic loop: call provider.Chat() with tool definitions → if tool calls in response, execute each, append results, loop back → if no tool calls, return text.

The interesting innovation is the ToolResult type — separate ForLLM (fed back to the model) and ForUser (shown to the human) fields, plus Silent and Async flags. This gives tool authors fine-grained control over UX without polluting the LLM's context window.

Nanobot: Python ReAct with Reflection

Classic ReAct loop with a twist — after every tool execution cycle, Nanobot injects a "Reflect on the results and decide next steps" message. This nudges the model to synthesize results, but adds fake user messages to every iteration and inflates the conversation. Not needed for modern models that handle tool results natively.

OpenClaw: Event-Driven with Hook System

The distinctive feature is the hook system: before_tool_call (can block or modify args), after_tool_call (fire-and-forget), and tool_result_persist (can redact results before saving). Tools also get an onUpdate callback for streaming partial results — the only project with this. For long-running tools (web fetch, browser automation), streaming progress is a significantly better UX than silence until completion.

BearClaw: Parallel Execution + Hook Pipeline

BearClaw is the only project that executes tool calls in parallel via Promise.all. When the LLM requests read_file on 3 different paths, they all run concurrently — with results appended in original request order, not completion order.

Every tool call passes through a sequential before-hook pipeline (where the PolicyEngine can block or modify args), then JSON Schema validation, then execution, then fire-and-forget after-hooks. Tools receive a ToolContext DI container with the full runtime environment — AbortSignal, SecurityPolicy, PolicyEngine, rate limiter, tool registry, and provider factory. Tools don't import anything directly, which makes testing trivial.

Tool System Comparison

Multi-Agent Collaboration

This is a key differentiator. There are two distinct patterns: team collaboration (agents talk to each other) and subagent delegation (parent spawns child for a task).

TinyClaw has a full team collaboration system with fan-out, sequential handoffs, and shared context — all via queue-based message passing. Agent A can mention [@agent_b: do this] and [@agent_c: do that] in its response, and both get enqueued as internal messages. When all branches resolve, responses are aggregated. No central orchestrator — collaboration emerges from the queue.

PicoClaw and Nanobot have subagent spawning — the main agent delegates tasks to background agents that report back. Useful for parallelism but it's delegation, not collaboration. Subagents don't talk to each other.

OpenClaw has multi-agent workspaces — multiple independent agents with isolated contexts. But they don't collaborate on a single task the way TinyClaw teams do.

BearClaw has both patterns. Like TinyClaw, it has team-based routing with mention-driven fan-out/fan-in. Like PicoClaw/Nanobot, it also has subagent spawning via the spawn tool where child agents get restricted tool registries. It's the only project that combines team collaboration with tool-level subagent delegation.

ZeroClaw is single-agent only.

Security Comparison

This is the most important differentiator. Ranked from most secure to least:

1. ZeroClaw — Grade: A

Zero critical or high findings. Defense-in-depth throughout:

• Filesystem sandboxing (blocks 14 system dirs, symlink escape detection, null byte injection blocked)
• Command allowlisting with injection pattern blocking
• Autonomy levels: ReadOnly → Supervised → Full
• Encrypted secrets (ChaCha20-Poly1305 AEAD)
• Pairing auth with CSPRNG codes, 5-attempt lockout
• Rate limiting (20 actions/hour default)
• 1,017 tests including security edge cases

2. OpenClaw — Grade: B+

Security-conscious engineering:

• Ed25519 device identity, timing-safe auth, challenge nonces
• SSRF protection (blocks RFC 1918, link-local, loopback, metadata endpoints, DNS pinning)
• Command injection prevention (shell: false on all spawn() calls)
• Log redaction (API keys, tokens, PEM blocks scrubbed)
• Plugin security scanner (detects eval(), shell execution, crypto mining patterns)
• Scope-based access control with default-deny permissions

3. BearClaw — Grade: B

No critical or high findings. The most layers of any project:

• Encrypted secrets (ChaCha20-Poly1305 with 0o600 permissions, auto encrypt-on-startup)
• Pairing auth (CSPRNG codes, SHA-256 hashed tokens, brute-force lockout)
• PolicyEngine (rule-based before-hooks), SecurityPolicy (path/command validation), sliding window rate limiting (scoped per-agent/per-tool)
• SSRF guard (connects directly to resolved IP — prevents DNS rebinding)
• Symlink resolution on read/write, command blocklist (backticks, $(), ${}, redirections)
• Only 2 runtime dependencies — tiny attack surface

4. PicoClaw — Grade: C+

Good intent, but the sandbox has holes — critical symlink bypass, bypassable regex deny-list, world-readable config file, no SSRF protection. Auth token storage and OAuth PKCE are done well.

5. TinyClaw — Grade: C

Secure pairing, but no sandbox by design — all security is disabled via CLI flags. File exfiltration, command injection, and plaintext credentials are all concerns.

6. Nanobot — Grade: D

Dangerous defaults: allowFrom: [] means allow everyone, arbitrary shell execution with a cosmetic blocklist, the "read URL and follow instructions" pattern is prompt injection as a feature.

Resource Efficiency

ZeroClaw and PicoClaw can run on a $10 single-board computer. BearClaw is the leanest Node.js option — only 2 runtime dependencies, no SDKs, all provider integrations use raw fetch().

Patterns Worth Stealing

ForLLM / ForUser Split (PicoClaw, BearClaw)

The best idea across all six projects, arrived at independently by two of them. Most tool systems return a single string for both LLM reasoning and user display. Separating these gives tool authors fine-grained UX control without polluting the LLM's context window.

Before-Hook Pipeline (OpenClaw, BearClaw)

Intercepting and blocking or modifying tool calls before execution — at the dispatch layer, not inside each tool. This is the right place for security policies, rate limits, and audit logging. BearClaw's hooks run as a sequential pipeline where each hook can modify args for the next.

Parallel Tool Execution (BearClaw)

When the LLM requests read_file on 5 files, there's no reason to wait for each to complete sequentially. BearClaw is the only project that uses Promise.all with order preservation.

TinyClaw's "Don't Reimplement" Philosophy

Not having a tool system is a valid design choice. TinyClaw gets Claude Code's full tool suite for free. The team collaboration layer is completely decoupled from tool execution.

Patterns to Avoid

Reflection Nudges (Nanobot)

Injecting "Reflect on the results" after every tool execution inflates the conversation and isn't needed for modern models. If a specific model needs this, it should be a per-provider behavior.

Sequential-Only Execution (Nanobot, PicoClaw, OpenClaw)

When the LLM asks to read 5 files, executing them one at a time adds latency linearly. Only BearClaw gets this right.

Mutable Tool State (Nanobot)

Overwriting tool context with each new message creates race conditions in concurrent processing. Pass context per-execution instead.

sh -c Without Strong Guards

Passing commands through a shell opens injection vectors. OpenClaw's shell: false approach is the safest. If you must use a shell, BearClaw's comprehensive blocklist is the minimum bar.

Full Feature Matrix

When to Use What

TinyClaw — You want multi-agent teams accessible from your phone. You trust your machine and want the full power of Claude Code without reimplementing tool systems. Personal use only.

ZeroClaw — You want the most secure foundation to build on. Best-in-class sandboxing and crypto. But tools don't work yet — it's a secured chatbot, not an agent.

PicoClaw — You want a complete agent on minimal hardware. Full tool loop, subagents, 10+ channels, runs on a Raspberry Pi. Fix the symlink bypass before exposing to untrusted input.

Nanobot — You want a quick prototype in Python. 3,500 lines, full ReAct loop, easy to hack on. Lock it down before running in production.

OpenClaw — You want the most feature-complete platform. 38 channels, 53 skills, mobile apps, web dashboard. Most "product-grade" of the six.

BearClaw — You want a well-architected framework you can actually read. ~4,600 lines, 2 dependencies, the most complete tool system, team orchestration AND subagent spawning, encrypted secrets, and a real security model. Built by taking the best ideas from the other five and starting fresh.

What I'd Build Next

BearClaw already combines the best patterns from the other five projects. The remaining gaps to close:

1. Add streaming progress — OpenClaw's onUpdate callback pattern for long-running tools
2. Add result redaction — OpenClaw's tool_result_persist hook for scrubbing sensitive data before saving
3. Switch to shell: false — OpenClaw's approach is fundamentally safer than any blocklist
4. Close symlink gaps — edit_file, list_dir, and search still skip realpath() validation
5. Skip the reflection nudge — modern models don't need it

The personal AI agent space is still wide open. These are all experiments, but the patterns — structured tool results, dispatch-layer security hooks, parallel execution, team orchestration — are production-ready ideas waiting for the right packaging.

Try BearClaw

BearClaw is open source and available on GitHub. Install it with:

npm install -g bearclaw

Or check out the BearClaw project page for more details.

Want to stay updated on AI agent framework developments? Subscribe below for future guides and analysis.