NanoClaw and the Agent Factory
You have spent eight lessons with one AI Employee. You set it up on your messaging channel, gave it real work, watched it delegate to a coding agent, connected it to your actual Google Workspace, and assessed what works and what remains unsolved.
Through all of that, one truth kept reinforcing itself: the patterns work. Gateway, channels, memory, skills, scheduling, delegation -- these are universal. OpenClaw proved it at 209,000-star scale, and the ecosystem responded. Developers who saw the same patterns asked: what if I optimized for different constraints?
This isn't just our opinion -- it's an empirical finding. In early 2025, researchers at MIT published the AI Agent Index, the first public database documenting the technical components, intended uses, and safety features of deployed agentic AI systems. They cataloged 30 prominent AI agents across chat, browser, and enterprise categories, with 24 launched or significantly updated in 2024–2025 alone. The most striking finding wasn't the pace of deployment -- it was what was missing. The researchers found limited information about the risk management practices of most developers, including their safety policies, internal testing, and external testing. In plain language: the industry is shipping autonomous agents at an accelerating rate, and most builders aren't documenting how those agents fail, what boundaries they operate within, or how they've been tested. That is the gap this chapter exists to close. Every security boundary you define, every threat model you build, every chaos test you run -- you're doing the work that MIT found most of the industry is skipping. Spec-driven development isn't overhead. It's the difference between a production system and a demo that hasn't broken yet.
The security realities from Lesson 5 -- 135,000 exposed instances, malicious skills on ClawHub, the one-click RCE vulnerability -- are real engineering challenges. They are not unique to OpenClaw. They emerge whenever all agent components run in a shared process, which is the most common architecture for good reason: it is simple to build and simple to deploy. But when your threat model includes patient records, financial data, or legal documents, a different architecture earns its complexity.
Meet NanoClaw
On January 31, 2026, a developer named Gavriel Cohen released NanoClaw. Where OpenClaw optimized for feature completeness and community reach, NanoClaw optimized for a different constraint: container isolation for sensitive data. Strip everything down to roughly few hundred lines of core TypeScript, isolate every agent inside its own container, and plug in the Claude Agent SDK for the actual reasoning.
Here is how the two architectures differ -- not better or worse, but optimized for different threat models:
| Property | OpenClaw (Your Chapter 7 Experience) | NanoClaw |
|---|---|---|
| Codebase | 430,000+ lines, 52+ modules, 45+ dependencies | ~500 lines core, handful of files, minimal dependencies |
| Isolation model | Application-level (allowlists, pairing codes) | OS-level containers (Apple Containers on macOS, Docker on Linux) |
| Auditability | Effectively un-auditable by a single person | Full review in approximately 8 minutes |
| Agent boundaries | All agents share memory and filesystem | Each agent gets its own container with isolated filesystem |
| Security default | Everything accessible unless explicitly restricted | Nothing accessible unless explicitly granted |
| Extension model | Feature PRs that grow the codebase | Claude Code skills that transform your fork |
NanoClaw is not a replacement for OpenClaw -- the 209,000-star project that validated the entire category remains the most feature-complete and community-supported option. NanoClaw is a different architectural answer optimized for a specific constraint: when the data inside the agent boundary is too sensitive for a shared process.
Body + Brain: Separating What OpenClaw Combined
Remember the seven components from Lesson 4? OpenClaw runs all of them -- Gateway, channels, memory, skills, scheduling -- in one shared process. That is what makes it easy to set up (Lesson 2) and what makes it vulnerable (Lesson 5).
With NanoClaw we can separate the AI Employee system into three distinct components:
| Component | Role | What It Provides |
|---|---|---|
| NanoClaw (the Body) | Always-on infrastructure | Container isolation, WhatsApp channel, per-group memory, cron scheduling, Agent Swarms, MCP integration, full auditability |
| Claude Agent SDK (the Brain) | Deep reasoning engine | Programmatic Tool Calling, local code execution, context management, tool orchestration |
| OpenAI Agents SDK (the Orchestrator) | Multi-agent coordination | Agent handoffs, routing between specialists, guardrails, tracing with 10+ integration targets |
The Body stays running 24/7, receiving messages, managing state, enforcing container boundaries. The Brain activates when reasoning is needed -- generating code, analyzing data, making decisions. The Orchestrator coordinates when multiple agents need to collaborate on complex tasks.
This separation matters because you can upgrade each component independently. Swap Claude Agent SDK for a different reasoning engine without touching the messaging infrastructure. Add new communication channels to NanoClaw without modifying the intelligence layer. Replace the orchestration framework without rebuilding your agent's knowledge.
What the Body Provides
NanoClaw's Body gives a Vertical AI Employee seven capabilities you saw pieces of in OpenClaw, but now each runs inside container isolation:
- Container isolation: Every agent task executes in its own OS-level container. No shared memory between agents. This directly addresses the CVE-2026-25253 vulnerability class from Lesson 5 -- even if an attacker gained WebSocket access, commands would execute inside a container with access only to mounted directories, not the host system.
- Multi-channel presence: WhatsApp integration out of the box via @whiskeysockets/baileys, with additional channels (Telegram, Slack, email) added via Claude Code skills.
- Per-group memory: Each conversation group gets its own isolated filesystem, dedicated CLAUDE.md memory context, and separate container sandbox. Remember how OpenClaw's memory files (Lesson 4) were shared across the system? NanoClaw isolates them per conversation.
- Cron scheduling: Built-in task scheduler supports cron, interval, and one-time scheduling -- the same autonomous invocation pattern from Lesson 3, but now each scheduled task runs in its own container.
- Agent Swarms: NanoClaw is the first personal AI assistant to support Agent Swarms -- teams of specialized Claude instances that collaborate on complex tasks in parallel, each in its own isolated container. This extends the delegation pattern from Lesson 6 beyond a single coding agent.
- MCP integration: Native Model Context Protocol support, providing standardized tool interfaces between the host process and agent containers.
- Full auditability: The entire codebase can be reviewed in 8 minutes. Every line is accountable.
The critical architectural choice: NanoClaw runs Claude Code directly inside each container. NanoClaw's creator describes Claude Code as "the best harness available" for AI agents -- it provides full shell access, filesystem tools, browser control, web search, and context compaction for long-running tasks, all within container isolation.
What the Brain Provides
Inside each NanoClaw container, the Claude Agent SDK provides the reasoning engine. But the critical differentiator is Programmatic Tool Calling: the agent writes and executes local Python scripts to process sensitive data, rather than sending raw files to the LLM.
Think about what this means for the Google Workspace integration you set up in Lesson 7. Your AI Employee had OAuth access to your Gmail, Calendar, and Drive. In OpenClaw's architecture, that data flows through the shared process. In NanoClaw's architecture, data stays inside the container:
- The Body receives a message via WhatsApp: "Analyze Q3 receivables for overdue accounts."
- NanoClaw spawns an isolated container with access only to explicitly mounted financial data directories.
- The Brain generates a Python script to parse the files, calculate aging buckets, and identify overdue accounts. The script runs locally inside the container.
- Only analysis results -- summary statistics, flagged accounts, recommendations -- return to the LLM for synthesis. Raw financial data never leaves the container.
- The container is destroyed after execution. No persistent access to sensitive data remains.
This pattern -- Programmatic Tool Calling -- is what makes AI Employees architecturally possible for regulated industries. HIPAA does not permit patient data to traverse external API calls to language model providers. SOX does not allow financial records to pass through third-party inference endpoints without audit controls. Keeping the data local while still leveraging AI reasoning is not a nice-to-have. It is a requirement.
What the Orchestrator Provides
For multi-agent workflows -- like the advisory council from Lesson 8 where multiple expert agents analyze a business problem -- the OpenAI Agents SDK serves as the orchestration layer. Its MIT license, model-agnostic design (supporting 100+ LLMs), built-in Handoff mechanism, Guardrails, session management, and tracing make it the coordination layer above the Brain. Claude handles deep reasoning; the orchestrator routes work to the right specialist.
Your Skills Are Already Portable
Here is something you may not have realized: the skills you learned to create in Lesson 5 are already an open standard.
In December 2025, Anthropic released Agent Skills as an open standard at agentskills.io. The SKILL.md format you used -- YAML frontmatter with Markdown instructions -- is the same format that works in Claude Code, OpenAI Codex, Cursor, GitHub Copilot, Gemini CLI, OpenClaw, NanoClaw, and dozens more. ClawHub alone hosts over 3,000 community-built skills using this exact format.
But skills are only half of what a professional AI Employee needs. Skills encode domain knowledge -- how to THINK about a problem. MCP servers encode domain tools -- how to ACT within a domain. Together, they create something more powerful than either alone:
| Standard | What It Encodes | Analogy | Example |
|---|---|---|---|
| Agent Skills (agentskills.io) | Domain knowledge -- how to THINK about a problem | A textbook | A HIPAA compliance skill that knows patient data handling rules |
| MCP (Model Context Protocol) | Domain tools -- how to ACT within a domain | A toolbox | A FHIR client MCP server that reads and writes electronic health records |
Both standards are supported across every major agent platform. This means something concrete for you: a HIPAA compliance skill you build works in Claude Code, NanoClaw, Codex, and every platform that adopted the standard. If a better Body framework than NanoClaw emerges, your skills and MCP servers port over unchanged. If a better Brain than Claude appears, the same intelligence works with it. The investment in domain expertise is permanent. The infrastructure around it is replaceable.
Agents Building Agents
OpenClaw grew to 430,000+ lines because every new capability meant new code: new modules, new integrations, new configuration options. Each addition increased the attack surface and made the codebase harder to audit. Remember from Lesson 5 how Koi Security found 341 malicious skills among 2,857 on ClawHub? A larger codebase means more places for things to go wrong.
NanoClaw takes a fundamentally different approach. Instead of adding features through code contributions, contributors add Claude Code skills. Want HIPAA compliance? That is a skill the agent loads on demand, not a module compiled into the codebase. Want FHIR integration? That is an MCP server the agent connects to, not a library dependency.
This means building a professional AI Employee is driven by skills, not by code:
/add-hipaa-compliance-- Claude Code adds HIPAA-compliant data handling, audit logging, and container security configuration to your NanoClaw fork/add-fhir-integration-- Claude Code builds the FHIR MCP server, connects it to your EHR system, and configures NanoClaw to expose it to the Brain/add-financial-audit-- Claude Code creates the financial ratio MCP servers, adds scheduled audit tasks to NanoClaw's cron, and installs the GAAP compliance skill
Installing NanoClaw itself demonstrates this pattern. The entire setup is three steps:
git clone https://github.com/gavrielc/nanoclaw.git
cd nanoclaw
claude
Then you run /setup and Claude Code handles everything: dependencies, WhatsApp authentication, container setup, service configuration. No manual configuration files. No dashboard. Claude Code reads the codebase (which it can understand in 8 minutes), follows the setup skill instructions, and configures the system.
This creates a recursive loop: Claude Code builds and configures NanoClaw (the Body), which runs Claude Agent SDK (the Brain), which uses Claude Code skills (the intelligence) to extend its own capabilities. Agents building agents.
The Bigger Picture: Why This Book Is Called Agent Factory
Step back from NanoClaw for a moment. Look at what has happened in the market:
Devin proved the AI Employee model for coding -- over $2 billion valuation, one vertical, one AI Employee that writes software. Harvey proved it for law -- $8 billion valuation, in talks at $11 billion. Manus proved horizontal value -- $2 billion Meta acquisition. These are not experiments. They are businesses.
Medicine does not have its definitive AI Employee. Neither does accounting, finance, HR, or dozens of other regulated professions. Every profession will need its own. And now you have seen the building blocks.
When you combine Body + Brain separation, portable intelligence standards, and agents building agents, a reference architecture emerges:
| Layer | Name | Purpose | Example Components |
|---|---|---|---|
| 6 | Body | Always-on presence, scheduling, Agent Swarms | NanoClaw |
| 5 | Orchestration | Multi-agent routing, handoffs, guardrails, tracing | OpenAI Agents SDK |
| 4 | Brain | Deep reasoning, Programmatic Tool Calling | Claude Agent SDK |
| 3 | Intelligence | Portable domain knowledge + executable tools | Agent Skills + MCP servers |
| 2 | Data | Persistent state, domain knowledge, vector search | PostgreSQL, Redis, vector DB |
| 1 | Security | Container isolation, sandboxes, audit logging | NanoClaw containers, Docker |
One layer stands apart. Layers 1, 2, 4, 5, and 6 are all tied to specific platforms and implementations. Replace NanoClaw with a different body, and Layer 6 changes. Switch from Claude Agent SDK to a different reasoning engine, and Layer 4 changes.
Layer 3 -- Intelligence -- is the only fully platform-independent layer. Your Agent Skills and MCP servers work across every platform in the portability matrix. This is where your investment compounds. Everything else is infrastructure. Layer 3 is expertise.
And that expertise maps directly to professions:
| Profession | Agent Skills (How to Think) | MCP Servers (How to Act) | Why Container Isolation Matters |
|---|---|---|---|
| Medicine | HIPAA compliance, clinical decision support, drug interaction protocols | FHIR client, PubMed search, dosage calculator, formulary DB | Patient data must never leave the container boundary |
| Accounting | GAAP/IFRS standards, SOX audit procedures, tax code logic | QuickBooks/Xero API, bank feed connectors, depreciation calculator | Financial records require SOX compliance |
| Law | Jurisdictional rules, privilege protocols, citation standards | Case law databases, court filing APIs, damages calculator | Attorney-client privilege demands strict isolation |
| Finance | Risk assessment frameworks, regulatory compliance | Trading APIs, portfolio analytics, market data feeds | Zero-trust environments with position-level access control |
| HR | Employment law, bias detection, compensation benchmarks | HRIS systems, payroll APIs, background check services | Employee PII requires strict containment |
In each case, the pattern is identical: domain knowledge encoded as Agent Skills, domain tools exposed as MCP servers, all running inside container isolation so sensitive data never leaves the boundary.
This is what this book is about. Not just using AI Employees -- building them. An Agent Factory: a system for creating professional-grade AI Employees for every vertical, using portable standards that survive any platform change.
What Connects
Every concept in this lesson grew from something you already learned:
| This Lesson | Grew From | The Connection |
|---|---|---|
| Container isolation | Lethal trifecta from Lesson 5 | Inverts the security default: nothing accessible unless granted |
| Body + Brain separation | 7 components from Lesson 4 | Separates what OpenClaw combined into one shared process |
| Per-group memory | MEMORY.md from Lesson 4 | Same concept, but isolated per conversation instead of shared |
| Agent Swarms | Delegation from Lesson 6 | Multiple Claude instances in parallel, each in its own container |
| Agent Skills portability | SKILL.md from Lesson 5 | The format you already learned is an open standard everywhere |
| MCP as tool standard | I/O Adapters from Lesson 4 | Domain tools exposed as standardized interfaces across platforms |
| Programmatic Tool Calling | Google Workspace from Lesson 7 | Your data stays in the container instead of flowing through shared process |
| Agents building agents | Delegation from Lesson 6 | Claude Code builds the system that runs Claude Code |
Nothing in this lesson is disconnected from what you experienced in Lessons 1 through 8. NanoClaw is not a separate topic. It is a different architecture built from the same patterns -- and it points toward the AI Employees you will learn to build in this book.
Try With AI
Prompt 1: Connect the Patterns
Setup: Use Claude Code or any AI assistant.
I learned 6 universal AI Employee patterns in Chapter 7 by using OpenClaw
(gateway, channels, memory, skills, scheduling, delegation). Now I've
seen NanoClaw's Body + Brain architecture. Map each of the 6 patterns
to where they live in NanoClaw's six-layer reference architecture.
Which patterns stayed the same? Which ones changed architecturally?
What you're learning: Architectural comparison as a design skill. The patterns are universal -- the six-layer architecture is one way to stack them. Mapping between OpenClaw and NanoClaw reinforces that the patterns matter more than any single implementation. This is what lets you evaluate any new AI Employee framework in minutes.
Prompt 2: Design Your Domain's Intelligence
Setup: Use Claude Code or any AI assistant.
Design the Layer 3 (Intelligence) for an AI Employee in
[YOUR PROFESSION OR INTEREST]. List 3 Agent Skills (domain knowledge --
how to think) and 3 MCP servers (domain tools -- how to act). For each
skill, explain what domain rules it encodes. For each MCP server, explain
what system it connects to. Then identify which pieces of data must NEVER
leave the container boundary and explain why.
What you're learning: Layer 3 design -- the only fully platform-independent layer. By designing for your own domain, you practice the exact process that creates portable vertical intelligence. The container boundary question forces you to think about data sensitivity before you build, not after a breach.
Prompt 3: Portability Stress Test
Setup: Use Claude Code or any AI assistant.
I built a HIPAA compliance Agent Skill and a FHIR client MCP server for
a medical AI Employee running on NanoClaw. My organization now wants to
switch to a different platform. Walk me through what stays the same and
what changes for each of the six layers (Security, Data, Intelligence,
Brain, Orchestration, Body). Which layers require the most work to migrate?
Which layer requires zero work?
What you're learning: Platform migration as an architectural litmus test. The answer reveals why Layer 3 investment is the most durable -- your Agent Skills and MCP servers transfer with zero changes while infrastructure layers require varying degrees of rework. Understanding this before you build prevents the most expensive mistake in agent development: building expertise that is locked to a single platform.