I use several openclaws at home and a few in the cloud. It's super annoying getting them to message each other / send files to each other. So I built AgentTransfer:

https://github.com/shehryarsaroya/agenttransfer

It's a single Go binary (can easily host on home laptop / mac mini or vps).

It uses hosted file links and each email gets an email. Agents can sign themselves up, on the server version or your own hosted version.

Let me know if you guys think this is helpful.

i run an agent that reads x every day, filters out the noise, and sends me a summary on imessage, it's a cron job, a database, and a model call running in a loop.

you can run the Agent on your own on a VPS or a already hosted version on your imessage, telegram.

Seven components

every personal agent, openclaw, hermes, or something you build yourself, breaks into the same seven parts:

1. Gateway, one long-running process connected to every chat platform, functioning like a kernel.
2. Loop, the engine, every event, message or timer, runs through this:

​

while True:
    event   = wait_for_input()        # a message, a heartbeat, a webhook, a cron
    context = load_state(event)       # history + database + memory, built into a prompt
    reply   = model.call(context)     # one "thought"

    while reply.tool_calls:           # if it wants to act, let it — then think again
        results = run_tools(reply.tool_calls)   # shell, files, browser, web
        context.append(results)
        reply = model.call(context)

    persist(event, reply)             # write it down so a restart doesn't wipe it
    if reply.text:
        respond(event.channel, reply.text)
    # else: stay quiet. doing nothing is a real output.

1. Memory, state on disk, a transcript plus a searchable database.
2. Skills, reusable procedures in markdown, written by a person or, in hermes's case, by the agent itself.
3. Tools, shell, files, browser, web, where the agent gets useful and where it gets risky at the same time.
4. Heartbeat, a timer that injects a synthetic event into the loop, my x reader is a heartbeat and nothing else.
5. Model, the llm behind a swappable interface, cloud or local.

Two different Agent

openclaw runs hub-and-spoke, one gateway daemon coordinating fifteen-plus chat platforms, a skill marketplace called clawhub, and agents that can spawn other agents, the internal codename for the rewrite was "the agent os," and it's an accurate label, the bet is breadth.

hermes, from nous research, bets on depth instead, its loop solves a task, writes down what worked, retrieves it later, and refines from there, and when a task takes multiple steps or needs a correction, the agent writes its own skill file:

---
name: deploy-staging
triggers: ["deploy to staging"]
uses: 7
---
## Steps
1. Build the web app. If it fails, read the error, fix the import, retry once.
2. Run the tests. Only continue on green.
3. Deploy to staging. Post the URL to #eng.

its always-loaded memory has a hard character cap, forcing it to keep what matters and search the rest on demand instead of dumping full history into every prompt.

openclaw scales out across channels while hermes scales in on one private history, and both are closing the gap from opposite directions, openclaw is adding memory, hermes is adding integrations.

Security is the constraint

any personal agent sits at lethal trifecta, it can add untrusted input like emails or web pages and you get prompt injection, since models can't reliably separate data from instructions.

openclaw's early versions ran shell commands with no approval step at all, that fast, open growth meant a fast attack surface, real vulnerabilities, poisoned skills on clawhub, and researchers finding roughly a quarter of a million exposed openclaw instances sitting on the open internet.

hermes built the boundary in from the start instead, deny-by-default access plus a hardline blocklist that nothing can override

Run the Agent on VPS or use the hosted one they have tend to keep you secure as they are not running in your machine.

We heard the feedback. v2026.6.11 focuses on the rough edges that make OpenClaw feel less dependable, with fixes for misplaced replies, stuck sends, reconnects, model setup failures, and safer admin defaults.

Replies, sends, and reconnects

Across Telegram, WhatsApp, Matrix, Google Chat, iMessage, Feishu, and Mattermost, replies, commands, queued messages, and attachments are less likely to be dropped, duplicated, misrouted, or attached to the wrong conversation.

WebChat and the Control UI keep the active conversation visible more consistently after reconnects. The terminal UI now clears completed or rejected sends instead of leaving them looking stuck.

Models and fallback recovery

Model selection and setup recover more clearly when catalogs, credentials, streams, timeouts, compaction, or fallbacks go wrong. Affected OpenAI, OpenRouter, and OpenCode Go setups are less likely to leave users with a stale model choice or a stalled request.

Follow-up fixes improve fast mode in affected provider and fallback paths. Automatic fast mode itself is not new in this release.

Sessions, memory, and safer recovery

Sessions, compaction, memory, and QMD-backed memory preserve the intended conversation and useful context more consistently through long-running work, reconnects, upgrades, and transcript repair. Tool search also recovers the right context or capability more reliably.

Encrypted Matrix recovery now stops safely when required key state cannot be verified. Tool policies, approvals, and secret handling stay attached to the intended runtime state, while higher-risk actions remain disabled unless explicitly enabled.

Plugins and installation

Plugin management now handles more official integrations through normal external package installation and repair flows. The plugin inventory and setup checks give clearer guidance when a package is missing, incompatible, or needs to be reinstalled.

Admin and deployment controls

Slack router relay mode gives managed or multi-gateway deployments a supported way to centralize incoming Slack traffic while the correct gateway still handles mentions, threads, and replies. The Raft channel and Raft plugin add a local CLI wake path for External Agents, including setup and status checks.

Gateway health and troubleshooting signals now line up more consistently with whether OpenClaw is ready, restarting, or unable to continue. Agent runs started through the CLI and the broader gateway recover more cleanly from disconnects, shutdowns, routing changes, and failed startup conditions.

Setup, commands, and scheduled work

Common CLI commands now handle configuration, paths, output, and failure cases more consistently. Shell completion, doctor, config commands, and gateway configuration provide clearer guidance when an installation or setting needs attention.

Scheduled jobs and built-in tools now finish, retry, report failures, and preserve their intended inputs more consistently. The plugin SDK runtime also improves reliability for tool-backed extensions that load, return results, or run scheduled work.

Full Release Notes

This release includes 302 PR-backed units and 704 direct commits. Full notes: https://docs.openclaw.ai/releases/2026.6.11