Multi-Agent Collaboration Survey: How Should Agents Actually Divide Work

This article is dense, technical, and engineering-focused. Recommended reading before a meal.

Multi-agent collaboration is often presented on Douyin and Xiaohongshu as a cool team story: one agent researches, one agent writes code, one agent runs tests, one agent does reviews, and finally the main agent collects results like a project manager.

Then the comments: “Wow, that’s awesome!”

But anyone who has actually used multi-agent systems, or more precisely, used them efficiently, just smiles and shakes their head.

Because multi-agent is never as simple as “spawning multiple model instances.” You also need to consider task scheduling, context isolation, permission control, state management, and result merging mechanisms.

In engineering terms, this means: who has the authority to create a worker? How much context does a worker get? Can it write files? What happens when multiple workers write to the same area? When a worker fails, times out, or is interrupted by the user, how does the parent task recover? When results come back, who judges conflicts, and who takes responsibility for the final merge? A whole host of problems.

So how can we better build our own multi-agent teams?

Let’s first look at how Codex, Claude Code, OpenClaw, and Hermes Agent approach this.

Triggers and Topologies

A lot of discussion gets muddled because people treat two problems as one.

The first problem is triggering: When does the system transition from a single agent to multiple agents?

The second problem is topology: Once you have multiple agents, how are they organized? Does a main agent dispatch a few workers and then collect results centrally? Or can workers communicate among themselves? Does the system wait for results within the current turn, or does it put the task into a persistent queue to resume tomorrow?

There are roughly four types of triggers.

The first is explicit triggering. The user directly says “use parallel subagents,” “spawn one agent per review category,” “delegate this work in parallel.” Codex mainly falls into this category. It won’t arbitrarily spawn a bunch of workers just because a task sounds complex; it leaves parallel authorization to the user and the main agent.

The second is semantic triggering. The main agent judges whether to invoke a specific expert agent based on the task content and the subagent description. Claude Code’s regular subagents primarily fall into this category. The more a description reads like a triggering condition, the easier it is for the system to call it at the right time. The more a description reads like a wish, the easier it is for the system to call agents indiscriminately.

The third is routing triggering. The system doesn’t first ask “is this task complex?” but instead looks at where the message came from. OpenClaw selects an agent based on channel, account, thread, peer, guild, role, etc. Slack ops channel goes to the ops agent, private Telegram goes to the deep work agent, family entry goes to a low-privilege assistant.

The fourth is queue triggering. Tasks are written to a board, queue, cron, or background job, and a dispatcher launches workers based on status and assignee. Hermes Kanban falls into this category. The key here is no longer whether a response can be returned immediately in the current turn, but whether the task can span turns, days, restarts, and human intervention.

Topologies can also be categorized.

Single agent is the default form. When requirements are vague, changes are small, or steps are heavily dependent, a single agent is often the most stable. Many tasks don’t need multi-agent; they just need better context and shorter feedback loops.

Star fan-out/fan-in is the most common subagent topology. A main agent dispatches multiple workers, workers don’t negotiate directly, results go back to the main agent, and the main agent performs reduction. Codex subagents, Claude’s regular subagents, and Hermes’ delegate_task are primarily this structure. Its advantage is clear responsibility centralization; its disadvantage is that workers cannot correct each other, and all conflicts are pushed to the main agent’s merge stage.

Chain pipeline suits strongly sequential tasks. For example, first locate a bug, then write a fix, then add tests, then review. Forcing parallelization on such tasks usually just wastes the later workers’ time on incorrect assumptions.

Tree topology is suitable for large task decomposition. A main agent dispatches an orchestrator, which then dispatches several leaf workers. Tree topology looks powerful, but depth and concurrency must be strictly limited, otherwise fan-out can expand exponentially. OpenClaw and Hermes both keep default depth low precisely to control this risk.

Mesh team fits multi-hypothesis problems. For example, a production login failure could stem from frontend state, backend tokens, database sessions, cache, or deployment configuration. Multiple teammates can independently verify hypotheses and challenge each other. The cost of mesh topology is direct: more messages, more context, higher coordination costs, and a higher chance of write file conflicts.

Gateway routing suits persistent multi-entry systems. It’s not “one task split among multiple agents,” but “different entry points go to different agents.” A large part of OpenClaw’s multi-agent value lies here.

Durable board suits long-term collaboration. Tasks, comments, handoffs, blocked states, retry records all go into persistent storage.

The Call Chain

I break a multi-agent system down into the following call chain:

Router / Dispatcher is responsible for deciding whether to split a task and to whom. In Codex, this decision comes mainly from explicit user authorization and the main agent. In Claude Code, it can be influenced by description matching. In OpenClaw, it’s often determined by entry point binding. In Hermes, short tasks might be delegated by the parent agent via delegate_task or automatically selected by the model based on task complexity; long tasks might be launched by the Kanban dispatcher based on assignee.

Context Builder is responsible for deciding what the worker knows. If a subagent doesn’t have enough context, it will go off track. You can’t bring in a worker and just say “fix it,” expecting it to understand the project path, error scene, relevant files, acceptance criteria, prohibitions, and output format. For a subagent, the delegation information is the requirements document.

Worker Profile Selection decides what role to use. Common ones include: read-only explorer, code-capable worker, security reviewer, test reviewer, profile with long-term memory, one-shot child. If the role is chosen incorrectly, permissions and output will also be wrong.

Execution Sandbox decides what the worker can do. Can it run a shell? Can it access the network? Can it write files? Can it spawn further children? Can it access user credentials? These are not just security configurations; they directly change the collaboration pattern. A read-only reviewer and a writable implementer are two completely different agents.

State Store decides where state is kept. One-shot subagents typically only live for the duration of the current task, finally returning a summary. OpenClaw agents have their own session store. Hermes Kanban stores tasks, comments, handoffs, blocked/retry status in a database. Where state is placed determines whether the system can span turns, days, and restarts.

Merge / Reduce is responsible for closing the loop. After multiple workers produce results, who judges conflicts, who makes trade-offs, who writes the final patch, and who is accountable to the user? Many multi-agent demos look impressive because they skip the merge challenge. In real engineering, merge is where multi-agent systems succeed or fail.

Finally, there’s cancellation and failure propagation. When a parent task is interrupted, should child tasks also stop? What happens when a worker times out? What if two workers reach opposite conclusions? If one worker writes a bad patch and another worker’s tests are based on that patch, how does the system roll back? These are not model capability issues; they are runtime design issues.

Codex: Explicit Fan-out

Codex’s subagent strategy is very restrained. By default, it won’t automatically launch a group of agents just because a task sounds complex. You need to give explicit parallel authorization, for example:

If you just say “analyze deeply,” “thoroughly review,” or “carefully investigate this bug,” Codex will usually interpret this as a quality requirement, not multi-agent authorization. This is an important product decision: Codex leaves control of fan-out to the user and the main agent, rather than automatically translating complexity into more workers.

There are several reasons behind this design. Spawning more agents increases tokens, latency, log volume, and merge costs. If workers can write files, it introduces conflict risk. If subagents return lots of explanation, the main agent’s reduce cost goes up. Explicit authorization might seem less “automatic,” but it makes system behavior predictable.

Codex’s default topology is star.

The main agent plays both dispatcher and reducer. It decides who to dispatch and is responsible for merging results into a usable answer or patch for the user. The value of subagents isn’t just “an extra brain,” but also context isolation. Codebase searches, long logs, test output, and call chain exploration can all go into a sub-context, preventing the main context from being polluted with noise.

Codex’s built-in agent types can be understood by responsibility:

• explorer: Good for reading code, finding paths, locating call chains, searching relevant files. It should stay read-only and output file paths, function names, key evidence, risk points, and next-step suggestions. The value of an explorer is reducing the main context’s exploration cost, not directly modifying code.
• worker: Good for modifying code, adding tests, implementing local functionality. Workers must have clear ownership, e.g., only modify src/auth/* or only be responsible for tests/auth/*. If two workers can both modify the same logic, the time saved will likely be spent on conflict resolution.
• default: A general fallback, suitable for tasks where boundaries aren’t fully clear but independent context is needed. Convenient, but be careful: the more general the worker, the clearer the task boundaries need to be.

Codex also supports custom agents. Teams can place TOML files in .codex/agents/ or user-level directories, configuring description, developer instructions, model, reasoning effort, sandbox, MCP, skills. This capability is good for solidifying fixed roles within a team, like security-reviewer, migration-worker, docs-editor. But it also brings a problem: the more agents, the clearer the scheduling rules need to be; otherwise, it’s just moving prompt chaos from the main context to the agent registry.

Codex also has two key guardrails: agents.max_threads controls concurrency width, and agents.max_depth controls recursion depth. The default depth usually only allows the main agent to spawn subagents, not subagents spawning further subagents. This restriction is practical. For a PR review, spawning three workers (security, tests, performance) is usually enough. If each worker spawns three more, cost and behavior quickly become uncontrollable.

Codex is not suitable for automatically splitting all complex tasks. Small fixes aren’t worth fan-out. Strongly sequential tasks are not suitable for parallelization. When multiple workers will write to the same file, you need serial design first, then parallel execution. When requirements are still vague, multi-agent only amplifies the vagueness.

A more robust way to delegate with Codex looks like this:

Claude Code: Description + Team

Claude Code’s regular subagents feel more like a local expert registry. Each subagent has a name, description, system prompt, tool permissions, model, and independent context. The main session can judge when to call it based on the description, or it can be explicitly called by the user.

For example, a security reviewer can be written like this:

{
  "name": "security-reviewer",
  "description": "Review code changes for security vulnerabilities...",
  "system": "You are a security expert..."
}

Here, the description is the routing rule. It answers “when should I be called.”

If written specifically, Claude can more easily invoke it at the right time. If written too broadly, like “review code quality,” it might appear too frequently and become noise.

Regular subagents have relatively short lifetimes. The main session calls them, they execute the task in an independent context, and then return a summary. They don’t naturally become long-term roles, nor do they default to negotiating with other subagents. They are suitable for exploration, review, log analysis, local debugging, codebase understanding—tasks with high context noise.

Claude Code’s built-in Explore, Plan, General-purpose can be understood as three default worker profiles. Explore is read-only, good for codebase search, path location, and quick understanding. Plan is good for research in planning mode, putting exploration materials in a sub-context to avoid main context bloat. General-purpose is broader, capable of multi-step tasks and potentially reading/writing files.

The difference from Codex at this level is the trigger threshold. Codex defaults to waiting for explicit user authorization; Claude Code can automatically delegate based on description. In other words, Codex asks “has the user authorized parallelism?”, while Claude Code asks “is there a description matching the current task?”

Regular Claude subagents are still star topology.

Agent Teams is another logic. According to current Claude Code documentation, it’s still experimental, disabled by default, and requires explicit enabling. When enabled, a lead Claude works with multiple teammates, each with independent context, able to communicate, and sharing a task list. At this point, the system is no longer just star fan-out; it’s closer to a team mesh.

Team mode suits multi-hypothesis problems. For example, production login failure could be from frontend state, backend tokens, database sessions, cache, or deployment config. One agent following one line of inquiry can easily anchor early. Multiple teammates verifying hypotheses separately and challenging each other gives better coverage.

But team mode has higher costs. Teammates generate more context, more messages, more intermediate judgments. They might modify the same file, give conflicting advice, or create management overhead on the shared task list. The lead must have clear closing responsibility. A team without ownership easily becomes “multiple Claude sessions busy, but no one responsible for the final result.”

Claude Code also has Agent View, worktrees, and /batch, which should be understood separately from regular subagents.

• Agent View is more like a human dispatch console. You can launch multiple background sessions, observe their status, and intervene, pause, or take over if needed. Human involvement is higher here; the system doesn’t pretend all coordination is done automatically by the model.
• worktrees are file isolation mechanisms when writing code. If multiple agents write to the same repo in the same workspace, conflicts are almost inevitable. Worktrees at least let each worker modify its own copy, then merge later.
• /batch is better for repo-wide migration or mechanical refactoring. For example, replacing an old API with a new one across the repo can be split into multiple worktree-isolated subagents by directory. Each agent handles one area, then unified tests and review.

So Claude Code can be thought of in three layers:

Claude Code’s common failure points come from description and permission boundaries. Descriptions too broad lead to false triggers; tool permissions too large lead to overstepping; teams without ownership lead to conflicts; batches without acceptance criteria produce a pile of patches that look complete but have inconsistent styles.

When writing a Claude subagent, a good description should read like a trigger condition:

“It can be routed, reducing uncertainty.” Claude Code’s proactiveness comes from descriptions, but its controllability also depends on descriptions.

OpenClaw: Gateway + Background Tasks

OpenClaw’s starting point differs from Codex and Claude Code. Codex and Claude Code mostly operate within a single coding session. OpenClaw first faces multi-channel event streams. It’s more like a self-hosted Gateway, connecting WhatsApp, Telegram, Discord, Slack, and other channels to an agent runtime.

In OpenClaw, what the user sends isn’t necessarily a unified “task.” It could come from the company Slack ops channel, a personal Telegram, or a Discord thread. Different entry points imply different identities, permissions, contexts, and risks. So OpenClaw’s first layer isn’t subagents; it’s routing.

It can select agents based on peer, thread inheritance, Discord guild/role, Slack team, accountId, channel-level fallback, etc. Messages from Slack ops channel might go to the ops agent; from personal Telegram, to the deep work agent; from a family entry, to a low-privilege assistant.

Here, the trigger isn’t the user saying “spawn subagent,” nor the model matching a description; it’s the event entry point binding. OpenClaw first answers “which agent does this message belong to,” and only then considers whether that agent should split the task.

Agents in OpenClaw are more like isolated runtime units. Each agent has its own workspace (e.g., AGENTS.md, SOUL.md, USER.md, notes, persona rules), its own agentDir (with authentication info, model registry, per-agent config), and its own session store (recording conversation history and routing state). Note a boundary: OpenClaw documentation states that sub-agent auth is resolved by agent id, but main profiles are merged in as fallback, so it’s not “each agent’s auth material is completely hard isolated”; a more accurate description is agent-level isolation for config, workspace, session, and tool strategy.

This means a large part of OpenClaw’s multi-agent value comes from isolation. Entry identity isolation, context isolation, permission isolation, tool isolation—these are its main threads. An ops agent can have log and deployment tools; a family assistant shouldn’t have dangerous shell permissions; a deep work agent can record long-term project context; a temporary chat agent shouldn’t share that state.

The second layer is background subagents. An existing agent can launch a background agent run via /subagents spawn or sessions_spawn. It usually returns a run id, and the main conversation isn’t blocked. The subagent runs in its own session and announces results when done.

This is similar to Codex’s fan-out, but with a different lifecycle. Codex’s subagents are more like parallel workers within the current task; the main agent waits for results and then closes the loop. OpenClaw’s background subagents are more like async jobs, suitable for persistent chat scenarios. You ask it to check logs, run research, or wait for a slow tool; the main conversation can continue without being stuck on the same turn.

OpenClaw allows nesting but has strong default limits. maxSpawnDepth defaults to 1. Raising it to 2 allows an orchestrator subagent to dispatch workers in a tree structure, but child count and concurrency are limited, and depth-2 workers cannot spawn further. This is typical fan-out control. The system allows tree topology but doesn’t encourage unbounded task expansion.

The third layer is ACP Agents. OpenClaw can connect external coding harnesses like Codex, Claude Code, Cursor, OpenCode, Gemini CLI. If the user says “run this in Codex,” OpenClaw can route to the Codex runtime. It doesn’t need to cover all execution scenarios with native subagents; instead, it makes itself a unified entry point.

OpenClaw can be understood in three layers:

OpenClaw’s problem areas are also in these three layers.

• If routing is misconfigured, messages go to the wrong agent.
• If permission policies are too wide, a low-risk entry might get dangerous tools.
• If session store design is unclear, personal and work contexts can cross-pollinate.
• Too many background jobs create concurrency and cost pressure.
• If ACP harness scheduling is unclear, users might think they’re in OpenClaw’s native environment but are actually in another toolchain.

So OpenClaw’s engineering focus isn’t “how to make several agents think together,” but “how to keep a network of agents with different entries, identities, and permissions running stably long-term.” It’s more like an agent operating system or message gateway, rather than a parallelizer for single coding tasks.

Hermes: Short-Task RPC, Long-Task Durable Queue

Hermes Agent is very engineering-oriented because it splits short-term parallelism and long-term collaboration into two primitives: delegate_task and Kanban.

delegate_task handles short-term parallelism. The parent agent initiates a call, the child agent executes, and finally returns a summary. This is very RPC-like. Triggering doesn’t necessarily require the user to explicitly say “delegate”: Hermes documentation states the agent automatically chooses to delegate based on task complexity; but the mechanism still generates a child agent via delegate_task.

Child agents have fresh conversations, restricted tools, and independent terminal sessions. They don’t know the parent agent’s full context, only what’s written in goal and context.

The phrase “subagents know nothing” in the Hermes documentation is key. It highlights the most common pitfall in multi-agent delegation: child agents don’t automatically know the background. The parent agent must write in the project path, error info, relevant files, task goal, acceptance criteria, prohibitions, and output format. Writing only “fix the error” is like giving an incomplete requirement to a new colleague.

Hermes also has clear limits on delegate_task. By default, a maximum of 3 concurrent children; exceeding that returns an error, not silent truncation. Batch results are returned in input order. When the parent turn is interrupted, active children are interrupted together. By default, leaf subagents cannot further delegate. To enable nesting, you must set the child as an orchestrator and increase max spawn depth. Three levels of depth with 3 concurrent children each quickly becomes 27 leaf agents.

It also restricts leaf tools: cannot call delegate_task again, cannot clarify to ask the user, cannot write shared persistent memory, cannot send cross-platform messages, cannot use certain dangerous execution tools. Leaf workers are fixed as controlled execution units. The flavor of this design is clear: short tasks can be parallel, but parallelism width, recursion depth, tool permissions, and interrupt propagation must all be controlled.

Kanban handles another type of task. It’s not a subagent, but a durable queue plus state machine. Tasks, handoffs, and comments are written to a SQLite task board. Workers have profiles, names, and memory. A dispatcher launches workers based on assignee. Tasks can be blocked, unblocked, retried, or wait for human input.

The difference between delegate_task and Kanban can be seen from the lifecycle:

For example, you want three researchers to look up three data sources separately and then synthesize a conclusion; delegate_task is suitable. You want to do a two-day research report: first gather data, then analyze, then write a draft, then review, possibly waiting for human direction in between; this should go into Kanban.

Hermes’ failure point is mixing the two task types. Using Kanban for short tasks makes it clunky; using delegate_task for long tasks loses state, makes retrying hard, and makes handoffs difficult. Another failure point is writing too little context. Hermes already states the risk in its docs: the child doesn’t know the parent context. Without enough information, it can only guess.

The engineering value of Hermes lies in clearly articulating the lifecycle. One-shot parallelism and persistent collaboration are not the same thing. The former needs fork/join; the latter needs queues, state, retries, comments, handoffs, and audit trails.

Looking at Specific Scenarios

Scenario 1: PR Review.

If it’s just reviewing a medium PR, Codex or Claude Code regular subagents are sufficient. Spawn a read-only worker for security, one for tests, one for performance, and finally the main agent aggregates. This scenario doesn’t need team mesh, because workers don’t need heavy dialogue. What matters more is clearly writing the review dimensions, output format, and whether file modification is allowed.

With Codex, you can explicitly say:

With Claude Code, you can write security-reviewer, test-reviewer as description-driven regular subagents, allowing them to appear automatically after relevant code changes.

Scenario 2: Production Login Failure.

This problem suits a team or at least parallel exploration, because the fault could be in frontend state, token issuance, session storage, cache, or deployment configuration. Codex can explicitly spawn multiple explorers to check UI, API, DB, cache separately, then the main agent closes the loop. Claude Code Agent Teams are better suited for teammates to challenge each other’s hypotheses; e.g., the backend teammate argues token expiry, the frontend teammate can counter with browser state.

Here, it’s not recommended to have multiple workers write fixes initially. A safer approach is read-only parallel localization first, then one worker writes the patch, then a reviewer checks it. The first phase of multi-agent should broaden the observation field, not the write field.

Scenario 3: Multi-Channel Personal Assistant.

This is not Codex or Claude Code’s home turf. WhatsApp, Telegram, Slack, Discord entries need routing, entry identity isolation, permission isolation, and session store. OpenClaw fits this problem better. Your concern isn’t “how many agents work together,” but “which entry can trigger which agent, what tools does that agent have, where is state stored, and how are credentials and tool permissions constrained.”

A reasonable design might be: Slack ops channel only goes to the ops agent, with log reading and low-risk deployment query tools. Personal Telegram goes to the deep work agent, with personal project context. Family entry goes to low-privilege assistant, without shell or company account access. Here, multi-agent is first a isolation boundary, not a collaboration show.

Scenario 4: Two-Day Research Report.

One-shot subagents aren’t enough. You need task decomposition, state recording, material handoff, human comments, and failure retry. Durable boards like Hermes Kanban are more suitable. You can create a board: data collection, data cleaning, analysis, draft, review. Each task has an assignee, dependencies, acceptance criteria, and comment section.

For specific tasks, like “look up three official documents separately,” use delegate_task for local parallelism. In other words, Kanban manages the lifecycle, delegate_task manages local parallelism. Keeping these two layers separate prevents the system from being both clunky and losing state.

Scenario 5: Repo-Wide Migration.

This task suits worktrees + batch. Split by directory or module, not by “let agents figure it out.” Each worker owns a set of files, and then unified tests and review. Claude Code’s worktrees / batch are closer to this scenario. Codex can also use workers with file scope, but ownership must be clearly written.

A common mistake is splitting by role, e.g., “one agent thinks, one implements, one tests.” For repo-wide migration, a better split is almost always by file boundary: packages/api, packages/web, packages/shared. File boundaries create fewer conflicts than abstract roles.

Anti-patterns: Where Multi-Agent Fails Most

Anti-pattern 1: Using complexity as a trigger. Complex tasks don’t necessarily mean parallelism. If subtasks are strongly dependent, e.g., “first understand business rules, then decide data model, then write migration,” that’s a pipeline, not fan-out.

Anti-pattern 2: No delegation contract. Workers don’t get paths, error scenes, acceptance criteria, or prohibitions; they can only guess. Correct guesses are luck; wrong guesses are the norm.

Anti-pattern 3: Letting multiple workers write the same code. Multi-agent most fears “parallel writes without ownership.” If parallel writes are necessary, first partition by directory, module, test file. If boundaries can’t be drawn, don’t parallelize writes.

Anti-pattern 4: No reducer. After multiple agents return results, someone needs to make trade-offs, merge, deduplicate, sort, accept. Multi-agent without a reducer is just multiple opinions.

Anti-pattern 5: Making short tasks into queues and long tasks into RPCs. Short tasks on durable boards slow feedback. Long tasks with one-shot subagents lose state. Hermes separating delegate_task and Kanban is a good engineering reminder.

Anti-pattern 6: Overly broad permissions. A review agent shouldn’t have file write permission. A family entry agent shouldn’t have a company shell. A leaf worker doesn’t necessarily need to spawn children. Broader permissions make scheduling less predictable.

Anti-pattern 7: No observability and audit. A multi-agent system needs to know who triggered whom, what context was passed, what tools were used, what summary was returned, and where failure occurred. Otherwise, when something goes wrong, you can only guess from chat logs.

Selection Order

When designing multi-agent, ask in this order:

First, can a single agent do it? If yes, don’t split first. Small changes, strong sequential dependencies, vague requirements—single agent is most stable.

Second, will the main context be polluted? Long logs, large searches, cross-directory reading, multiple failure stacks—these muddy the main agent. Offloading them to an explorer or read-only subagent is reasonable.

Third, can the subtasks be independent? Security review, test review, performance review can be parallel. First locate bug, then decide fix: better as a pipeline.

Fourth, must the result be returned in the current turn? If yes, use fork/join. If not, use background jobs. If it needs to span days, retries, wait for humans, use durable queue or Kanban.

Fifth, do workers need to challenge each other? If only separate data gathering, star is enough. If they need to question each other and share task status, consider team mesh.

Sixth, will multiple workers write files in parallel? If yes, write ownership first. Who modifies which directory, who is read-only, who merges last. Without these constraints, don’t parallelize writes.

Seventh, is entry isolation needed? Multi-channel, multi-identity, multi-permission systems should prioritize Gateway routing over throwing all messages to a universal agent.

Eighth, how does failure recovery work? Can it retry? Can it block? Can it preserve handoffs? Can it see evidence from subtasks? These determine whether the system can run long-term.

Delegation Contract Template

If you want to take away just one practical template, use this. It applies to Codex, Claude Code, Hermes, and any system needing worker delegation.

This template looks simple, but it solves the basic problems of multi-agent: context, permissions, boundaries, output, and closure. Without these, no advanced topology will save you from random parallelism.

Conclusion

Multi-agent collaboration is not about more being better, nor about more automation being better.

The more engineering-robust order is: first decide scheduling method, then decide state placement. First decide context and permission boundaries, then decide topology. First decide who reduces, then decide how many workers.

• Codex suits explicit, controllable star parallelism.
• Claude Code suits description-driven expert delegation, and can do more complex collaboration in team and batch scenarios.
• OpenClaw suits multi-entry, persistent, permission-isolated agent networks.
• Hermes suits separating short-term parallelism and long-term queues: delegate_task for temporary fork/join, Kanban for cross-turn workflows.

If a task just needs faster parallel investigation of four lines, use star subagents.

If a problem needs multiple parties to challenge each other, use team mesh.

If messages come from different channels and identities, use Gateway routing.

If tasks must span days, retries, wait for humans, use durable board.

If multiple workers will write the same code, stop first and write ownership clearly.

Design boundaries first, then increase agent count.

This order might not look flashy, but it’s closer to real engineering.