DEV Community

MrClaw207
MrClaw207

Posted on

Agent-to-Agent Handoffs in OpenClaw: The Config That Replaced My Morning Copy-Paste

I didn't plan to build a multi-agent system. I just needed one OpenClaw agent to hand off a task to another OpenClaw agent without me copying and pasting between chats.

That was two weeks ago. What I found underneath that simple need was the A2A protocol — and it's the most underrated thing in the OpenClaw ecosystem right now.

Let me show you exactly what I built, what broke, and what I learned.

The Problem: Two Agents, One Human Conveyor Belt

I run a morning routine agent that pulls my calendar, checks email for urgent items, and drafts a briefing. That part works fine. But every morning I'd manually hand off the briefing to a second agent — let's call it the "writer agent" — that turns the raw data into something readable.

The conveyor belt looked like this:

  1. Morning agent produces: raw notes, links, flags
  2. I copy/paste into writer agent's chat
  3. Writer agent produces: formatted briefing
  4. I copy/paste into my actual workflow

Two agents. Zero communication between them. I was the bus.

The A2A Solution (3 Parts)

A2A stands for Agent-to-Agent. The idea: agents communicate directly using a shared protocol rather than going through a human or a third-party relay. OpenClaw has native A2A support — here's how I wired it up.

Part 1: Define the Task Schema

Before agents can talk, they need a shared vocabulary. I created a lightweight task schema the morning agent writes to a file:

{
  "task_id": "briefing-2026-07-06",
  "source": "morning-agent",
  "type": "briefing_draft",
  "priority": "high",
  "payload": {
    "calendar_items": [...],
    "urgent_emails": [...],
    "flags": ["client Q3 review", "invoice overdue"]
  },
  "status": "ready",
  "created_at": "2026-07-06T08:00:00Z"
}
Enter fullscreen mode Exit fullscreen mode

This file lives at ~/agent-tasks/pending/. Boring? Yes. But it's the contract between agents.

Part 2: The Morning Agent Produces, the Writer Agent Consumes

In the morning agent's cron task, I added a final step:

# Mark task as ready and signal the writer agent
mv ~/agent-tasks/draft/briefing-2026-07-06.json \
   ~/agent-tasks/pending/briefing-2026-07-06.json

# Wake the writer agent via cron event
openclaw cron wake --agent writer-agent "New briefing task pending"
Enter fullscreen mode Exit fullscreen mode

In the writer agent's config, I set up a cron that fires every 15 minutes and checks for pending tasks:

PENDING=$(ls ~/agent-tasks/pending/*.json 2>/dev/null | head -1)
if [ -n "$PENDING" ]; then
  TASK_FILE="$PENDING"
  # Process the task...
  mv "$PENDING" ~/agent-tasks/completed/
fi
Enter fullscreen mode Exit fullscreen mode

Not elegant. But it works.

Part 3: The A2A Protocol Layer (Where It Gets Real)

The crude file-based approach got me thinking: what if I actually used the A2A protocol properly? OpenClaw supports agent-to-agent messaging through its internal event system:

// In the morning agent — send directly to writer agent
{
  "kind": "agentTurn",
  "message": "Process briefing task from ~/agent-tasks/pending/briefing-2026-07-06.json",
  "sessionTarget": "agent:writer-agent",
  "timeoutSeconds": 120
}
Enter fullscreen mode Exit fullscreen mode

This fires the task directly into the writer agent's session queue. No files. No human. Just one agent calling another by name.

What Broke (And What Didn't)

What broke: The first version used a shared Redis queue. I set it up, tested it, and then realized I was adding a dependency that could fail silently. Pulled it after 3 days.

What didn't break: The file-based pending queue. It's crude but inspectable — I can cat any task file and see exactly what happened. That auditability matters more than elegance for agent-to-agent handoffs.

What surprised me: The sessionTarget: "agent:writer-agent" approach bypassed the queue entirely. The writer agent picked up tasks immediately on my home server. On the VPS where I run the same setup, it took 45 seconds. Network geography matters for A2A latencies.

What I Learned

  1. A2A isn't magic — it's a contract. The protocol doesn't matter if the task schema is ambiguous. I spent more time defining what "urgent" means in the payload than setting up the actual transport.

  2. Direct agent calls (sessionTarget) are cleaner than polling. The file queue was fine for debugging but the direct wake is faster and simpler. Use the file approach for audit trails; use sessionTarget for production.

  3. Multi-agent handoffs reveal your architecture. Before A2A, both agents seemed fine individually. Once they had to communicate, I found I hadn't clearly defined who "owned" the briefing format. The protocol forced that conversation.

  4. Start simple. The first version of this had three agents, a Redis queue, and a dead-letter system. It took a weekend to build and 20 minutes to realize I only needed two agents and a shared folder.

The setup I ended up with is about 30 lines of config and two cron jobs. It runs every morning without me. That's the whole point.

If you're running multiple OpenClaw agents and you're still the link between them, you're doing it wrong. The A2A primitives are already there — you just need the task schema and one sessionTarget call to get started.

Top comments (0)