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

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.

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.

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.

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

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:   

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:

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.

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.   
 

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.

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

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

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

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.  
 

Potential Mitigation Strategies

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.