8 agents, 21 skills, 15 scheduled jobs. It looks like an L3 system. But the right question isn't "how many components do you have", it's "how do they interact". This article looks at where OpenClaw sits on the agentic autonomy scale, what it already gives you out of the box, and what you need to build on top of it to move from L2 to L3.
What is OpenClaw, and why does it already start at L2?
OpenClaw is an open-source Node.js framework for persistent AI agents. LangChain, CrewAI and AutoGen orchestrate LLM chains as one-shot scripts. OpenClaw builds always-on agents with separate identities, each with its own workspace, its own sessions and its own communication channels.
Out of the box, the framework includes a gateway that hosts N agents as embedded processes, each with an isolated workspace and its own auth profile. Every agent has a skill system with a router and a routing table that maps inputs to workflows. Scheduled jobs use standard cron syntax and run in isolated sessions. Memory persists across sessions. Connectors cover Telegram, WhatsApp and webchat. Playwright is built in for browser automation.
This isn't L1. A chatbot that answers questions is L1. A system with multiple agents, skill routing, scheduled execution and memory is already L2, semi-autonomous, according to the NVIDIA and Sema4.ai frameworks.
L2 means the agent makes decisions at predetermined points in a flow. It has the tools and knows how to use them, but it fires them on fixed triggers. A cron job that runs a skill at 08:00 is L2. The agent decides what to do inside the skill, but not when or whether to run it in response to changing conditions.
What separates L3 from L2, according to the reference frameworks?
Three independent frameworks land on a similar 4-5 level scale: NVIDIA, Sema4.ai and Dextra Labs.
| Level | Name | Behavior | Architectural differentiator |
|---|---|---|---|
| L1 | Assistant | Responds to single commands, no planning, stateless | No loop. Single input/output |
| L2 | Semi-autonomous | Decides at fixed points in a predefined flow, limited branching | Acyclic graph (DAG). No feedback loop |
| L3 | Conditional autonomy | Plans, executes, reflects, corrects. Chooses tools freely | Execution loops. The agent can go back, replan, retry |
The key difference: at L2 you can list every decision path (it's a DAG). At L3, loops show up. The agent can reject an output, go back to an earlier phase and try again with different parameters. NVIDIA defines L3 like this: the AI model freely decides whether, when and how to call tools, and it can revise its own plan mid-execution.
The technical dividing line isn't the number of agents or skills. It's the topology of the flow. If the execution graph contains loops, you're at L3. If it's linear or branched with no cycles, you're at L2.
What's the gap between OpenClaw at L2 and an L3 system?
OpenClaw OOB gives you the building blocks. Three layers are missing to close the gap to L3.
| Capability | OpenClaw OOB (L2) | What L3 needs |
|---|---|---|
| Skill execution | Fixed trigger (cron or user command) | Dynamic orchestration: an agent chooses which skill to call based on the task state |
| Execution flow | Linear (DAG): trigger → skill → output | Cyclic: trigger → skill chain → review gate → feedback loop → retry/advance |
| Knowledge loading | Full context loaded on every call | Selective: a resolver that assembles only the modules the specific workflow needs |
| Cross-skill coordination | Each skill is independent | Multi-phase pipeline: state passes between skills through a shared JSON file |
| Self-maintenance | Manual: editing a skill = risk of breaking dependencies | Automatic: dependency map, validation script, knowledge base auto-reindex |
| Knowledge base | The agent's text memory | Vector RAG: embeddings + semantic search across all workflows and procedures |
Layer 1: Orchestration with a feedback loop
The architectural jump from L2 to L3 is the orchestrated pipeline. An orchestrator agent coordinates N specialized skills in sequence and passes state through a shared JSON file. Each skill reads the current state, does its job and writes the result.
The Reviewer acts as a review gate. It can block publication and send the content back to an earlier phase. That feedback loop is the architectural trait that makes the flow non-DAG, and therefore L3.
Every transition is a decision made on the fly. The orchestrator picks the right workflow by reading the task type from the state. The Copywriter chooses between different modes based on the schedule. The Publisher decides whether to use the API or browser automation based on the target platform.
Layer 2: Selective knowledge management
The standard approach to multi-agent systems is to load the whole context into every call: every operating procedure, every API reference, every configuration. With 8+ agents and 20+ workflows, that means 25-35K tokens of context for every single call, most of it irrelevant to the task at hand.
The fix: a resolver that assembles context on demand. Each workflow declares its dependencies explicitly with markers (READ modulo-x). When the agent runs a workflow, the resolver finds every marker, resolves them by inlining only the referenced modules, and produces a complete, self-contained document. The agent gets 3-8K tokens of surgical context instead of 30K+ of generic context.
On top of that sits a vector knowledge base (RAG): every workflow and procedure is indexed with semantic embeddings. When an agent needs information the current workflow doesn't cover, it can run a semantic search on the knowledge base without loading everything into context.
Layer 3: Self-maintenance
An L3 system that needs a human for routine maintenance isn't really L3. Two mechanisms close the gap.
A script generates a full dependency graph that maps which workflows use which shared modules and which skills call which other skills. Before you change a shared module, the graph shows you exactly what depends on it. A second validation script checks that every reference points to a real file and that every entry in the routing table is valid.
For reindexing, a service watches the workflow directory. When a file changes, it waits for a debounce, indexes the updated content in the vector knowledge base and regenerates the dependency graph. The agents always work with current information, with no manual step.
What do the performance numbers look like going from L2 to L3?
We don't have formal benchmarks on standardized datasets. What follows are estimates based on comparing the standard approach (pre-optimization) with the current setup, measured on the system's real operations.
| Metric | Standard approach (context dump) | L3 setup (skill resolution) | Delta |
|---|---|---|---|
| Tokens per agent call | 25-35K (full context loaded) | 3-8K (only the modules needed) | -75/80% |
| Average response time | 12-18s (long context = slow inference) | 4-8s (short context = fast inference) | -55/60% |
| Procedural accuracy | ~70% (the agent ignores parts of the noisy context) | ~92% (surgical context = fewer errors) | +22pp |
| Human intervention for errors | 3-5 times/day (steps skipped or misread) | 0-1 times/day (procedures followed precisely) | -80% |
| System maintenance | Manual: every change needs checking by hand | Automatic: validation + auto-reindex | ~0h/week vs ~2h |
Why does accuracy go up?
The problem with a context dump is diluted attention. When an agent gets 30K tokens of mixed context (procedures for 8 different platforms, API references the current task doesn't need, other agents' configurations), the model has to decide what's relevant. With today's models that works "almost always", but that 30% of errors clusters around procedural details: skipped steps, parameters mixed up between platforms, wrong formats.
With selective context, the agent only gets the procedure for that specific platform and the API references that workflow needs. There's nothing to ignore. Accuracy goes up because the problem gets simpler for the model, not because the model gets smarter.
These estimates come from operational observation, not controlled benchmarks. The numbers vary with workflow complexity, the model you use and the volume of context. The pattern (less context = more accuracy) holds up well, but the exact figures are indicative.
Where do the token savings come from?
The math is simple. A system with 9 shared modules (platform configuration, API references, state patterns, operating procedures) adds up to ~18-20K tokens. A single standard call loads all of it. With the resolver, an average workflow references 2-3 modules for ~2-4K tokens, plus the workflow itself (~1-3K). The savings grow linearly with the number of calls: at 50-80 calls/day, the difference is ~1-2M tokens/day.
How do you replicate this architecture?
Three principles drive the design. They apply to any multi-agent framework, not just OpenClaw.
Principle 1: Keep orchestration separate from execution
The orchestrator doesn't execute anything. It coordinates. Each phase is handed to a specialized skill with its own routing, its own workflows and its own dependencies. The orchestrator passes a task identifier, and each skill reads and writes its own piece of state in a shared JSON file.
Principle 2: Explicit state, never implicit
Every task has a JSON file with the full structure: type, target platforms, completed phases, intermediate outputs. Each skill reads the current state, updates only the fields it owns (the read-modify-write pattern) and writes the result. No information passes "in memory" from one agent to another. Everything lives on disk, where you can inspect it and debug it.
Principle 3: Architectural guardrails, not just prompts
The limits of autonomy don't live in the system prompts. They live in the structure: a routing table that limits which workflows an agent can run, a review gate that blocks publication without approval, platform-specific operating procedures that set non-negotiable rules (text length, format, posting times). The agent has freedom inside those limits. It can't step outside them by design, not by instruction.
What's the next step toward L4?
L3 is conditional autonomy. L4, according to Sema4.ai, is self-refinement: the system improves its own tools, creates new skills and changes its own procedures based on the results it observes.
Some of this already exists in early form: a weekly report analyzes how published content performed and spots patterns, like which formats do best and which posting times drive the most engagement. The concrete step toward L4 is to have those patterns update the operating procedures and scheduling parameters automatically. Once the system doesn't just execute but improves its own rules based on data, the line between L3 and L4 starts to blur.
Cosa ottieni iscrivendoti:
- Accesso a tutti gli episodi della newsletter
- Guide e corsi completi sull'AI per marketer
- Strumenti AI professionali (BrandPix, Short Video Suite)
- Crediti gratuiti per iniziare subito