Context

The bottleneck in 2026 is no longer model quality — it is orchestration. AaaS combines autonomous AI agents with cloud-based delivery to automate complex workflows without constant human oversight. MAaaS extends this further: multiple agents collaborating, dividing labor, and executing in parallel. This article is about building that foundation in OpenClaw.

#	Idea	In Plain Terms
1	The bottleneck has shifted	Frontier models are capable enough. What fails in production is not the LLM — it is the system around it: routing, isolation, memory, and control.
2	Isolation is the default	Each agent operates in its own workspace, session store, and auth context. Nothing is shared unless explicitly configured. This is a feature, not a limitation.
3	The gateway routes, it does not orchestrate	OpenClaw’s gateway decides which agent receives a message. It does not decide what agents should do next or how they should collaborate. That logic lives in SOUL.md and your config.
4	Division of labor beats generalism	A specialist agent with a focused SOUL.md and a matched model outperforms a single generalist agent trying to handle everything. Knowing what each agent should NOT do is as important as what it should do.
5	Shared memory is the simplest coordination	Before reaching for `sessions_spawn` or `sessions_send`, shared `MEMORY.md` covers most coordination needs. It is auditable, human-readable, and does not require direct agent-to-agent messaging.

From the Pipeline

This NetOps security assessment used five agents across a /24 subnet with 17 alive hosts, scanning ports 1–65535 in three phases, managed via Telegram and resulting in a report.

Observation	What It Means in Practice
5 agents ran across 3 phases	Multi-agent is not optional for complex workflows — context window limits make it a necessity, not a choice. No one can work alone.
2 portscan subagents ran in parallel	Parallel execution is real and works. The LLM decided to spawn both simultaneously — no additional config required beyond SOUL.md intent.
Session keys are UUID-based, not named	You cannot address a subagent by name after it is spawned. This limits deterministic coordination — a key constraint covered in Part 2.
architect-review killed at 25m 51s	Long-running subagents pose risks due to the lack of session timeouts. The orchestrator resolved this by handling tasks internally.
40 sessions accumulated	Session accumulation is real and requires active monitoring. Token budgets per session (200K default) add up quickly across a fleet.
Final report: 22,159 bytes PDF	The main orchestrator agent handled Phase 3 in-house. Knowing when NOT to spawn another agent is as important as knowing when to spawn one.

Why Multi-Agent?

The real-world analogy

Think of it as the difference between one generalist employee and a small specialized team. Your network engineer handles infrastructure, your analyst handles security reporting, and they share context when needed but operate independently. OpenClaw multi-agent works the same way.

This is based on a real pipeline: three phases, five parallel agents, scanning 17 network hosts across ports 1–65535, producing a security report — all orchestrated from a single Telegram conversation.

The single-agent ceiling

Context window fills up when an agent juggling research, drafting, code review, and scheduling simultaneously runs out of room mid-task.
Mixed concerns degrade output quality when a generic prompt trying to cover both "run an nmap scan" AND "interpret CVE severity" produces shallow results on both.
A single agent cannot specialize; a network automation agent should not also be writing security compliance reports. The skills, context, and model prompts are fundamentally different.

A single OpenClaw agent is a capable tool. But in practice, it has a ceiling that most users hit quickly.

What “multi-agent” actually means in OpenClaw

Multiple isolated agents inside one gateway process, each with its own workspace, memory, and model.
Channel-based routing: each agent handles specific messaging channels or contacts.
Limited native coordination via sessions_spawn and sessions_send (covered in Part 2).

It does NOT currently mean fully autonomous peer-to-peer agent communication out of the box. That capability is under active development (RFC: Agent Teams) and available via a community plugin, covered in a separate article.

Architecture Concepts

The diagram below shows NVIDIA's NemoClaw reference architecture announced at GTC 2026 - built on OpenClaw.
We highlighted the element called SUB-AGENTS: the runtime-spawned child agents created by sessions_spawn, each running isolated with its own session key in the format agent:<id>:subagent:<uuid>. This is the same session pattern visible in Figures 1 and 2 later in this article.

Figure 0 — NVIDIA NemoClaw Reference Architecture (GTC 2026). Highlighted: SUB-AGENTS.

TL;DR
Understanding the architecture before touching the config file will save significant debugging time.

Agents and the surrounding system

What fails in production is not the LLM — it is the system around it:

Routing: which agent handles which request?
Isolation: does one agent’s failure take down another?
Memory: how does context persist across sessions?
Control: who governs lifecycles, timeouts, and retries?

OpenClaw’s multi-agent architecture is designed around these four problems. The LLM is the execution engine; the architecture is the safety net.

AI agent evolution timeline 2022–2026

Figure 0a — AI agent evolution timeline 2022–2026. Source: ChuyenVD, 'The RenAIssance', GreenNode, March 2026.

Isolation of Agents and Further Considerations

Agents are isolated by default and only share what is explicitly configured. Each agent has a clear boundary:

Workspace: SOUL.md, AGENTS.md, USER.md, TOOLS.md, MEMORY.md
State directory: auth profiles, model registry, per-agent config
Session store: chat history and routing state
Optionally its own LLM model and provider

When OpenClaw spawns a subagent, it creates a separated and isolated session with an auto-generated key following this format:

FORMAT
agent:<agentId>:subagent:<uuid>
// Example:
agent:noc_operator:subagent:d085af01-cf9f-482c-9825-9225a56394b9

The UUID is generated at spawn time and cannot be predicted or addressed by name. This is a key limitation discussed in Part 2.

Real-World Evidence: Session Isolation

The following screenshots show the OpenClaw Sessions UI from an actual pipeline --- a network security assessment across 17 hosts.
Two parallel portscan subagents (noc_operator)

Figure 1 — Two noc_operator subagents (portscan-1, portscan-2) running in parallel. Session keys use auto-generated UUIDs. Tokens: 13,036/200,000 and 9,287/200,000.

More subagents fleet - 40 sessions across multiple agent roles.

Figure 2 — More subagent session list (25 of 40 rows shown). Agent roles visible: system_architect, noc_operator, rnd_lead. Each subagent is an isolated session with its own token budget.

Key observations from the session data:

Each subagent has kind: "direct" - meaning it operates as a direct session, not a channel-bound agent (session in group chat).
Token budgets are per-session: 200,000 is the default context limit per subagent. For a production NetOps pipeline that might run daily, this would become a real operational problem within a week. We shall have a discusstion how to cleanup config in Part 2.
All settings (thinking, fast, verbose, reasoning) inherit from the parent agent by default.
40 subagent sessions visible - demonstrating that session accumulation is real and requires monitoring.

Despite isolation, all agents share one thing by deafult: the gateway process and port. There is a single OpenClaw gateway running, and it acts as the central router for all incoming messages across all channels.

So what if full isolation is required ? for complete process-level isolation, different ports, different profiles, run two independent gateway instances:

BASH
# instance_admin
openclaw --profile instance_admin setup
openclaw --profile instance_admin gateway --port 18789
openclaw --profile instance_admin gateway install
# instance_operator
openclaw --profile instance_operator setup
openclaw --profile instance_operator gateway --port 18790
openclaw --profile instance_operator gateway install

This approach offers enhanced security isolation; however, it introduces additional complexities, as it necessitates the management of two distinct processes and configurations.

In my view, it makes more sense to utilise Docker to encapsulate each isolated instance or agent within its own container.

Gateway as router, not orchestrator

This distinction matters. Gateway only decides which agent receives which incoming message, based on deterministic binding rules.

User message → Gateway → Routes to appropriate agent(s) → Agent processes → Response

The gateway does NOT decide:
▸    What agents should do next ?
▸    How agents should collaborate ?
▸    When to spawn or kill subagents ?

That logic lives in your orchestrator agent's SOUL.md, config, prompting, sessions_spawn, or sessions_send. If you need workflow orchestration, you build it - OpenClaw gives you the primitives, not the policy.

Division of labor beats generalism

A specialist agent with a focused SOUL.md and a matched model outperforms a single generalist agent trying to handle everything.
Strong division of labor means:

Each agent has a clear mandate --- what it owns and what it delegates
SOUL.md is written for a specific role, not a generic assistant
Each agent knows what it should NOT do (scope exclusion)

TL;DR
Knowing what each agent should NOT do is as important as what it should do.

Example: A Security Analyst agent with SOUL.md focused on CVE research, IOC hunting, and compliance mapping will produce sharper output than a generalist that also handles network design, capacity planning, and scheduling.

Shared memory as simple coordination

Before reaching for sessions_spawn or sessions_send, ask: can MEMORY.md solve this?

MEMORY.md is often enough for coordination:

Passing context after a subagent completes
Storing delegation logs, findings, task statuses
Human audit trails - any team member can read the history
No agent-to-agent messaging overhead

This introduces a deliberate exception to agent isolation - acceptable only when the shared data is explicitly scoped and the coordination benefit outweighs the exposure risk. For threat mapping and mitigation guidance, see Section 5.3.

Configuration: Defining Agents and Routing

Key configuration objects

Object	Purpose	Scope
agents.list	Defines each agent: ID, workspace path, model	Per-agent
agents.defaults	Baseline settings inherited by all agents unless overridden	All agents
bindings	Routes incoming messages to a specific agent based on channel, account, or peer	Gateway-level
sessions_spawn	LLM-triggered subagent creation within a parent session	Runtime (covered in Part 2)

Defining multiple agents

Edit ~/.openclaw/openclaw.json to define your agents. The following example is taken from an actual NetOps deployment involving five specialized agents:

JSON
{
 "agents": {
   "defaults": {
     "model": {
       "primary": "anthropic/claude-opus-4-6",
       "fallbacks": [
         "openrouter/nvidia/nemotron-3-super-120b-a12b:free",
         "openrouter/auto"
       ]
     },
     "workspace": "/root/.openclaw/workspace",
     "sandbox": { "mode": "all" }
   },
   "list": [
     {
       "id": "main",
       "subagents": { "allowAgents": ["contentcreation","rnd_lead","system_architect","noc_operator"] },
       "sandbox": { "mode": "off" },
       "tools": { "profile": "full", "alsoAllow": ["sessions_send","sessions_spawn","sessions_yield","subagents","gateway","agents_list"] }
     },
     {
       "id": "system_architect",
       "workspace": "/root/.openclaw/agents/system_architect",
       "model": { "primary": "anthropic/claude-opus-4-6", "fallbacks": ["openrouter/nvidia/nemotron-3-super-120b-a12b:free","openrouter/auto"] },
       "subagents": { "allowAgents": ["main","noc_operator"] },
       "sandbox": { "mode": "off" },
       "tools": { "profile": "full", "alsoAllow": ["sessions_send","sessions_spawn","sessions_yield"] }
     },
     {
       "id": "noc_operator",
       "workspace": "/root/.openclaw/agents/noc_operator",
       "model": { "primary": "anthropic/claude-opus-4-6", "fallbacks": ["openrouter/nvidia/nemotron-3-super-120b-a12b:free","openrouter/auto"] },
       "subagents": { "allowAgents": ["main","system_architect"] },
       "sandbox": { "mode": "off" },
       "tools": { "profile": "full", "alsoAllow": ["sessions_send","sessions_spawn","sessions_yield"] }
     }
   ]
 }
}

NOTE
agents.defaults sets the baseline model and workspace for all agents. Individual list entries override only the fields they specify. openrouter/auto is the final fallback - OpenRouter selects the best available model automatically when all primary and named fallbacks are exhausted or rate-limited. For fast verification and demonstrations, sandbox.mode is currently set to "off" for each agent, which provides full tool access; however, be aware of the risks involved when disabling sandbox mode in your own environment. This could also inspire another article that explores Openclaw's security aspects in greater detail, as there are many important security considerations to address.

Channel Bindings - Routing Rules

Bindings tell the gateway which agent handles which incoming message. The most specific binding always wins. In this deployment, all five agents use Telegram as their channel --- routing is done by accountId (each agent has its own bot token and Telegram account).

JSON
{
 "bindings": [
   { "type": "route", "agentId": "main",             "match": { "channel": "telegram", "accountId": "default" } },
   { "type": "route", "agentId": "contentcreation",  "match": { "channel": "telegram", "accountId": "contentcreation" } },
   { "type": "route", "agentId": "rnd_lead",         "match": { "channel": "telegram", "accountId": "rnd_lead" } },
   { "type": "route", "agentId": "system_architect", "match": { "channel": "telegram", "accountId": "system_architect" } },
   { "type": "route", "agentId": "noc_operator",     "match": { "channel": "telegram", "accountId": "noc_operator" } }
 ]
}

Binding specificity hierarchy (highest to lowest):

Peer-level match (specific contact or user)
Channel + accountId match
Channel-wide match
Default agent (unmatched messages)

Multi-Account Channels

If you have multiple accounts on a single channel, use accountId to route each account to its own agent. In this deployment, five Telegram bots run under one gateway - each mapped to a distinct agent:

JSON
{
 "channels": {
   "telegram": {
     "enabled": true,
     "dmPolicy": "allowlist",
     "allowFrom": ["<auth-tele-account-id>"],
     "streaming": { "mode": "partial" },
     "accounts": {
       "default":          { "botToken": "<main-bot-token>",             "dmPolicy": "allowlist", "allowFrom": ["<auth-tele-account-id>"] },
       "system_architect": { "name": "System_Architect", "botToken": "<system-architect-bot-token>", "dmPolicy": "allowlist", "allowFrom": ["<auth-tele-account-id>"] },
       "noc_operator":     { "name": "NOC_Operator",     "botToken": "<noc-operator-bot-token>",     "dmPolicy": "allowlist", "allowFrom": ["<auth-tele-account-id>"] }
     }
   }
 }
}

NOTE
dmPolicy: "allowlist" + allowFrom restricts access to a specific Telegram user ID. This is the recommended security posture for NetOps deployments - agents should not respond to arbitrary users.

Output from Multi-Phase NetOps Pipeline

TL;DR
The main limitation isn't how available AI is, but rather how well we can guide, and enhance agents. In OpenClaw terms: defining the right agent roles, SOUL.md personas, and routing rules is more important than which LLM you use.

Real-World Pattern: Multi-Phase NetOps Pipeline

The most concrete illustration of what multi-agent OpenClaw looks like in production comes from a real network security assessment pipeline. The orchestrator agent (Sonclaw) coordinated three phases entirely via Telegram:
Orchestrator summary via Telegram

Figure 3 — Orchestrator summary via Telegram. Three phases: port scanning (2 parallel subagents), security & infrastructure analysis (3 parallel subagents), report generation.

Pipeline breakdown:

Phase 1 - noc_operator spawned 2 parallel portscan subagents covering 17 hosts, ports 1--65535. Runtime: ~30-45 min each.
Phase 2 -noc_operator spawned security-deep; system_architect spawned infra-deep and architect-review in parallel.
Phase 3 -Main orchestrator agent wrote the full report in-house and generated a PDF using gen_pdf.py.
Architect-review ran 25m 51s then was killed - a real limitation of sessions_spawn covered in Part 2.

Figure 4 — Security Assessment Report output: 7 critical findings, risk matrix, attack surface analysis, remediation roadmap.

TL;DR
The challenge in this pipeline was not model quality - the models performed well. The challenge was orchestration: non-deterministic spawn timing, UUID-based session addressing with no way to reference a subagent by name, and one agent consuming 25 minutes of runtime before being killed. These are the real constraints of sessions_spawn covered in Part 2.

Specialist Agents by Role (NetOps Example)

For NetOps environments, routing by functional domain is the more relevant pattern - matching the pipeline shown in Figures 1-4. The table below reflects the actual agent configuration from the production pipeline:

Agent ID	Telegram Account	SOUL.md Focus	Model (Primary)
main	default	Orchestrator — delegates to all other agents, handles report generation in-house.	claude-opus-4-6
system_architect	system_architect	Infrastructure topology, host roles, architecture review.	claude-opus-4-6
noc_operator	noc_operator	Port scanning, security analysis, nmap orchestration.	claude-opus-4-6
rnd_lead	rnd_lead	Risk analysis, ops strategy, research.	claude-opus-4-6
contentcreation	contentcreation	Content creation, image generation, x_search.	nemotron-3-super-120b (primary)

NOTE
Contentcreation is the only agent using Nemotron as its primary model - the other four agents all use claude-opus-4-6 as primary with Nemotron as the first fallback.

Model Routing is not only by Cost but Complexity

Different agents can use different LLMs, allowing cost optimization in a mixed models setup. In this deployment, all NetOps agents use claude-opus-4-6 as primary - the reasoning depth is required for infrastructure analysis and security assessment. The contentcreation agent uses a free Nemotron model as primary to reduce cost for high-volume content tasks.

Model routing overview

Figure 5 — Model routing overview.

The following examples are taken from real Telegram conversations. While the primary and fallback roles remain unchanged, various models demonstrate distinct behaviors.

Agent AIOps-Team: claude-opus-4-6 primary	Agent A2A Team: Nemotron-120B primary
When the main is using claude-opus-4-6, he doesn't suggest to change the primary model.	When the orchestrator is utilizing Nemotron-120B with a more advanced model as a fallback, it suggests switching to the superior model automatically without prior consultation --- introducing non-deterministic pipeline execution, uncontrolled cost escalation, and broken audit trails in production. The origin of this behavior is unconfirmed.

When working in production, what actual limitations should you keep in mind? To find out, I ran a quick experiment by instructing the main process to launch a content creation agent and checked whether any errors appeared in the output.

image (6).png

Figure 8 — Experiment output: main process launching content creation agent.

Inter-model compatibility: Nemotron → Opus handoff

Figure 9 - Inter-model compatibility: Nemotron → Opus handoff.

Agent-spawn

Figure 10 — Inter-model compatibility: continued output.

TL:DR
Nemotron → Opus works perfectly. contentcreation (nemotron) successfully spawned a subagent using claude-opus-4-6 with no errors. The inter-model handoff is clean.

The actual output demonstrates that inter-model compatibility is achievable. Nonetheless, these constraints are practical in nature and should be addressed with precision.

Contextsize: operate with different effective context limits, causing inconsistent behavior on the same task
Instruction: different compliance levels across models; what claude-opus-4-6 follows precisely, a weaker model may approximate or ignore
Tool-calling compatibility: not all models handle tool schemas equally; errors in tool-call formatting increase silently in fallback scenarios
No semantic consistency guarantee: two agents on different models processing the same input will not produce semantically equivalent output

The bottom line: mixed model deployments trade cost efficiency for behavioral consistency. In a NetOps pipeline where decisions affect live infrastructure, inconsistency is not just an inconvenience - it is an operational risk. Pick your model boundaries deliberately, not by default.

Agent and Skills Integration

Skills enhance each agent by providing specialised tools tailored to different domains, enabling them to carry out tasks assigned by the main agent. These skills are task modules managed by MCP, such as mcp-nmap, netbox, grafana, NVD API, and others. Skills may be shared among agents or reserved exclusively for certain agents.

Within the scope of this article, none of the listed skills serve as orchestrators - there isn't a skill that:

Spawns/manages multiple agent sessions simultaneously
Routes work across agents based on topic/demand
Coordinates parallel agent workflows

Main agent acts as orchestrator by design (tool permissions, subagent allowlist), not by a dedicated skill.

TREE
main
├── can spawn → contentcreation
├── can spawn → rnd_lead
├── can spawn → system_architect
└── can spawn → noc_operator

Agent	Can call who as sub-agents
main	contentcreation, rnd_lead, system_architect, noc_operator
contentcreaction
rnd_lead	main, system_architect, noc_operator
system_architecture	main, noc_operator
noc_operator	main, system_architect

Shared Memory as Common Ground ?

As mentioned above, agents are isolated. For agents that need to collaborate on shared context - project goals, scan results, decisions, current network state - OpenClaw provides two mechanisms.

MEMORY.md as Shared Knowledge Base

Each agent has its own MEMORY.md inside its workspace. For agents to share context, designate a shared file path that both agents reference.
▸    The orchestrator/coordinator agent writes summaries and decisions to a shared MEMORY.md.
▸    Specialist agents read from the same file at the start of each session.
▸    Keep entries concise - verbose memory entries are re-injected into every subsequent context window, increasing token costs significantly at scale.

extraCollections - Reading Another Agent's Session Transcripts

For more granular cross-agent memory access, memorySearch supports reading another agent's QMD session transcripts:

JSON
{
 "agents": {
   "list": [
     {
       "id": "coordinator",
       "memorySearch": {
         "qmd": {
           "extraCollections": ["agent:noc_operator:sessions"]
         }
       }
     }
   ]
 }
}

NOTE

Use agents.defaults.memorySearch.qmd.extraCollections only when every agent should inherit the same shared collections.

Security Considerations for Shared Memory

Security for AI agents applies directly to OpenClaw multi-agent deployments. Ferrag et al. (2025) define 4 threat categories for LLM-agent ecosystems - each maps to specific risks in OpenClaw shared memory and multi-agent coordination.

Threat Category	Key Attacks (from paper)	In OpenClaw Context
1. Input Manipulation (Tool / Agent layer)	Direct/indirect prompt injection, P2SQL injection, adaptive injection (>50% bypass rate), Toxic Agent Flow via MCP.	nmap output or CVE data written to MEMORY.md without sanitization — coordinator reads poisoned context and executes embedded instructions.
2. Model Compromise (Host / Model layer)	Backdoor triggers (BadAgent, DemonAgent ~100% ASR), memory poisoning via MINJA — inject via benign queries, progressive shortening erases evidence.	MINJA: adversary interacts with noc_operator via Telegram → injects bridging steps into session memory → coordinator reads poisoned context from extraCollections.
3. System & Privacy (Host / Agent layer)	Corba (Contagious Recursive Blocking) — propagates across topologies, depletes resources; datastore leakage; membership inference on shared RAG.	Corba: poisoned MEMORY.md triggers cascading spawn loops → exhausts token budget across all 5 agents. All agents share same OS user — one compromise exposes all workspaces.
4. Protocol Vulnerabilities (Protocol / Agent layer)	MCP SQL injection, rogue agent registration via A2A Agent Card spoofing, credential theft, replay attacks, supply chain poisoning.	Malicious MCP skill package or compromised pyATS testbed file (PYATS_TESTBED_PATH) affects all agents sharing the same skill — persistent across restarts.

Potential Mitigation Strategies

Mitigation	Addresses category	How
Sanitize before writing to MEMORY.md	Input Manipulation	Write plain-language summaries, not raw tool output — removes embedded injection payloads.
Explicit extraCollections scope — no wildcards	Model Compromise	Coordinator reads only named sessions — limits MINJA propagation across the fleet.
subagents.allowAgents whitelist + maxConcurrent	System & Privacy	Limits Corba-style recursive spawn loops — noc_operator cannot spawn contentcreation or rnd_lead.
Separate OPENCLAW_HOME per agent class	System & Privacy	Compromised shell-access agent cannot read MEMORY.md of general-purpose agents.
sandbox: "all" for agents processing external data	Protocol Vulnerabilities	Constrains tool execution for agents ingesting untrusted inputs: nmap output, CVE feeds, API responses.
Restrict exec/write tools per agent	All categories	Not every agent needs exec or write — removing these limits blast radius if model inference is compromised.

NOTE
Source: Ferrag et al. (2025), "From Prompt Injections to Protocol Exploits: Threats in LLM-Powered AI Agents Workflows", arXiv:2506.23260v2. The 4 threat categories are from the paper; the OpenClaw mappings above are applied inference.

Conclusion

Part 1 covered everything needed to configure, run, and understand a multi-agent OpenClaw setup - grounded in real evidence from a NetOps security assessment pipeline running parallel subagents across three phases.

Multi-Agent Workflows: A Practical Guide From Setup to Running and Real Use Case (Part 1)