OpenClaw is an autonomous agent you'd normally talk to over Discord or Telegram. That never sat right with me. Chatting with an autonomous worker through a chat app wastes most of what makes it useful. So I asked the obvious question: what if I connect it directly to Claude, agent to agent?
That's openclaw-mcp. Claude delegates a task, Claw goes off and does the work autonomously on a server, and reports back. One conversation, two agents collaborating. It's my second most successful repo (over 120 GitHub stars), and by stars and issue traffic, more of you seem to run it than run the official bridge.
Where it stops being a toy
Agent-to-agent sounds cute until you see it close a real loop. A couple I actually run:
Bug fixing on autopilot. n8n catches a Sentry alert. An AI node decides it's worth fixing and sends the task to Claw over MCP. Claw clones the repo, spins up Claude Code, fixes the bug, opens a pull request on GitHub, and drops a Slack message with the link. You wake up to a ready-to-review PR. The first time that happened I genuinely didn't believe it until I read the diff.
Jira without the context bloat. Instead of loading ten different MCPs into Claude Code and watching them eat your context window, you load one: Claw. Tell Claw to grab the Jira task; it hands back a clean prompt; you do the work; you notify Jira through Claw that it's done. One bridge instead of ten tool servers is a real context saving.
The unglamorous part: making it safe to run
The fun demo is easy. Making an agent you'd actually leave running took the boring work:
- Docker images on GHCR with OAuth 2.1.
- Security hardening: SSRF protection, input validation, CORS. An agent that clones repos and runs code is a juicy target; treat it like one.
- Configurable timeouts for long-running operations.
- Session persistence, so Claw keeps your conversation context across calls.
Or just npx openclaw-mcp if you want to poke at it in seconds. It's at v1.2.1 with full CI/CD.
The honest warning
I'm not going to pretend this is a tame tool. Claw can go rogue if you don't set it up properly. It's happened to me more than once: an agent with the ability to clone, edit and push, pointed at the wrong flow, will do exactly what you told it to and not at all what you meant. When it works it feels like magic; when it doesn't, it's a mess you have to clean up.
Which is why the next thing I'm building is the opposite of open-ended: a code-forge where the flows are precisely defined and I work with predefined agents instead of hoping an open agent improvises correctly. MCP's improvisation is great for exploration and real trouble for unattended code changes. Know which one you're doing.
Agent-to-tool vs. agent-to-agent
Building this pushed me toward the other half of the picture, so I also built openclaw-a2a, an implementation of Google's A2A (Agent2Agent) protocol v1.0. And the thing worth saying out loud:
MCP and A2A aren't competitors. They're complements.
- MCP = an agent talks to tools. Vertical.
- A2A = an agent talks to another agent. Horizontal.
Today you have one agent doing one thing. The direction of travel is a network of agents, each good at something different, coordinating on their own, and that needs a protocol built for it, not a chat integration bolted on.
Try it (carefully)
Set the guardrails before you hand it the keys.
Do you see real potential in agent-to-agent, or is it still hype? I go back and forth on it myself.
Top comments (1)
This is the right direction. The chat-app-as-interface thing always felt like a temporary hack — agent-to-agent delegation with a structured handoff and a report-back artifact is closer to how you'd actually wire production workflows. The part that interests me is where you draw the boundary: what should one agent be allowed to tell another without a human in the loop, and what's the verification artifact before the second agent takes a real action? Curious if you built any guardrails around that or if you're letting it run warm first.