What can OpenClaw do for you?

Samuel Tardieu, 2026-11-06

OpenClaw is a self-hosted personal agent. It is free software, released under the MIT license (source code on GitHub). It is a gateway that runs on your own machine, talks to you through a chat channel (Telegram in my case, plus a web interface), and can use tools: shell commands, scripts, a headless browser, MCP servers, and scheduled automations. Mine runs on a small NixOS box at home, listening only on loopback.

People often ask what such an agent is for, beyond demos. Here are a few things it does for me every week. None of them are spectacular on their own; together, they remove a lot of small chores.

One idea runs through all of them: keep the model out of the loop unless there is something to think about. A language model is slow, costs money, and can make mistakes; a ten-line script checking whether something changed is none of those things. So most of my automations start with a plain script. If nothing changed, no model runs, nothing is spent, and I receive no message. The model only steps in for what scripts are bad at: reading a messy announcement, summarizing a changelog, explaining a trend.

Finding jam sessions

I play jazz trumpet as an amateur, and I am always looking for jam sessions where a trumpet and a jazz repertoire would fit. The information is scattered: venue websites, online agendas, a Facebook group, Instagram accounts, and a couple of WhatsApp groups where musicians post “anyone up for a jam tonight?”.

OpenClaw gathers all of it:

public agendas and venue pages are fetched directly;
the Facebook group, which is behind a login wall, is read through a headless browser profile that stays logged in;
the WhatsApp groups are recorded read-only by a small plugin attached to OpenClaw’s existing WhatsApp connection. Group content is treated as untrusted data: the agent never posts, reacts, or follows instructions found in messages.

Every morning I get a digest of upcoming jams, and a few times a day a short alert if a new jam has been announced for today. A dashboard lists the next seven days, and every entry says where it was found, with a link when there is one. If a detail is missing (the time, the style, whether it is an instrumental jam or a vocal open mic), it is marked as uncertain rather than guessed.

“What can I do tonight?”

The same knowledge serves a simpler, on-demand question: “anything worth going to tonight?”. The agent searches the day’s listings, checks the venues’ own agendas (generic listings are often wrong or stale), drops events that are already over, checks the weather if the answer involves cycling, and comes back with two to four verified options and one clear recommendation.

A music database

I keep notes on the repertoire of the music workshops I attend: tunes, composers, performers, recordings, linked together as Org-roam notes and published as a small website.

When a new tune is added, from a playlist or from a set of scores, the agent:

finds which tunes are actually new compared with the existing notes;
researches who wrote the tune separately from who recorded it, citing its sources, and says when the credits are uncertain instead of assuming that the first artist found is the composer;
creates or updates the notes and the links between them, then checks that every link resolves;
rebuilds and publishes the site, and verifies the live pages (not just a successful build).

Phone battery investigation

My phone’s battery drains faster than it should, and Android’s own battery screen is not much help in finding out why. So I asked OpenClaw to run a two-week study.

On the phone, an automation (MacroDroid, with Shizuku for privileged read-only access) takes an hourly sample of Android’s battery statistics and uploads it over my VPN to the home server. It never resets the statistics and never restricts any app: the goal is to observe, not to change the outcome. The collector removes itself at the end of the study.

On the server, a script turns these cumulative counters into daily per-app figures. This sounds easy, but the counters reset and get revised without warning, so the script detects resets, only counts positive deltas, and separates screen-on from screen-off usage. Every morning I get a briefing with the top consumers, how much screen-off activity they had, and how reliable the data is (number of samples, gaps, resets). At the end, a final summary will point at the real cause, or at least rule out the wrong ones.

Updating the Internet box, on my terms

My ISP’s box gets firmware updates that only install when it reboots, and a reboot means a few minutes without Internet (and without home automation). OpenClaw handles this without ever surprising me:

an hourly script checks the installed version and the vendor’s release feed; the model is not involved at all, and in most weeks it never wakes up for this;
when an update is pending, I get a Telegram message in the evening with the changelog and two buttons: postpone by one day or postpone indefinitely;
if I do nothing, the box reboots at 04:45, when nobody is using the connection, and I am told the next morning that the new version is installed;
several safeguards prevent silent reboots: the reboot only happens for a version I was actually notified about, and if a pending update goes unannounced for 36 hours, I get a warning instead. Long postponements trigger a weekly reminder.

Tapping a button is the decision; the agent does not ask again.

Keeping VPN exit nodes usable

I use Tailscale with Tailnet Lock enabled, which means that every node must be signed by a trusted key before my devices accept it. Tailscale also resells Mullvad exit nodes, and Mullvad regularly adds and re-keys servers, which then show up as locked and unusable.

Once a week, OpenClaw runs a script that signs the new Mullvad nodes, only for the countries I chose (each signature is a permanent entry in the lock log, so signing everything is not a good idea). It keeps a per-country record of what was signed and when, and stays silent when there was nothing to do.

French law, from the source

OpenClaw can use any MCP server. One I find especially useful is Droit Français MCP, which queries the official French legal APIs: Légifrance for codes, laws, decrees and the Journal officiel, and Judilibre for case law. Instead of paraphrasing half-remembered articles, the agent quotes the version of the text currently in force, with references I can check myself. It does not replace a lawyer, but it is a good first step to understand where a question stands.

Skills it learned by itself

OpenClaw follows skills: short Markdown files describing a procedure, loaded when a task matches. Some ship with OpenClaw, others can be installed from a public registry, and the agent can also write its own. After a tricky multi-step task, or after I correct it, it saves the procedure that worked, or patches the skill that misled it, and tells me so (I can undo the change in one word). Every version is kept.

Two examples of skills it learned along the way:

Vetting third-party skills before installing them. Public registries contain several skills with the same name from different publishers, and “the one whose name matches” is not necessarily the safe one. The learned procedure lists every candidate, runs the registry’s security verification on each, reads the publisher’s own notes (demo-only status, data sent to third parties, required credentials), checks whether the skill ships executable scripts, and asks me before installing anything flagged. It has already turned down a suspicious skill that had exactly the right name.
Writing monitoring automations that stop cleanly. Many watches have an end condition: the event was confirmed, the season is over, the flight has landed. The obvious approach (the last run disables its own job) turned out to suppress that run’s final message, which is precisely the one I want to read. The skill now says: the last run records that it is done and delivers the result; the next run notices this, disables the job, and stays silent. The same skill also insists on reading a job back after creating it, and on not confusing “scheduled” with “ran successfully”.

None of these are things I would have thought of writing down in advance. They come from real mistakes, and the mistakes were not repeated.

What makes it work

A few lessons from these examples:

Scripts first, model second. Cheap deterministic checks decide whether there is anything to do, and the parts that must be reliable (rebooting a box, signing a key, computing battery figures) are scripts, not prompts. The model glues things together and handles the fuzzy parts.
Silence is a feature. Most runs end with no message at all. When something arrives, it is worth reading.
Explicit boundaries. Read-only access where possible, no action on my behalf without my OK, buttons for decisions, and safeguards so that a broken automation fails loudly rather than doing something silently.
Procedures that improve. When something goes wrong, the agent updates the skill it follows, so the same mistake does not happen twice.

None of this required writing a large application. Each example is a few scripts, a written procedure, and a schedule; the agent glues them together and handles the parts that need judgment.