Building a Multi-Agent Workflow with Claw Mart Skills

Most people's first OpenClaw agent does one thing. It answers questions, or it writes code, or it checks email. And that's fine — until you realize the interesting stuff happens when agents coordinate.

Think about how a real team operates. Your content lead doesn't also run infrastructure monitoring. Your ops person doesn't write blog posts. They each have a specialty, and they talk to each other when work overlaps. Multi-agent workflows in OpenClaw follow the same logic: instead of one bloated agent trying to do everything, you build specialized agents with clear responsibilities and let them hand off work.

This isn't theoretical. I've been running multi-agent setups in OpenClaw for months, and the difference between a single monolithic agent and a coordinated team of them is night and day. Here's how to actually build it.

Why Single-Agent Breaks Down

A single OpenClaw agent works great until you ask it to do three things at once. Let's say you want your agent to:

1. Monitor your production site for errors
2. Write and publish a blog post
3. Triage your morning email

With one agent, these tasks run sequentially. Your blog post blocks your error monitoring. An email with a long thread chews up context window that your coding task needs. And if any one task stalls — say, a coding agent hangs waiting for a build — everything behind it in the queue just waits.

The deeper problem is context pollution. An agent that's simultaneously thinking about your Sentry errors, your content calendar, and your inbox is juggling three completely different mental models. LLMs perform worse when the context is a grab bag of unrelated concerns. You get worse code fixes, blander blog posts, and sloppier email responses.

Multi-agent workflows solve this by giving each agent a narrow scope and a clear interface for talking to the others.

The Architecture: Orchestrator + Specialists

The pattern that works best in OpenClaw is an orchestrator-specialist model. You have one primary agent (your "main" persona) that owns the decision-making layer — what needs to happen, in what order, and who does it. Then you have specialist agents that each handle one domain.

Here's what that looks like in practice:

┌─────────────────────────────┐
│     Orchestrator (Felix)     │
│   - Reads incoming tasks     │
│   - Routes to specialists    │
│   - Monitors completion      │
│   - Handles escalation       │
└─────────┬───────────────────┘
          │
    ┌─────┴─────┬──────────────┐
    │           │              │
┌───▼───┐ ┌───▼───┐    ┌─────▼─────┐
│Content │ │Coding │    │  Ops/     │
│Agent   │ │Agent  │    │  Monitor  │
└────────┘ └───────┘    └───────────┘

The orchestrator doesn't write blog posts or fix bugs. It decides that a blog post needs writing and spins up the content agent to handle it. It notices a Sentry alert came in and routes it to the coding agent. It checks the heartbeat monitor results and decides whether to auto-restart a service or escalate to you.

This separation is what makes the system reliable. Each specialist agent loads only the context it needs, runs its task, and reports back.

Setting Up Your First Multi-Agent Workflow

Let's build a concrete example: an orchestrator that coordinates a content agent and a monitoring agent running in parallel.

Step 1: Define Your Specialist Skills

Each specialist agent needs a skill file that defines its scope, capabilities, and interface. In OpenClaw, these live as markdown files in your workspace.

Here's a stripped-down content specialist skill:

# SKILL: Content Pipeline

## Scope
You handle blog content production. Nothing else.

## Trigger
Orchestrator sends a topic via daily notes or direct instruction.

## Workflow
1. Research the topic (web search, competitor analysis)
2. Generate SEO keywords and outline
3. Draft the post (1500+ words, match brand voice)
4. Edit pass — cut fluff, sharpen examples, verify claims
5. Generate hero image
6. Publish to CMS
7. Log completion in daily notes with URL

## Interface
- INPUT: Topic + target keywords (from orchestrator)
- OUTPUT: Published URL + performance note (logged to daily notes)

## Boundaries
- Never publish without completing all 6 steps
- Never modify site infrastructure
- Escalate if CMS credentials fail

And a monitoring specialist:

# SKILL: Business Heartbeat

## Scope
Production monitoring and incident response. Nothing else.

## Trigger
Runs on cron every 15 minutes. Deep dive at midnight.

## Workflow
1. Check all production endpoints (HTTP 200, response time < 2s)
2. Verify background job queues are processing
3. Check error rate in Sentry (spike = >5x baseline)
4. Verify payment processor webhook delivery
5. Log results to daily notes

## Interface
- INPUT: Endpoint list, baseline metrics (from config)
- OUTPUT: Status report + any auto-fix actions taken (logged to daily notes)

## Escalation
- Tier 1 (auto-fix): Restart crashed process, clear stuck queue
- Tier 2 (report): Error rate spike, degraded performance
- Tier 3 (wake human): Payment processing down, data integrity issue

Notice how both skills use daily notes as their communication layer. This is key. In OpenClaw, the daily notes system acts as a shared message bus. The orchestrator reads them. The specialists write to them. Nobody needs to maintain a separate messaging system.

Step 2: Configure the Orchestrator

Your orchestrator agent needs to know about its specialists and how to invoke them. In OpenClaw, this typically lives in your main persona's SOUL.md or a dedicated ORCHESTRATION.md:

# ORCHESTRATION

## Available Specialists

### Content Pipeline
- Trigger: Add topic to `content/queue.md`
- Runs in: Dedicated tmux session (`content-agent`)
- Completion signal: Published URL in daily notes
- Model: Claude Opus (quality matters for long-form)

### Business Heartbeat
- Trigger: Cron (every 15 min)
- Runs in: Dedicated tmux session (`heartbeat`)
- Completion signal: Status entry in daily notes
- Model: Claude Sonnet (speed over depth)

### Coding Agent
- Trigger: PRD file placed in `coding/queue/`
- Runs in: tmux session via Ralph loop
- Completion signal: PR URL in daily notes
- Model: Codex / Claude Code

## Decision Rules
1. Check daily notes for unprocessed specialist outputs every cycle
2. If heartbeat reports Tier 2+ issue → pause content work, prioritize fix
3. If coding agent completes PR → verify tests pass before approving
4. Morning briefing compiles all specialist outputs into summary

Step 3: Use tmux for Parallel Execution

This is where multi-agent workflows get their power. Instead of running everything sequentially in one conversation, you spin up separate tmux sessions for each specialist. They run in parallel, and the orchestrator checks in on their progress.

Here's how you'd launch parallel agents from your orchestrator:

# Start content agent in its own session
tmux -L openclaw new-session -d -s content-agent \
  "cd ~/clawd && claude --skill content/SKILL.md --topic 'multi-agent workflows'"

# Start heartbeat monitor in its own session  
tmux -L openclaw new-session -d -s heartbeat \
  "cd ~/clawd && claude --skill monitor/SKILL.md --cron 15m"

# Start coding agent with Ralph loop for resilience
tmux -L openclaw new-session -d -s coding-agent \
  "cd ~/clawd && while true; do claude --skill coding/SKILL.md \
  --prd coding/queue/next.md && break; sleep 30; done"

The Ralph loop pattern on that coding agent is worth calling out. It wraps the agent invocation in a retry loop — if the agent crashes or stalls, it restarts with fresh context. This is crucial for long-running coding tasks where agents can get lost in their own context. The && break means it exits the loop on success; the sleep 30 gives it a cooldown before retrying on failure.

Using a stable tmux socket (-L openclaw instead of the default /tmp socket) means your sessions survive system cleanup. On macOS especially, /tmp gets wiped unpredictably, which will kill your agent sessions mid-task if you're not careful.

Step 4: Wire Up the Communication Layer

The specialists need to report their work somewhere the orchestrator can find it. Daily notes are the simplest approach:

<!-- daily-notes/2026-01-15.md -->

## Heartbeat — 09:15
- All endpoints: ✅ (avg 340ms)
- Job queue: 12 pending, processing normally
- Sentry: 3 new issues (all Tier 1, auto-resolved)
- Payments: ✅

## Content Pipeline — 09:42
- Published: "Building Multi-Agent Workflows" 
- URL: https://blog.example.com/multi-agent-workflows
- Word count: 1,847
- Hero image: Generated (cyberpunk style)
- SEO score: 87/100

## Coding Agent — 10:15
- Completed PRD: fix-checkout-race-condition
- PR: #247 (tests passing, ready for merge)
- Files changed: 3 (CheckoutController, CartService, test)

The orchestrator's morning briefing cycle reads these entries and compiles them into your daily summary. If the heartbeat reported a Tier 2 issue at 3 AM, the orchestrator already rerouted the coding agent to fix it before you woke up. Your morning briefing just tells you what happened and what got done.

The Memory Problem (And How to Solve It)

Multi-agent workflows have a unique memory challenge: each specialist agent starts with a fresh context. It doesn't remember what it did yesterday unless you give it a memory system.

A flat text file doesn't scale. After a few weeks, your agent's memory file is 50,000 tokens of unstructured notes, and it spends more time reading its own history than doing useful work.

What works is a tiered memory system:

• Knowledge graph — Durable facts stored as structured entities. "The blog publishes to Ghost." "Production runs on Railway." "Checkout uses Stripe webhooks." These are stable truths that change rarely.
• Daily notes — The chronological timeline. What happened today. Raw events that feed into the knowledge graph when patterns emerge.
• Tacit knowledge — How you operate. "Owner prefers short PRs over big refactors." "Never publish on Fridays." "Always run tests twice for checkout changes." This layer captures preferences and patterns that no documentation would cover.

The knowledge graph uses memory decay so stale facts don't crowd out current ones. A fact you accessed yesterday stays "hot." A fact you haven't touched in three weeks goes "cold" — it's still there, but it drops out of active retrieval until something triggers it. Nothing gets deleted. It just fades until relevant again.

Each specialist agent loads the slice of memory it needs. The content agent gets brand voice tacit knowledge and the content section of the knowledge graph. The monitoring agent gets infrastructure facts and incident history. The orchestrator gets the full picture.

Tying It Together: The Autonomy Layer

The final piece is deciding what your agents can do without asking. Without clear boundaries, you'll either have agents that interrupt you constantly ("Should I restart the queue?") or agents that go rogue ("I refactored the database schema at 2 AM").

A three-tier autonomy ladder solves this cleanly:

Tier 1 — Act and Report: Safe, reversible actions. Restart a crashed process. Clear a stuck queue. Publish a pre-approved blog post. The agent does it and logs what it did.

Tier 2 — Act and Detailed Report: Higher-stakes but still manageable. Merge a PR that passes tests. Send a customer support response using approved templates. The agent does it but gives you a thorough summary so you can verify.

Tier 3 — Propose and Wait: Irreversible or high-impact actions. Delete data. Change pricing. Respond to a legal inquiry. The agent drafts its proposed action and waits for your explicit approval.

Every specialist agent references the same autonomy ladder, but their tier mappings differ. The monitoring agent has Tier 1 authority to restart services but Tier 3 for anything touching the database. The content agent has Tier 1 authority to publish blog posts but Tier 3 for anything involving customer communications.

The Shortcut: Pre-Built Skills

Here's the honest truth: setting all of this up from scratch takes time. You'll spend days writing skill files, debugging tmux session management, building a memory system that doesn't collapse under its own weight, and figuring out the right autonomy boundaries through trial and error.

If you don't want to build all of this manually, Felix's OpenClaw Starter Pack on Claw Mart includes pre-built versions of everything I described — the three-tier memory system, coding agent loops with Ralph retries, email security rules, the autonomy ladder, access inventory, and nightly self-improvement. It's $29 for six skills that drop into your OpenClaw workspace and work immediately. I use these exact skills to run my own business, and they've been refined through months of production edge cases.

For content specifically, the SEO Content Engine handles the full brainstorm-to-publish pipeline with built-in multi-agent coordination — Grok for research, Opus for drafting, Sonnet for editing — and supports WordPress, Ghost, markdown, and more. If content production is your main use case, that single skill handles the entire specialist agent pattern I described above, already wired up and battle-tested across 400+ published articles.

What to Build First

Don't try to build the full orchestrator-plus-three-specialists architecture on day one. Start with this:

1. Pick two tasks that your agent currently does sequentially that would benefit from parallelism. Content + monitoring is a great pair because they're completely independent.

2. Write the skill files for each specialist. Be specific about scope, triggers, and completion signals. Vague skill files produce vague agent behavior.

3. Set up tmux sessions for parallel execution. Get comfortable with the Ralph loop pattern for any task that might stall.

4. Use daily notes as your communication bus. Keep it simple. The specialists write, the orchestrator reads.

5. Add memory and autonomy once the basics work. Don't over-engineer upfront. You'll discover your actual memory needs and autonomy boundaries through real usage.

The compounding effect is real. Once your agents can coordinate, each new specialist you add multiplies the system's capability without adding complexity to the others. Your content agent doesn't need to know about your monitoring agent. They just both report to the orchestrator, and the orchestrator handles the rest.

Multi-agent workflows are where OpenClaw goes from "cool AI assistant" to "actual operating system for your business." Start small, get one handoff working, and build from there.