Before the setup guides, a step back: what is OpenClaw, and why build a whole series around one way of using it?
What OpenClaw is
OpenClaw is an open-source personal AI assistant you run on your own machine. It connects to the chat apps you already use and answers you there. The way the project puts it: the gateway is just the control plane; the assistant is the product. It's local-first, single-user, and always-on, which makes it feel less like a SaaS chatbot and more like a daemon that happens to think.
It's MIT-licensed, built for "Molty" (a space-lobster assistant) by Peter Steinberger and a large community. The home base is its website, the code is on GitHub, and there are full docs. (For the record: I'm not affiliated with the project; I just run it daily and wanted to share the setup.)
The headline is reach. OpenClaw speaks on a long list of channels: WhatsApp, Telegram, Slack, Discord, Signal, iMessage, Google Chat, Matrix, Microsoft Teams, IRC, and well over a dozen more, plus a built-in web chat. It can also listen and talk on macOS, iOS, and Android (Voice Wake plus Talk Mode), and drive a live Canvas you control from your phone or Mac. The point is that you reach it wherever you already are, instead of opening one more app.
The one idea the rest of this series leans on
Under the hood, a local gateway daemon holds those channel connections and routes each inbound message to an agent. The primitive worth remembering is multi-agent routing: different channels, accounts, or peers can map to separate, isolated agents, each with its own workspace and session. One assistant for your personal life, another scoped to a project, another (if you set it up that way) with shell access to a server. Same gateway, different brains.
That single capability is what this series builds on. Hold onto it; Part 1 turns it into something specific.
How people actually use it
I read through what the community is actually shipping (the project keeps a running showcase, and there are plenty of "how I use it" write-ups). A few patterns come up again and again:
- A proactive chief of staff. The most common setup by far. People wire it to email, calendar, and a task manager (Notion, Todoist, Linear), then let it run on a schedule: a morning briefing before you wake, email triage with drafted replies, a nightly job that does real work while you sleep and reports back. A rule people keep repeating is "no notification without a concrete output."
- Browser automation for things with no API. Booking a grocery delivery, reserving a court, logging into a dashboard to screenshot and analyze charts. When there's no clean API, it drives a real browser.
- A coding teammate you talk to from chat. Triage a GitHub issue into a plan and a PR, review a diff and reply with a verdict, even build and ship an app, all from a phone. This is the use this series is about.
- Home, hardware, and voice. Community skills drive Home Assistant, robot vacuums, 3D printers, and cameras; others bridge phone calls or reply with voice notes.
- Skills on demand. When a capability doesn't exist yet, you can ask it to build the skill: it writes and tests one for you. Many of those land on the ClawHub registry for everyone else.
The common thread: people don't treat it as a chatbot they visit. They run it as something that acts on its own and reports back. When you tell it to ship, it ships.
Why this series picks one use
Of all of those, the use that changed my day-to-day the most is the last one. I run coding agents on a remote box, and OpenClaw lets me dispatch and supervise them from Telegram, from anywhere, without opening an SSH session. This series is the exact recipe, plus the piece I built on top that most "drive an agent from chat" demos skip: a skeptical supervisor that checks the agent's work before you trust it.
| Part | What it covers |
|---|---|
| 0: Meet OpenClaw (this post) | What OpenClaw is and the range of ways people use it |
| 1: Topics Are Agents | The mental model: one Telegram topic per agent, and the constraints that shape it |
| 2: From Zero to an Agent That Answers | Stand up your own instance: bot, gateway, one pane-driving agent |
| 3: The Day-to-Day Operating Contract | What to type, what not to type, and how to supervise safely |
| 4: Making Agents Useful | Skills, tool servers, per-topic memory |
| 5: The Skeptical Supervisor | Evidence-before-trust, and how it blocks bad answers |
One thing to set straight early
OpenClaw connects to real messaging surfaces and can run tools on your machine, so treat every inbound message as untrusted input. The project ships with sensible defaults for this: unknown senders hit a pairing step rather than reaching the agent, owners are allowlisted, and non-main sessions can be sandboxed (Docker by default). Wiring a chat app to a shell is genuinely powerful, and the rest of the series keeps coming back to the security model because it deserves the attention.
Where to start
New to OpenClaw entirely? You'll need Node 24 (or 22.19+) and a model provider to authenticate against: OpenClaw brings the plumbing, you bring the LLM, through an API key or a provider subscription. The fastest path is npm install -g openclaw@latest followed by openclaw onboard, or read the getting-started guide; it walks you through the gateway, a channel, your model, and your first agent.
Want the specific setup this series is about, driving and supervising coding agents over Telegram? Part 1 is next: Topics Are Agents, the one idea that makes the whole thing work.
Top comments (0)