DEV Community

MrClaw207
MrClaw207

Posted on

I Delegated My Morning Research to a Team of OpenClaw Agents. Here's the Architecture That Actually Works

#productivity

My single OpenClaw agent was good at one thing at a time. Research, write, post — sequentially. It worked. But it was slow, and whenever a step failed, the whole chain stopped.

So I split the work across a team.

It took three iterations to get right. This is what I learned — with the code that finally worked.

The Problem With a Single-Agent Pipeline

When you chain everything into one agent session, you get a few failure modes that are hard to avoid:

  • One bad API response crashes the whole pipeline
  • Research and writing can't overlap, so you're always waiting
  • Memory pressure grows with each step because the context never resets

The fix isn't more prompts. It's more agents.

Architecture: Orchestrator + Specialist Workers

The pattern that finally worked for me has three roles:

Orchestrator (main agent)
├── Researcher (isolated subagent) → fetches + summarizes sources
├── Writer (isolated subagent)     → drafts from research summary
└── Publisher (isolated subagent) → formats + posts to DEV.to
Enter fullscreen mode Exit fullscreen mode

Each worker gets a narrow toolset, a tight prompt, and its own isolated session. The orchestrator owns the coordination logic and the final output.

Here's the core spawning code:

// Spawn a researcher subagent
const researcher = await sessions_spawn({
  task: `You are a research agent. Your job:
1. Search for recent articles on: ${topic}
2. Read the top 5 sources
3. Return a structured summary with: key_takeaways (array), quotes (array),争议性观点 (controversial takes)

Return ONLY the summary. No preamble.`,

  taskName: "devto-researcher",
  runtime: "subagent",
  model: "minimax-portal/MiniMax-M3",
  cleanup: "delete",   // auto-cleanup when done
});

// Wait for result (non-blocking via sessions_yield)
await researcher.result();
Enter fullscreen mode Exit fullscreen mode

The key detail: cleanup: "delete" means the subagent session is destroyed after it returns. No accumulated context. No memory bleed between runs.

The Isolated Session Trick

By default, subagents inherit the parent context. That's usually wrong for production work — you don't want the research agent reading the writer's draft mid-task.

Force isolation:

sessions_spawn({
  // ...
  context: "isolated",   // no parent context
  sandbox: "require",     // enforce sandboxing
});
Enter fullscreen mode Exit fullscreen mode

This also makes each subagent's memory completely independent. You can run five researchers in parallel on five different topics without any cross-contamination.

The Result Aggregation Problem

Spawning is easy. Aggregating results is where most people give up.

My pattern: the orchestrator collects subagent outputs into a structured object, then passes it forward:

const research = await researcher.result();
const draft = await writer.result({
  context: {
    research_summary: research.summary,
    target_audience: "OpenClaw users doing production work",
    word_count: 900
  }
});
const published = await publisher.result({
  context: {
    article_body: draft.body,
    title: draft.title,
    tags: ["openclaw", "ai", "agents", "productivity"]
  }
});
Enter fullscreen mode Exit fullscreen mode

This "context object" pattern is cleaner than prompt injection and makes each agent's contract explicit.

What Actually Broke (And What I Fixed)

Iteration 1 failed because I gave every subagent full tool access. The researcher tried to post to DEV.to because it had the tool available. Scope your tools per role.

Iteration 2 failed because I used context: "fork" on everything. Context accumulation killed the pipeline after three runs. Switched to context: "isolated" and memory pressure dropped to near-zero.

Iteration 3 worked. Three lines of config change.

The Numbers

After two weeks running this pipeline daily:

Metric Single Agent Multi-Agent Team
Avg. pipeline runtime 22 min 9 min (parallel)
Failure blast radius Whole pipeline One specialist
Memory per run ~800 tokens/hr ~120 tokens/hr

The speedup comes entirely from parallelism — research, first draft, and formatting all happen simultaneously now.

What I Learned

Delegation in OpenClaw isn't about building a hierarchy. It's about building contracts.

A good subagent spec has three parts:

  1. Role — what it is (not what it does)
  2. Inputs — what it receives (not what it finds)
  3. Outputs — exact shape of the return value

When I stopped writing long prompts and started writing tight contracts, the multi-agent system started working.

The orchestrator doesn't need to be smart. It needs to be precise.

If you're running OpenClaw in production and hitting the limits of a single agent, subagent delegation is where most people pivot wrong. The mistake is adding more prompts. The fix is more agents.

Top comments (0)