OpenClaw Multi-Agent Workflows Part 2: Native A2A, Limitations, and What's Next

Part 1 covered agent configuration, routing, and a real three-phase security pipeline. Part 2 goes deeper: how agents communicate at runtime via session tools, shared files, the structural limitations encountered in production, security concerns for enterprise readiness, and the orchestration paths available to go beyond native A2A. 

Session Tools: How Agents Communicate at Runtime

What & Why Session Tools?

OpenClaw's session tools provide the necessary infrastructure for multi-agent delegation and context management. While basic agent setups rely on manual routing via external channels (Telegram, Slack, Discord), session tools allow agents to programmatically initiate work between themselves at runtime.

Session tools become necessary when work requires one agent to actively delegate to another - not just share a file, but hand off a task, wait for a result, or control a running child. A single agent also hits hard limits quickly: context windows fill up juggling scanning, analysis, and reporting simultaneously; mixed concerns degrade output quality; and a network automation agent should not also be writing security compliance reports. Multi-agent delegation is not a design preference - it becomes a necessity once task complexity crosses a threshold.

The Seven Session Tools

OpenClaw provides seven tools for cross-session work. They are documented at docs.openclaw.ai/concepts/session-tool and summarized below. Sections 1.3--1.7 cover each in depth.

Not every agent gets every tool. maxSpawnDepth is the gate that controls session tool distribution across the spawn tree.

The key rules:

Depth 0 (Main agent) always has the full session tool set - sessions_spawn, sessions_send, sessions_yield, sessions_list, sessions_history, and subagents.

Depth 1 sub-agents are where maxSpawnDepth matters most:

• With maxSpawnDepth: 1 (default), they're leaf workers with zero session tools - completely isolated.
• With maxSpawnDepth: 2, they become orchestrators and gain 4 tools: sessions_spawn, subagents, sessions_list, sessions_history. Notably sessions_send is still denied - orchestrators can spawn children but can't message arbitrary sessions.

Depth 2 sub-sub-agents never get session tools regardless of config. They're always terminal leaf workers.

One important nuance: the role (orchestrator vs leaf) is written into session metadata at spawn time, so even if a session key is flat-restored after a restart, it can't accidentally regain orchestrator privileges it wasn't originally granted.

The max allowed value is maxSpawnDepth: 5, but the docs recommend 2 for most use cases.

sessions_send - Cross-Session Messaging

sessions_send delivers a message to a session and optionally waits for the response. It is the primary tool for the coordinator pattern: one agent explicitly calls another by name, waits for the result, and decides what to do next.

How It Works

Two delivery modes are available:

Wait for reply: set a timeout (timeoutSeconds > 0) and receive the response inline in the same turn. The coordinator blocks until the target responds or the timeout expires.

Fire-and-forget: set timeoutSeconds: 0 to enqueue the message and return immediately. The coordinator continues without waiting. Completion is not tracked in the current turn.

After the target responds in wait mode, OpenClaw can run a reply-back loop where the agents alternate messages up to 5 turns. The target agent can reply REPLY_SKIP to stop the loop early. This enables lightweight back-and-forth between a coordinator and a specialist without spawning a subagent.

In the example below, the first agent uses sessions_spawn for querying the current date and time, but the agent does not specify any timezone yet. After that, sessions_send uses the existing childSessionKey indicating that the timezone is GMT+7.

For sessions_send to work, the agent must get the childSessionKey from existing sessions.

The childSessionKey is now being used as sessionKey for sessions_send input, which tells the target what to do next.

When to Use sessions_send

Use sessions_send when:

• the target agent is known in advance;
• the result must be in the coordinator's context before the next step begins;
• the pipeline has a fixed phase order like "Scan → Analyze → Report".

sessions_spawn - Spawning Sub-Agents

sessions_spawn creates an isolated sub-agent session for background work. It is always non-blocking: it returns immediately with a runId and a childSessionKey, and the parent continues its own turn while the child runs independently.

How It Works

When sessions_spawn is called, OpenClaw creates a child session under the parent's namespace with an auto-generated session key in the format agent:<agentId>:subagent:<uuid>. The label huawei-report-generator is a human-readable tag visible in the Sessions UI. When the child finishes, it pushes a completion announce back to the requester's channel - push-based delivery, not polling.

The figures below demonstrate in detail the step-by-step flow from: Task Initialization & Planning → Sub-Agent Orchestration & Communication (2 Phases) → Final Delivery.

sessions_yield - Collecting Sub-Agent Results

sessions_yield intentionally ends the current turn so the next message can be the follow-up event you are waiting for. Use it after spawning sub-agents when you want completion results to arrive as the next message instead of building poll loops.

subagents - Control Plane for Spawned Children

The subagents tool is the control-plane helper for already-spawned sub-agents. It is separate from sessions_spawn - subagents manages children that already exist; sessions_spawn creates new ones. Three actions are available:

list: inspect active and recent sub-agent runs for the current session.

steer: send follow-up guidance to a running child. Requires the childSessionKey or runId - not the label. This resolves the "no mid-run communication" limitation: the parent can send new instructions to a running child, but must have stored the childSessionKey at spawn time.

kill: stop one specific child by sessionKey, or all active children. In the architect-review failure (Part 1, 25m 51s), the orchestrator could have issued subagents({ action: "kill", sessionKey: "agent:system_architect:subagent:4c01a178-..." }) if it had stored the childSessionKey at spawn time. It did not, so external intervention was required.

sessions_list, sessions_history, and session_status

Three supporting tools complete the session tool set.

sessions_list: returns sessions with key, agentId, kind, channel, model, token counts, and timestamps. Filter by kind (main, group, cron, hook, node), label, agentId, search text, or recency (activeMinutes). Useful for mailbox-style triage or finding a specific subagent session by label (huawei-status-collector) when you do not have the childSessionKey. Visibility is scoped by the configured visibility policy.

sessions_history: fetches the conversation transcript for a specific session. By default, tool results are excluded - pass includeTools: true to see them. The view is safety-filtered: thinking tags, scaffolding blocks, leaked control tokens, and credential-like text are stripped or redacted. Very large histories may drop older rows. If you need the raw byte-for-byte transcript, read the file on disk directly.

session_status: the lightweight status tool for the current or another visible session. It reports token usage, elapsed time, model and runtime state, and linked background-task context when a sub-agent is attached. Passing model=default clears a per-session model override and reverts to the agent's configured primary. Use session_status instead of sessions_list when you only need status on one known session.

Shared Workspace - Coordination Without Session Tools

Before reaching for any session tool, consider whether the shared workspace covers the use case. The orchestrator writes a structured task file to a shared directory, specialist agents read it, execute their portion, and write output artifacts back to the same location. The orchestrator collects by reading the artifact files directly - no session routing required. This is not a workaround or a fallback -it is an established operational pattern. The shared directory at /root/.openclaw/workspace/shared/ contains several task files. The pattern predates all session-tool-based coordination in this deployment.

The LLDP topology pipeline demonstrates this pattern end-to-end. The orchestrator created a task record at /root/.openclaw/workspace/shared/tasks/lldp-topology-1777856190.md with explicit subtask assignments.

After execution, the shared artifacts directory showed:

In this example, the shared workspace enabled subagents to generate file-based outputs, which the orchestrator processed once all workers had finished. The shared workspace survives Gateway restarts - files persist even if the session that wrote them is killed - and produces human-readable audit artifacts by default.

In this session, we demonstrated the uses of sessions_spawn to delegate work to specialist sub-agents, sessions_yield to collect results without polling and sessions_send to deliver follow-up instructions to an existing session via its childSessionKey. In addition, the shared workspace pattern offers a file-based alternative.

These tools provide the building blocks, but the deployment evidence also exposed where they fall short - which Section 02 examines.

Limitations

The production pipeline in Part 1 worked - it produced real reports from real network tasks. But it also surfaced every significant limitation of OpenClaw's native A2A mechanisms. These are not edge cases. They are structural constraints that any serious deployment will encounter. Each limitation below is grounded in what the pipeline did.

Non-Deterministic Flow Control

When sessions_spawn (§1.4) is in use, the LLM decides the execution order, task division, and number of children at runtime. There is no way to guarantee the split, the sequence, or even whether a child will be spawned at all on a given run. Two identical prompts to the same orchestrator can produce different spawn patterns depending on model temperature, context window state, and minor phrasing variation. This is because Large Language Models (LLMs) are sophisticated probability and statistics engines. They are designed to model the statistical relationships within massive datasets, rather than understanding language, logic, or facts in a human-like way.

In the Part 1 pipeline, this non-determinism was visible across all phases.

• In Phase 1, noc_operator correctly decided to spawn two parallel portscan subagents (Part 1, Figure 1) - the right call for covering two host ranges simultaneously. That decision was made by the LLM based on SOUL.md intent, not by a workflow rule.
• In Phase 2, system_architect spawned infra-deep and architect-review in parallel (Part 1, Figures 3 and 5), while noc_operator spawned security-deep separately (Part 1, Figure 4). The parallel spawn worked for infra-deep (2m 14s, status Done) but failed for architect-review (killed at 25m 51s).

In Part 2, a second distinct failure mode appeared in the LLDP topology pipeline, both subagents - rnd_lead (Juniper collection) and system_architect (Huawei collection) - failed four consecutive times each with "assistant turn failed before producing content."

The root cause was model-level: both subagents inherited Nemotron-120B from the parent, which in this deployment produces output only in reasoning_content rather than content, causing empty responses. This is separate from the timeout failure mode - it is a silent model-level failure that produces no announce and no result, indistinguishable from a successful spawn until collection time.

The consequence for production: a pipeline that worked on Tuesday may produce a different spawn tree on Wednesday. Steps that must run in a fixed order - scan before analyzing, analyze before report, validate before deploying - cannot be guaranteed by sessions_spawn alone.

This is not a bug. It is the intended behavior of an LLM-driven spawning model. The limitation is in treating it as a workflow engine when it is not one.

Spawn Depth Cap and Hierarchy Constraints

As described in §1.2, maxSpawnDepth controls which session tools each depth level receives. The maximum configurable value is 5, but the docs recommend 2 for most use cases. At depth 2, subagents are always denied sessions_spawn - they cannot create their own children regardless of configuration. The practical ceiling for most deployments is a three-tier hierarchy: main orchestrator (depth 0) → coordinator agent (depth 1) → specialist subagent (depth 2). No further delegation is possible from depth 2.

In the Part 1 pipeline, the effective hierarchy was: main (orchestrator) → noc_operator / system_architect (coordinators, depth 1) → portscan-1, portscan-2, infra-deep, security-deep, architect-review (specialists, depth 2). This matches the recommended depth exactly. The pipeline worked within the constraint - but only because the task decomposition was shallow enough to fit. A more complex NetOps pipeline - for example, one where a security-deep subagent needed to spawn targeted re-scan subagents against specific CVE-affected hosts - would hit the depth ceiling. At depth 2, security-deep cannot spawn children. The coordinator (noc_operator) would need to handle that re-spawn itself, collapsing the hierarchy and increasing the coordinator's context load.

Timeout Governance: Opt-In with a Dangerous Default

sessions_spawn accepts a runTimeoutSeconds parameter. The critical problem is its default: 0, meaning no timeout. Unless runTimeoutSeconds is explicitly set - either in the sessions_spawn call or via agents.defaults.subagents.runTimeoutSeconds - a child session runs indefinitely.

The architect-review subagent in Part 1 ran for 25 minutes and 51 seconds before being killed - not by the orchestrator, not by a timeout rule, but by an external mechanism. During those 25 minutes, system_architect had no visibility into architect-review's progress. It received no heartbeat, no partial result, and no failure signal - only silence.

The LLDP pipeline adds a second cost-of-no-timeout data point: both subagents went across four retry attempts each before failing. No runTimeoutSeconds was set. Each retry against a broken model endpoint burned tokens with no ceiling.

At scale, this becomes a cost and reliability problem.

Gateway Restart: The Hidden Pipeline Killer

Part 1 emphasises that the gateway acts as a router, not an orchestrator, and this point is now reinforced.

If those limitations covered in Sections 2.1-2.3 are all about what happens inside a running pipeline. Gateway restart is different - it is an external event that terminates everything simultaneously, regardless of how well the pipeline was designed. A correctly governed pipeline with proper runTimeoutSeconds, explicit childSessionKey storage, and checkpoint writes to shared artifacts can still lose all in-flight work in a single restart event. This makes gateway restart the highest-severity operational risk for any multi-agent deployment running sustained workloads.

When all active sub-agent sessions are immediately killed, there is no drain mode, no checkpoint, no resume. Work in progress at restart time is gone. The session files remain on disk but the session context - what the agent was doing, which tool call was in flight, what the LLM had just produced - is not recoverable from them.

In the LLDP pipeline example, a gateway restart during Phase 2 would have killed both the Juniper and Huawei collection subagents mid-execution, lost all accumulated LLDP data, and required the orchestrator to restart the entire pipeline from Phase 1. The shared workspace artifacts would be incomplete or absent.

The Sessions UI captures the aftermath of a gateway restart across a three-agent deployment. Six sessions are visible for orchestrator, security_analyst, and system_architect -three on the slash channel and three on the direct channel. The slash-channel sessions show n/a for token usage, indicating they were killed before any work was recorded; the direct-channel sessions show real token counts (28,299, 21,939, and 21,475 respectively), confirming they either completed before the restart or were created after it. The orchestrator's slash session updated 31 hours ago while the others updated 29 hours ago, suggesting it may have been re-triggered independently after the restart. None of the killed sessions produced a deliverable.

TL;DR: Orphaned sessions are proof of wasted spend - the tokens were consumed but no result was delivered, and the entire pipeline must re-run at full cost.

For critical pipelines, it is standard to deploy two gateway instances behind a load balancer with session synchronization, so restarting one instance does not terminate sessions on the other. However, OpenClaw has no session replication, so sticky sessions would just route you back to the same single point of failure.... Mitigation: write checkpoint summaries to the shared workspace at defined pipeline phases. If the gateway restarts mid-pipeline, the next run reads the last checkpoint and resumes from there rather than restarting from zero. Additionally, Openclaw Lobster workflows can encode this as an explicit recovery step.

Security Blast Radius in Multi-Agent Context

Multi-agent setups multiply the attack surface in proportion to the number of agents and the scope of their tool access. In the Part 1 configuration, all five agents - main, system_architect, noc_operator, rnd_lead, contentcreation - run under the same OS user with sandbox: "off". This was an explicit choice for the assessment pipeline. In production it is the wrong default.

The blast radius scales with delegation depth. While maxSpawnDepth controls which session tools are available at each level, it does not restrict access to the filesystem. A compromised noc_operator subagent running at depth 2 -for example, a portscan subagent that processed a malicious nmap response - can read the filesystem of every other agent sharing OPENCLAW_HOME. It cannot re-delegate (depth 2 is denied sessions_spawn per §1.2), but it can read MEMORY.md files written by system_architect, exfiltrate session transcripts from rnd_lead, and access the Telegram bot tokens stored in the shared .env.

The attack chain for a NetOps deployment runs in order: external data input (nmap output, CVE feed, BGP table) → tool execution → session transcript → MEMORY.md write → shared artifact files → shared skill in ClawHub → then become input of other agents. Each step is a potential injection point. The multi-agent architecture does not reduce this chain - it extends it across more agents simultaneously. The LLDP pipeline adds a concrete shared workspace example: huawei_lldp.md (2,958 bytes) and juniper_lldp.md (516 bytes) were written to /root/.openclaw/workspace/shared/artifacts/ and read by the main orchestrator. Any agent with read access to that shared directory - including compromised subagents - can read all artifacts written by other agents. If LLDP data contained injected instructions (an attacker controlling a network device's LLDP system description field), those instructions would persist in the artifact file and be re-injected into the orchestrator's context.

Concrete mitigations - sandboxing, filesystem isolation, tool scoping, and input sanitization - are covered in

Security Note: Actual Concerns against Enterprise Readiness

Security Vulnerability Overview

OpenClaw's rapid growth in early 2026 - exceeding 346,000 GitHub stars within weeks of launch - brought intense security scrutiny. A January 2026 audit identified 512 vulnerabilities, eight classified as critical. Between February and April 2026, researchers tracked approximately 137 security advisories, roughly 2.2 new CVEs per day over a 63-day window.

One of the most critical disclosed vulnerability, CVE-2026-25253 (CVSS 8.8), allowed a one-click remote code execution attack: a victim visiting a malicious webpage while OpenClaw was running could have their authentication token silently stolen via WebSocket hijacking, giving the attacker full shell access to the host machine. This vulnerability affected every version prior to v2026.1.29 and was actively exploited in the wild, with over 135,000 instances found exposed on public IP addresses across 82 countries. Another critical flaw, CVE-2026-32922 (CVSS 9.9), allowed any device with minimal pairing access to escalate to full admin control through a token rotation race condition. This was patched in v2026.3.11. If your deployment is running any version below v2026.3.11, upgrading is not optional.

ClawHub and the Supply Chain Problem

ClawHub - OpenClaw's community skills marketplace - became a significant supply chain attack surface in early 2026. A coordinated campaign dubbed ClawHavoc resulted in 341 confirmed malicious skills being published to the registry (12% of the total at the time of the audit), with updated scans placing the figure as high as ~ 800 skills, representing approximately 20% of the full registry. The attack required no technical exploit: skills were published with professional-looking documentation and fake "prerequisite" installation steps that, when followed, installed Atomic macOS Stealer (AMOS) or opened reverse shells back to attacker-controlled servers.... This matters directly for multi-agent deployments.

Skills installed to a shared directory are available to all agents running under the same gateway. A single compromised skill affects every agent in your fleet simultaneously. The mitigation is practical but requires discipline: read every SKILL.md and every referenced script before installation, maintain a private curated skills repository rather than installing directly from ClawHub, and set sandbox: "all" for any agent that processes external data.

Enterprise Readiness: An Honest Assessment

In its current form, OpenClaw is not enterprise ready. This is not a dismissal of the project - it is an accurate description of where it sits on the maturity curve.

• The architectural gaps documented in Section 2 represent real operational risks for any pipeline where reliability and auditability are requirements, not nice-to-haves.
• The security gaps go deeper: there is no native identity layer for agents, no action authorization model, no memory integrity guarantee, and no skill vetting mechanism at the platform level. These are not bugs that patches fix - they are design choices that require architectural change.

The trajectory, however, is positive. The OpenClaw team has demonstrated a willingness to ship patches rapidly - CVE-2026-25253 was patched within days of disclosure, and the v2026.4.29 release addressed multiple state management regressions documented in this article.

Furthermore, the NVIDIA NemoClaw reference architecture-introduced at GTC 2026 and detailed in Part 1-offers a comprehensive framework for achieving operating system-level sandboxing through OpenShell and out-of-process policy enforcement.

The RFC: Agent Teams proposal addresses the core A2A coordination gaps that limit production multi-agent deployments today. The Lobster workflow engine already exists and works for deterministic orchestration - it simply requires adoption discipline that most users have not yet applied.

The practical conclusion: OpenClaw is a capable and rapidly evolving platform for experimental and internal NetOps automation, particularly for teams that control their environment, audit their skills, and do not expose the gateway to public networks. For regulated environments, multi-tenant infrastructure, or any deployment where a compromise of the agent host would have significant downstream consequences - it requires further hardening before that use case is appropriate. The community is building toward that goal. It is not there yet.

What Comes Next: Orchestration, Cross-Server A2A, and the Road to Production

The native OpenClaw A2A mechanisms - sessions tools - are functional primitives, not a complete orchestration system. They give you the ability to route work between agents and create parallel workers. They do not give you pipeline sequencing guarantees, cross-gateway communication, named session addressing, or timeout governance. The limitations documented are not bugs awaiting patches - they are design boundaries that define the ceiling of what native A2A can do today.

Three paths exist for going beyond that ceiling: Lobster (deterministic workflow orchestration within a single gateway), RFC Agent Teams (the official roadmap for native structured A2A), and openclaw-a2a-gateway (community plugin for cross-server agent communication). Each addresses a different gap. None is a complete replacement for the others.

Taken together, we have an incomplete orchestration stack.

The production-viable path: Lobster for pipeline sequencing, sessions_spawn inside each phase for parallelism, and sessions_send for explicit cross-agent handoffs. openclaw-a2a-gateway becomes relevant when deployment spans multiple hosts - matching the isolation goals described in session 2.

Conclusion

Part 2 provided an overview of the native OpenClaw A2A framework utilizing session tools, including pattern selection, practical pipeline validation, structural constraints, security considerations, and the orchestration avenues available in addition to core primitives. The tools are functional but incomplete. The question for any team deploying this today is not whether these limitations will be fixed - the roadmap is active - but whether the workarounds documented here are sufficient for your pipeline's reliability requirements.