OpenClaw breaks multi-agent work into three modes: standalone agents, subagents and ACP

OpenClaw presented its multi-agent model not as an abstract idea but as a set of working modes for real tasks in Telegram. A user can keep one main agent and then hand out roles to persistent executors, temporary subagents and external development tools via ACP.

Three working modes

OpenClaw's setup rests on three different ways of delegating. The first is standalone persistent agents, each with its own working folder, memory and instructions. The second is subagents, which the main agent launches for a specific one-off task and supplies only with the context it needs. The third is ACP, a mode in which engineering work is done not by OpenClaw itself but by a connected external tool such as Codex, Claude Code or Gemini CLI.

The result is not one universal assistant but a dispatcher that can pick the right level of execution for each type of work.

• Persistent agent: for a role that is needed regularly
• Subagent: for one-off research or a piece of a larger task
• ACP: for development tasks in an external environment
• Main agent: for routing, oversight and assembling the result

"Multi-agent work in

OpenClaw is not a single button but several modes of running agents."

When to use each

Standalone agents are useful in this model where a task repeats and accumulates its own context. The article gives simple examples: a research agent, a rewrite agent, a publishing agent. Each can live in its own working folder, remember earlier actions and receive tasks either directly or through the main agent. This reduces chaos: instead of one long conversation with mixed instructions, you get a system of roles in which every executor has its own area of responsibility and its own accumulated memory.

Subagents solve a different problem: how to quickly pull one-off or parallel work out of the main thread. If you need to briefly study a topic, gather several findings or split a large task into independent pieces, the main agent can spin up child runs and then merge the answers into a single result. This is especially useful for research and preliminary analysis. In this mode there is no need to create a new permanent participant in advance: the subagent appears for the task, gets limited context and disappears when done, without burdening the overall system with extra memory.

For development, OpenClaw offers a separate route through ACP. The main agent remains the entry point and orchestrator, but an external tool writes the code itself. The article describes three scenarios: a one-off ACP session for a single engineering task, a persistent ACP session for a long-running project, and binding the ACP context to a dedicated Telegram topic, where the technical discussion lives apart from the main chat. This mode is for projects that need long context, successive iterations and the advantages of specialized CLI tools.

Telegram as a control panel

The author puts particular emphasis on Telegram as a natural interface for this architecture. A persistent agent can be bound to a separate bot or to the current topic, and the technical ACP context to a dedicated thread in the chat. As a result, roles and work streams do not get mixed: research happens in one place, development in another, and the main agent remains the central entry point for assigning tasks. To the user this looks not like complex infrastructure but like a clear map of conversations with different types of executors.

This leads to OpenClaw's main scenario: the main agent stops being just a conversational partner and becomes the system's coordinator. It can send research to a standalone agent, a one-off subtask to a subagent and the engineering part to ACP via Codex, then return a single assembled answer. In other words, the user manages not each action by hand but the logic of dividing the labor. That is the practical value of multi-agent work: less micromanagement, more controlled specialization and parallel execution.

What this means

OpenClaw is effectively offering not a "magic AI agent" but an operating model for teams and solo developers who want to spread roles, context and tools across different channels. If the approach catches on, Telegram chats with agents will increasingly resemble a lightweight IDE and a dispatch room at once: one entry point, several executors and a cleaner separation between research, content and code.