How AI Agents Delegate Tasks to Each Other: OpenClaw Orchestration Explained

The Tweet Making the Rounds

> "This army of @openclaw agents runs an entire company for $400/month. Here's the exact structure to follow."

366 retweets. Not surprising — it sounds like a dream. A team of AI agents handling sales, marketing, code, support, and coordination, no payroll required.

What the tweet doesn't show: how the agents actually talk to each other.

How does a coding agent know the marketing agent needs a new feature description? How does the team lead know when a sub-agent is done? How do you prevent a task from just... disappearing?

This post answers exactly that — from real operation of our 6-agent team.

---

The Three Ways Agents Communicate in OpenClaw

OpenClaw provides three distinct mechanisms for agent-to-agent communication. Each has its place, and the choice between them matters.

1. sessions_send — Direct Messages Between Agents

The simplest form: one agent sends another a message, just like a regular chat message.

```javascript

// Sam sends Peter a task

sessions_send({

sessionKey: "agent-peter",

message: "Can you review the new API endpoints in apps/api/routes.ts?

Focus on security vulnerabilities and missing input validation.

Post the result as a comment in ClickUp task TC-47."

});

```

Peter receives the message like a normal user message — he "wakes up", reads it, and executes the task.

When to use this:

Limitation: You don't get a direct reply. Sam can send Peter a message — but she has to wait or actively check whether Peter is done.

---

2. Sub-Agents (sessions_spawn) — Temporary Specialists

For tasks that are a self-contained unit of work, Sam spawns a temporary sub-agent. The sub-agent exists only for this one task, delivers its result, and then disappears.

```javascript

// Sam spawns a one-off security auditor

const result = await sessions_spawn({

task: `Run a complete security audit of the file

/opt/agents/docker-compose.yml.

Check: exposed ports, hardcoded secrets, missing resource limits.

Return a prioritized list of issues (CRITICAL/HIGH/MEDIUM).`,

runtime: "subagent",

mode: "run"

});

```

The difference from sessions_send: Sam waits for the answer. The sub-agent runs isolated, completes its task, and returns a structured result. Then: gone.

When to use this:

Real example from our setup:

When a cron job runs in the morning and Sam builds the daily report, she spawns a sub-agent for each domain in parallel:

```

Sam spawns simultaneously:

├── Sub-Agent A: "Check unread emails and extract key points"

├── Sub-Agent B: "Load high-priority ClickUp tasks for today"

└── Sub-Agent C: "Check calendar for the next 48 hours"

Sam waits for all three results.

Sam combines results into a morning report.

Sam sends the report via Telegram.

```

Total runtime: the slowest sub-agent's time — not the sum of all three.

---

3. Shared Memory — Coordination Through Files

This is the most underrated mechanism. Agents can communicate through shared files — which looks primitive at first glance, but is extremely robust in practice.

Example: Peter has completed a task

Peter writes to his workspace file `status/tc-47.md`:

```markdown

# TC-47: API Security Review

Status: DONE

Completed: 2026-03-07 03:45 UTC

Issues Found

ClickUp comment posted: Yes

```

Sam reads this file at the next heartbeat check and knows without asking: TC-47 is done, and there are critical issues that need her attention.

Why this works:

---

The Orchestration Pattern That Actually Works

After many iterations, we landed on a pattern that handles most tasks reliably. We call it internally "Claim & Complete":

```

1. Sam identifies a task (from ClickUp, email, or her own context)

2. Sam chooses the right agent based on task type

3. Sam delegates via sessions_send (for long tasks) or spawns sub-agent (for fast ones)

4. Sam writes the delegated status into her own HEARTBEAT.md

5. On the next check, Sam verifies whether the task was completed

6. On timeout or failure: Sam escalates or handles it herself

```

This sounds like a lot of overhead — it isn't. Step 4 is one line in a Markdown file. Step 5 takes seconds.

---

Which Agent for Which Tasks?

This is the decision Sam makes with every delegation. Our routing:

| Task Type | Delegated To | Mechanism |

|-----------|-------------|-----------|

| Code review | Peter | sessions_send |

| Write blog post | Maya | sessions_send |

| Quick research | Sub-agent | sessions_spawn |

| CEO briefing | Atlas | sessions_send |

| Email replies | Alex | sessions_send |

| Complex analysis | Sub-agent (Opus) | sessions_spawn with model="claude-opus" |

The most important factor: Do I need the answer immediately? → Sub-agent. Can I wait and let the agent work independently? → sessions_send.

---

Mistakes We Made (and You Should Avoid)

Mistake 1: Too Granular Delegation

We initially delegated every small step. "Peter, create a variable." That's overhead without benefit. Agents are good for tasks that replace 5–60 minutes of human work. For 5-second tasks: Sam handles it herself.

Mistake 2: No Task Acknowledgment

Sam sends a message to Peter. Peter doesn't respond (maybe another task is running). Sam spawns a second Peter. Now the same task is running twice.

Solution: sessions_send with a clear acknowledgment pattern. Peter writes as its first action to its status file: "TC-47: IN PROGRESS". Sam checks the file before sending a second task.

Mistake 3: Circular Delegation

Peter needs information and sends Sam a message. Sam forwards it to Iris. Iris sends the result to Sam. Sam replies to Peter. That's a 3-hop chain for something Sam could have asked Iris directly.

Rule: Maximum one delegation hop. If Peter needs something from Iris, Sam sends directly to Iris — not Peter → Sam → Iris.

Mistake 4: Shared State Without Locking

Two sub-agents write to the same file simultaneously. Result: corrupted data.

Solution: each sub-agent writes to its own file. Sam combines the results. No shared writes.

---

The Full Picture: How a Real Workday Runs

8:45 AM — Sam's morning report cron fires:

```

Sam spawns 3 parallel sub-agents:

├── A: Email check → 2 important emails, 14 newsletters

├── B: Calendar → 1 meeting at 10:00, 1 at 15:00

└── C: ClickUp → 3 high-priority tasks open, 1 blocked

Sam summarizes and sends report to Dimitrios via Telegram.

Sam identifies: TC-89 (critical bug) needs immediate action.

Sam delegates TC-89 to Peter via sessions_send.

Sam notes in HEARTBEAT.md: "TC-89 delegated to Peter, check at 10:00"

```

10:00 AM — next heartbeat:

```

Sam reads HEARTBEAT.md.

Sam checks Peter's status file: TC-89 = IN PROGRESS, estimated done 11:00.

Sam updates HEARTBEAT.md: "TC-89 wait until 11:00"

```

11:00 AM — heartbeat:

```

Peter's status file: TC-89 = DONE, PR #142 created.

Sam briefly reviews PR #142.

Sam informs Dimitrios: "TC-89 fixed, PR ready for review."

Sam removes TC-89 from HEARTBEAT.md.

```

Total human involvement: Dimitrios reads the morning report and the final status. Everything else: entirely between agents.

---

The Cost of Orchestration

This is the practical part: every communication between agents costs tokens.

For the "$400/month" setup from the viral tweet: that's realistic if most coordination happens through shared memory, and sub-agents are used sparingly for actual parallel work.

Our setup runs at ~€350–450/month for 6 agents in active operation — the majority of that is LLM costs for actual content work (code, writing, analysis), not coordination.

---

Going Deeper

The complete implementation — system prompts, SOUL.md configuration for each agent role, Docker setup, and the exact cron configurations — is documented in the OpenClaw Setup Playbook.

18 chapters. The real setup, not a hypothetical framework.

Fully available in German too. 🇩🇪