I tested OpenClaw for two weeks: here is what I learned

I installed OpenClaw two weeks ago. Since then, I use it five to ten times a day. Let's start with the bad news for fans of spectacular demonstrations: I haven't fired anyone, my business isn't running on its own, and there's no army of agents working while I quietly drink my coffee.

The reality is less spectacular, but it interests me more. OpenClaw has become a good extension of my hands for a few specific tasks. I talk to it normally; it chooses its tools, works in a repository, opens a merge request, transcribes a voice message or prepares the framework for a publication. And, some days, it burns tokens at remarkable speed, breaks its own configuration, or demands access it should never have.

I prefer to warn you straight away: this story will be deliberately down to earth. No “my life will never be the same again,” no captures where six digital agents run a business while I sleep. I'm going to tell you what I actually configured, what it cost me, what broke and why I continue to use it despite everything. It's less salesy, but it's precisely the part that interested me before installing it.

What OpenClaw actually adds to an LLM

A large language model receives text and returns text. All the apparent magic starts from there. An agent adds a loop: with the message, it transmits to the model the description of the available tools. The model then doesn’t just respond with a sentence; it can ask, in a structured form, to execute an action.

This idea remains a bit of an intellectual shock for me. We're talking about models that write code, analyze an image, or appear to reason; yet, at the heart of the device, there is always a transformation of text into text. In a classic chat, I write a question and I receive an answer. With an agent, we simply add — “simply” with a lot of quotation marks — a list of things that the system around the model knows how to perform.

If I say "remind me to call a customer in an hour", the model identifies the intention, OpenClaw creates the task, then the result goes back to the model so that it formulates the confirmation. To send an e-mail, consult a repository or control a browser, the principle remains the same: the model advises, the gateway executes, the result returns to the model.

Concretely, my sentence becomes something that looks like a JSON call: tool name, time, reminder text, possibly conversation identifier. The gateway receives this order, creates the reminder and returns a result to the model with its identifier. The model can finally answer me: “it’s done”. Even this last sentence is a new step. The agent does not celebrate its success alone: ​​it asks the LLM how to properly announce it to me.

This detail is important, because it removes a good part of the mystery. OpenClaw is not a digital consciousness hidden in my server. Without a model, it does not “think.” It is an orchestration layer that carries context, exposes tools, executes their calls, and returns results. At each slightly ambiguous stage, it returns to seek advice from the LLM. This explains both its flexibility and its consumption.

The first agents already worked like this, but their toolbox was frozen. To add email sending, a developer would write an SMTP function, declare it as a tool — possibly via MCP — then redeploy the application. The model then received the description of this new function with each request. It was effective, but the evolution of the agent remained classic development work.

So we already had agents before OpenClaw. When they were missing a feature, I could open my IDE, have a coding assistant write the integration, save it to the app and then redeploy. It had become much faster than before, sure, but there was still a human in the middle to take the generated code and plug it into the right place. The idea floating around in my head was obvious: since the agent already knows how to write this component, why couldn't it also install it itself?

Where OpenClaw becomes really interesting is that it knows how to extend its own environment. I can ask it to accept my voice messages: it reads the documentation, inspects the machine, installs or configures a component, adds a hook, then restarts what needs to be restarted. The tool catalog is no longer fixed. The agent itself participates in the creation of its capabilities.

The sequence is almost unsettling the first time: I formulate the need, it searches for the documentation for its own platform, locates the configuration file and the type of hook expected, prepares the modification then restarts. In theory, I no longer have to beg the agent developer to add a feature in a future release. In practice, I become precisely the person who must check that the agent has not missed a comma before cutting itself off.

It’s exhilarating. This is also exactly the time to be wary: a system capable of changing its configuration might forget a comma, produce invalid JSON, and then refuse to reboot. This happened to me, obviously.

Why the whole Internet went crazy

The idea of an agent capable of completing itself had been floating around for some time. With coding assistants, writing a new tool had already become much faster. OpenClaw removed the step where I had to take the generated code, install it, save it, and restart the system. The agent can read its own documentation, understand which file needs to change, prepare the component and restart its service.

Obviously, the demonstrations circulated very quickly. We saw assistants sorting mailboxes, booking tickets, filling out forms, monitoring dashboards and coordinating other agents. Then came the usual promises: no need for a team, no need for an office, everything works on its own overnight. This is the moment when my old technician reflex is triggered.

I've watched a lot of these demonstrations. Some gave me really good ideas; others made me think, “My God, you really shouldn’t do that.” I'm not putting all authors in the same bag - I can't verify every installation - but the mechanism of the rush is obvious. A video where the agent books a trip and responds to customers is more engaging than a story where they correctly create a Git branch. However, in my work, it is the second scene that has the most value.

Since the beginning of my career, I have already seen several technologies presented as an irreversible change in the rules of the game. Virtual worlds were to replace desktops, virtual reality was to become our main screen, and each new wave was to make the previous one obsolete. Some bricks survive and become useful. The big story generally disappears much more quickly.

I've been working in IT since 2008. I've heard at least five or seven times that the rules have definitely changed. They evolve, of course, but rarely in the way announced during the week of the hype. This skepticism does not prevent me from using OpenClaw: on the contrary, I use it enough to see new use cases every day. It only prevents me from confusing the real utility with the trailer for that utility.

I'm not saying that OpenClaw is a gimmick. I actually use it several times a day, which is already more than many supposedly revolutionary tools that have been tested and forgotten. But I wanted to check something more modest: where is the value when you remove the demonstration, the video editing and the science fiction vocabulary?

Why I haven't installed the agent on my main computer

The shortest path would be to run the installation script on my work computer, then let OpenClaw access the files, browser and applications. In a demonstration, it's brilliant: the agent finds a contract, updates the dates, compares tickets between Brussels and Amsterdam, fills out a form or reuses an already open session.

The documentation actually offers a very short installation command for macOS, Linux, WSL or PowerShell. It downloads the dependencies, installs the service and starts it in the background. It's convenient, and that's precisely why I don't recommend launching it mechanically on the machine where your entire digital life and work live. A one-line command does not reduce the trust perimeter: it hides it.

On paper, the positive side is great. I can say, “Find this client’s contract, update the date and contact information, then send the document back to me.” I can ask it to open the browser, examine the timetable for a Brussels–Amsterdam journey and prepare a reservation with the information already saved. This is the Jarvis fantasy, no longer in a movie, but sitting next to my real files and my real credit card.

The problem lies in this same demonstration: it sees the files, the browser and the sessions. Part of this context may leave with the model supplier. Then, all it takes is a hallucination, a misunderstood instruction or a hidden injection in a web page for a real action to be triggered. I have no desire to entrust my clients' documents, my keys and my daily browser to a still experimental tool.

We can construct a film scenario in which the supplier of the model deliberately seeks my secrets. I don't believe it much. I don't think I'm interesting enough for a big company to mount a special operation against my disk. But technically, the chain of trust does exist: OpenClaw describes its tools and part of my context to a remote LLM; this LLM offers calls for tools; my machine runs them. Giving this circuit the ability to search the disk or install a service merits more than an enthusiastic click of "next."

You don't even have to imagine a malicious provider. The most credible scenario is much more mundane: a page contains an instruction that the agent mistakes for instructions, a tool is given a path that is too wide, or the model takes "clean this folder" a little too literally. The danger is not only that someone steals my data. The danger is also that a well-intentioned assistant will do exactly the wrong thing with great enthusiasm.

Models hallucinate. The best are less often wrong with basic additions, but they are still wrong with complex situations, precisely those for which they are given a terminal and a browser. So it’s not an abstract fear of AI. I've seen people ask OpenClaw to "handle everything itself" and then come for help when the service stops starting. The model had no malicious intent: it simply wrote a bad file.

The browser further increases the scope of action. An open session sometimes contains access to invoices, an administration console, payment methods or internal tools. If the agent knows how to click for me, it can save me ten minutes. It can also transform a reasoning error into a purchase, a message sent or a production adjustment. Convenience and risk come from the same privilege.

So I installed it on a separate small virtual machine. The next step will probably be an old laptop running Ubuntu, with its own user and browser. No need for a powerful machine: the calculation of the model is done at the supplier. What matters here is isolation. If the agent decides to break everything, I'd rather it break its sandbox than my workstation.

The dedicated laptop also has a very mundane advantage: I can connect to it remotely, open a page myself and tell the agent "look here" instead of giving it permanent access to my daily browser. Its user, its history and its sessions belong to it. At worst, it can damage its own workshop. This is exactly the kind of slightly boring border that demos tend to edit out.

This choice also avoids frequent misunderstanding. A high-end mini-computer is not essential to run the gateway. When idle, OpenClaw consumes little; the heavy part, inference, runs elsewhere when I use a remote model. An old laptop, a VM or a small server is often enough. I'd rather invest in a clean separation of accounts and secrets than in an impressive machine sitting on the desk.

Unless you want to run the model locally, buying a powerful machine just for OpenClaw is more for pleasure than necessity. The gateway is not the motor: it holds the steering wheel and calls the remote motor. My priority investment remains an environment that I can reinstall, backups and rights that I can revoke.

• dedicated machine or VM, without automatic mounting of my personal folders;
• agent-specific system account and browser profile;
• access granted one by one, for an identifiable use and duration;
• separate secrets, revocable and limited to what is strictly necessary;
• versioned configuration so you can see exactly what the agent is modifying;
• no deployment, purchase or sensitive sending without human validation.

Current documentation provides tool policies, allowlists, security auditing, and several sandbox modes. They must be used consciously: the execution sandbox is not a perfect boundary and it is not automatically activated for all the tools of a classic installation.

The stupidest failure remains a real failure

I've seen a very simple problem come up for several people: the agent modifies its JSON file, forgets a comma or a brace, then no longer starts. With a great model, this happens less often. With a cheaper model chosen to save tokens, schema errors quickly become visible.

For a developer, the repair sometimes takes two minutes. I validate the JSON, look at the last diff and correct the error. For a person who installed the agent precisely because they do not want to touch the configuration, the experience ends with a silent service. The same system that was supposed to repair itself can no longer boot up to read the "repair yourself" message.

So I keep the configuration directory under Git. Before a major change, I want to know what will change. Afterwards, I look at the diff. For startup settings, permissions and mail bindings, I still prefer to edit the JSON myself. It's not very futuristic, but it's a great way to have a quiet Tuesday evening.

The hidden cost: every “hello” carries a suitcase

OpenClaw itself is lightweight. The bill can quickly add up. Each decision requires an inference and my simple “hello” never travels alone: ​​the model also receives the system prompt, the agent's rules, its tools, its skills, part of the memory and the history deemed useful.

During my test, with the current configuration and prices, a fresh session started around 10,000 input tokens. Resetting the session and receiving the greeting cost about two cents. Creating a simple reminder cost around 45,000 tokens and nine cents. Requesting the addition of two pages in a project consumed around 263,000 input tokens, 6,000 output tokens, including 168,000 served from the cache: around a few tens of cents for a fairly modest modification.

Why 10,000 tokens before you even start? Because “hello” comes with a small administrative bag: who is the agent, how should it respond, what tools does it have, what skills are installed, what rules apply, what memory is relevant and what part of the conversation must be preserved. In an ordinary chat, my word weighs a few tokens. In an agent, it wakes up an entire environment.

The 45,000-token reminder seems even more absurd until you look at the journey. The model understands the request, chooses the tool, possibly consults the correct way to call it, receives the result, verifies that the task exists and then prepares a readable response. OpenClaw does not do all this with a small deterministic engine: it queries the model at several stages.

I deliberately phrase it a little bluntly: without an LLM, OpenClaw is a machine without brain or will. At each junction, it returns to its advisor: “what should I do to make the user happy?” Then, once the action is finished: “how should I report to the user that I did a good job?” This flexibility is the product. This is also the invoice line.

Do not take these figures for a universal rate. The model, cache, provider and prices change. They just show what's going on under the hood. With pay-as-you-go, an unfortunate loop becomes a bill. With a capped subscription, the agent eventually hits the limit and stops. It's annoying, but at least the fuse blows.

On longer development tasks, I've seen the counter approach a million input tokens, with tens of thousands output and some context served from cache. It’s not necessarily a million “new” tokens in the human sense: rules, files and tool outputs circulate several times. But billing still adds them all up.

The most misleading thing is the speed. A change can last five minutes and give the impression of a small, almost free service. In those five minutes, the agent may have read the repository, queried the model, launched a tool, reread its output, fixed its code, ran the tests, and summarized the result. My timer doesn't show how much context has flowed.

This is also why I am wary of the formula “the agent replaces an employee”. It can absorb a specific function, for example preparing a summary, opening an MR or checking a box. If you let it reason and act non-stop for hours with an expensive model, the economy becomes much less attractive. The agent is not free because no one touches the keyboard.

And which employee are we replacing exactly? The one who only opens the mailbox once an hour and makes a digest? If the entire function of a person can be reproduced by such a tight loop, the real problem was perhaps already the organization of work. On my team, coding assistants increase productivity, but I haven't laid off any developers. I may recruit more slowly for a while; this is not the same statement as "the agents replaced the team."

Pay-as-you-go or subscription?

With an API billed by token, I retain great freedom, but I carry all the risk of a loop or an inflating context. A subscription better limits the disaster: when the quota is reached, the work stops until the next renewal. To experiment, this ceiling reassures me more than a bank card left open behind a nighttime automation.

Subscriptions do not make inference infinite. Affordable offerings have windows and ceilings; higher plans quickly cost several hundred dollars per month. For one person, this may still be acceptable. For an entire team, multiplying accounts and packages seriously changes the calculation. The cost must be compared with the time actually saved, not with an abstract promise of autonomy.

At the time of my test, an entry-level personal plan was mainly a way to experiment. With sustained agentic use, the short-term quota disappeared quickly, then the weekly cap kicked in. The much more expensive offers gave more breathing room without becoming unlimited. This is a point that marketing tables poorly convey: an “active” human conversation and an agent who multiplies tool calls do not consume at all the same rate.

At an enterprise scale, buying a large personal plan for each developer is not automatically the optimal solution, and professional contracts change the calculus again. We ended up centralizing several models behind our own gateway in order to control access and expenses. I do not present this as a universal recipe: it is simply the consequence of collective use where personal limits became too difficult to predict.

My recommendation to start therefore remains prosaic: first use a capped envelope. A limit that interrupts the agent for five hours is frustrating, but it is better than a nightly loop linked directly to billing without a cap. Once consumption is understood, we can consciously decide to open the tap more.

Cron and heartbeat: automation consumes even when nothing is happening

My messages are not the only ones to consume. A scheduled task might wake the agent up every hour, have it check the mailbox, ask the model what to do, find that nothing has happened, and then go back to sleep. Even this magnificent “nothing to report” required context, a decision and a few tokens.

I therefore reserve recurring automation for controls that really justify interpretation by model. A deterministic check, an API request or a few lines of script cost less and are often more reliable. The LLM only intervenes when the result requires language, ambiguous classification or a contextual decision.

To return to the email example: a script can first ask the server if there are new emails. If there are none, it stops without calling the model. If there are ten, it only transmits these ten messages for classification and summary. Waking up the full agent every hour to discover an empty box is technically possible, but it's a very expensive way to learn that nothing happened.

I saw configurations that wanted to automate everything, all the time. After a day or two, the quota had disappeared or the bill had taken on a much less amusing shape. The problem was not an extraordinary task: it was the accumulation of small awakenings, each accompanied by the system prompt, the tools, the memory and a request to the model. The agentic cost is often hidden in repetition, not in the big red button.

First practical use: reminders that won't let me go

My most frequent use is almost banal. I say, “Remind me to call this customer in an hour, then follow up with me every ten minutes until I confirm.” A classic calendar can display an alert. OpenClaw keeps the intention in mind and continues until my confirmation. It's sometimes painful. This is precisely why it works.

It's not revolutionary, but it's a little friction removed. The rule remains the same: the reminder should not have access to my entire mailbox, my disk and my production repository simply because it knows how to restart a task.

The carnival of possible uses

Once the agent is connected to the browser, messaging, terminal and APIs, the ideas come naturally. It can read emails, send a report, retrieve metrics, fill out a form, search for a restaurant, compare tickets or supervise other agents. Some demonstrations almost resemble a strategy game: several digital characters share the code, deployment and monitoring.

I find it fascinating to watch. I'm not sure I want to work like this. A spectacular interface is not necessarily a good process. What I'm looking for is more sober: to extend what I already know how to do, in moments when my keyboard is not available, while maintaining a clear point of control.

In a private community, I even saw an installation transformed into a strategy game: several agents moved as units, one built the site, another prepared the deployment, a third monitored the result. I could have watched the demonstration for a long time. But I never imagined myself working like this for a single second. It was a very good show interface, not necessarily a good day's work.

My criterion is poorer in special effects: does the agent actually extend my arms? Is it performing, under my control, an action that I already know how to do but cannot do comfortably at that moment? It is on this ground that OpenClaw began to gain its place in my home.

My real use case: a code agent in Telegram

The idea came to me after a very banal incident - the kind that always happens when you're not in front of your computer. A display error had multiplied the prices of a service. Two minutes at the keyboard would have been enough. From my phone, I wanted to modify the large component in the monorepo, I broke the deployment and I had to go back to put the service back up.

I was on leave, on the slopes, when a developer sent me the screenshot. Access to this project was then only configured for me. I opened the Git interface from the phone, tried to divide the faulty values ​​and above all succeeded in dropping the entire provider, stored in the same monorepo. I triggered the rollback, the team was able to resume their work, and I found myself with this annoying thought: in front of my computer, the correction and deployment would have taken two or three minutes.

So I built my “lifeboat”: a development agent reachable in a dedicated Telegram topic. It does not have the right to deploy and never directly touches the main branch. Its workspace contains a clone of the project. It creates a branch, modifies the code, runs the checks, pushes the branch and opens a merge request. Then, I take control again: I read the diff, I test and I decide on the merge.

The word “lifeboat” is intentional. This is not my primary development environment. In front of my computer, the IDE and my usual code assistant remain faster, more comfortable and above all more transparent. I want this agent for those times when I'm on the go, when a simple correction becomes painful from a phone, and when waiting several hours isn't reasonable.

In my configuration, the general assistant and the code agent are separated. The first uses the general model by default. The second is related only to the project topic and uses a code-oriented model. Telegram bindings determine which account, group, and topic activates which agent. Unknown private messages are refused, the agent must be mentioned in ordinary groups and it automatically replies only in its work topic.

At first, I wrote to it in the new group: “Are you there? ping.” Complete silence. In private, however, the agent assured me that everything must work and offered me increasingly imaginative explanations. The reality was less intelligent: in this group it had to be mentioned, and the bot had to have the necessary rights to read the messages. As soon as I tagged it, a reaction appeared and the conversation began.

This separation seems administrative, but it prevents the whole context from getting mixed up. A reminder conversation does not need monorepo rules. A code task doesn't need the memory of my general assistant. Routing by account, group and topic allows me to choose the model and workspace before the message is even processed.

The configuration principle, stripped of my identifiers, looks like this:

{
  "agents": {
    "default": { "workspace": "/srv/openclaw/general", "model": "general" },
    "provider-code": { "workspace": "/srv/openclaw/provider", "model": "coding" }
  },
  "bindings": [
    {
      "channel": "telegram",
      "chatId": "<groupe-code>",
      "topicId": "<sujet-projet>",
      "agent": "provider-code"
    }
  ]
}

This is not a ready-to-copy file: exact names depend on version and installation. It shows the logic that matters. The Telegram account arrives in a group, the group contains a topic, and this topic points to a specific agent, a specific model and a specific workspace. The routing is decided before the model begins to improvise.

I also host several agents on the same server. Each one has its own identity, workspace and connections. Creating one VM per agent would be unnecessarily expensive, but sharing the process does not mean sharing all permissions. The key point is to be able to say: this Telegram topic is talking to this agent, with this model, in this repository, and nowhere else.

In my real file, the main bot remains the default for general conversations. The project topic has a more specific binding to the code agent. I retrieved the topic ID by asking the system where the current message was, then inserted it manually into the JSON. I had prepared a cleaned copy of the file for the demonstration: displaying a security example with the real tokens on screen would have been a pretty bad joke.

The repository also contains a rules file: monorepo architecture, test commands, conventions, mandatory creation of a branch and an MR, prohibition of deployment. For a complex task, I first ask for a text plan. The GitLab token is dedicated and revocable; the SSH key belongs to this environment, not my main account.

I created a separate GitLab account for it, a dedicated address, its own SSH key and a limited access token. The agent generated its key and installed the token in its environment, but it was me who decided the rights. Its rules file instructs it to branch, push, and open an MR. For complex requests, it must file a plan before writing the code so that I can verify that it understood the correct problem.

I started with a deliberately ridiculous test: replacing one version number with another. The agent modified the file, created the branch and opened the MR. I read the diff, merged, then checked for autodeploy. It was only after this dress rehearsal that I gave it the two new pages. An agent does not deserve the rights to a major project because it managed to write a nice sentence in Telegram.

This first test proved almost nothing about its ability to code. It proved something more important to me: the whole chain worked. The message reached the right agent, the repository was the right one, the branch appeared, the MR was visible and the pipeline ran only after my merge. Before asking for intelligence, I wanted to check the plumbing.

What worked

I asked it to create an offer page and a temporary privacy page modeled on an existing terms page. Two minutes later, the MR contained the two routes, the temporary texts and even the theme selector consistent with the rest of the site. I then left a comment asking to remove a "draft" block: the agent read the comment, modified the branch and updated the MR.

In Telegram, the “typing…” indicator appeared while working. Under the hood, it would read the comment, find the branch, modify the file and push the new revision. When the response came, I checked the diff instead of taking its "done" as proof. The merge button remained under my finger, not its.

This last round trip counts more than the initial generation. A first version of code is easy to show in a demo. Reading a review comment, finding the right branch, applying a limited change then refreshing the MR already sounds like a real piece of workflow. I could track the result in GitLab instead of believing the “done” message.

This is exactly the level of autonomy I am looking for. When I'm in front of my IDE, my usual coding tool remains faster and more transparent. OpenClaw gets interesting when I'm outside, can explain the fix in a voice message, and have the change waiting for me in the form of a checkable diff.

I emphasize this point because it completely changes the promise. I'm not going to sit in front of my seven screens and dictate code in Telegram. At my desk, I open the IDE, see the files, and control the loop much faster. This agent is a lifeboat for when I'm in a car, on a train, or away from my post — not the theatrical replacement for my everyday environment.

What didn’t work the first time

The “automatic” configuration quickly lost its magical side. In a new group, the agent remained perfectly silent while assuring me that everything should work. The cause was quite stupid: it had to be mentioned and given the right to read the messages. I ended up correcting the JSON myself. Letting a model uncontrolled rewrite its own startup file seemed like a pretty bad way to end the evening.

The actual getting started required several steps: creating the group and its topics, retrieving the identifiers, declaring the bindings, associating the project topic with the code agent, setting up the mentions, preparing the workspace, installing the SSH key and providing a limited GitLab token. OpenClaw helped me with some of this work, but it didn't turn it into a single button.

In ordinary groups, I require explicit mention. Without a mention, it listens but doesn't respond. In the subject reserved for the code, the mention is not necessary: ​​all messages are intended for it. Private messages from unknown identities are refused. These are small tweaks, but they are what makes the difference between a useful assistant and a bot that intervenes everywhere.

This detail sums up OpenClaw well: it can make a convincing code change, then hallucinate about its own configuration. Intelligence is not uniform. So I check the permissions, the modified files and the actual result, not just the reassuring response from the bot.

Voice messages: the extension that is changing mobile usage

I wanted to talk to the agent rather than typing specifications on my phone. OpenClaw can review available resources and offer Whisper locally. My little VM wasn't suited to this transcription, so I provided it with documentation from our existing transcription service.

In our infrastructure, this service is not a simple direct call to a model. We have an internal gateway for several AI functions: transcription, LLM and image generation. For voice, it first tries an internal resource, switches to another engine if this fails, then only to a paid service. Some processing is asynchronous: you create a task, wait, then retrieve the result. We had to explain all this plumbing without letting OpenClaw invent half of it.

The agent asked a few questions, added a hook and changed its configuration. Now, a Telegram voice message goes through the transcriber first; the text returns to the normal loop and becomes an instruction like any other. Changes remain versioned, allowing me to precisely control which hooks are added.

Our transcriber works asynchronously: it receives the media, creates a task, waits for the result and then returns the text. Instead of explaining this protocol orally to the agent, I asked my code assistant to produce detailed integration documentation from an existing project. I gave this document to OpenClaw, answered its questions, then let it prepare the connection.

I already had a small internal bot that used this gateway: we sent it a voice message, it transcribed it and slightly put the ideas in order. I gave the code of this bot to my development assistant with very specific instructions: write an integration document, describe authentication, token format, task creation, waiting for the result and error cases. This Markdown file has become the contract between our service and OpenClaw.

The final pipeline is easy to read: a message arrives from Telegram; if it contains a voice message, the hook sends it to the transcription service; the resulting text replaces the media in the normal loop. From there, the agent treats my voice like any written instruction. This is exactly the kind of extension that justifies the project: it concretely changes my use when I'm away from the office.

I could watch the requests come in, the transcription job complete, and then the text came back into OpenClaw. So the result wasn’t just “the bot claims it understands speech.” I saw the actual journey. And since the OpenClaw configuration is versioned, I was able to read the added hook and the rule that inserts it into the pipeline before normal message processing.

Not everything remained perfect. The day before recording, I was still experimenting with the hooks and I temporarily broke voice-message processing. It's almost an ideal demonstration of the product: very powerful, really practical, and modifiable enough that I can render it unusable myself before going to sleep.

This was the best example of its ability to expand: I didn't write the integration by hand, but I didn't give blind permission either. I provided a documented interface, a limited token, and a version-controlled repository.

Second practical use: prepare my publications without losing my voice

I have been writing for my channel for a long time. I exported my old posts in JSON, then asked a model to extract a detailed style guide: rhythm, turns of phrase, structure, transitions and defects to avoid. I placed this guide in an agent's editorial-only prompt.

There was a time when I was posting almost every day. Then the cost of the first draft — opening the page, putting the ideas in order, finding the angle — ended up slowing the pace. It is this very ordinary problem that I wanted to solve. Not create a machine that would have my opinions for me, but shorten the path between an idea recorded while walking and a draft that I want to correct.

Export matters a lot. I didn't ask it to imitate three publications chosen because I liked them. I gave it years of texts, with my habits, my repetitions and my faults. The model transformed this material into usable instructions. Only then did I create a separate topic for the writing, just as I did for the code.

I don’t just tell it “write about OpenClaw.” I send it a draft, key points or a long voice message. It produces a structure and a first version close to my tone. I then go back to the text, replace certain passages and decide on my own to publish.

For the demonstration, I could have asked it a vague “write a post on the dangers of OpenClaw”. In real life, that's not how I work. I give it fragments, objections, an anecdote and sometimes a still confused conclusion. it mainly does the editing work. If I provide no facts, no position, no rough edges, it gives me exactly what I deserve: a smooth text that anyone could have signed.

I am not claiming that it writes for me. It makes the blank page disappear and gives me a good enough skeleton to start with. Afterwards, I cut, I rewrite and I put in my own rough edges. Content, judgment and responsibility remain with me; the machine mainly saves me the painful first hour.

The gain was seen immediately: I started producing drafts regularly again. It is not because the agent has become an author. That's because the most costly moment for me — turning a bunch of notes into a structure — became shorter. Then I can focus my energy on what the agent doesn't have: my experience, my level of doubt, and the decision to publicly own each sentence.

The flow that works best isn't "give me a topic." I send it my ideas out of order, sometimes in the form of bullet points, sometimes in a long voice message recorded while walking. It puts the elements in a readable order and suggests a text. The more my draft contains personal opinion and examples, the less the result resembles a generic soup.

“It learns on its own” deserves an asterisk

OpenClaw can install components, modify its files and enrich its skills. To say that it “learns on its own” is nevertheless a shortcut. It does not spontaneously become wiser. It applies a request with the tools and model to which I gave it access. A bad instruction or a bad model simply produces a new error in a now more complex system.

Recent versions have tightened the default behavior. To obtain the most permissive profile, you must activate it voluntarily in the configuration. I find this brake healthy. A new installation should start by discussing and observing, not by immediately having the terminal, the browser, the secrets and all the files.

In other words, the shortcut “it makes itself smarter” mixes several things. It can read documentation, install a package, create a skill, add a hook or modify a prompt. This is a very powerful expansion ability. But its judgment continues to depend on the model, the context and the permissions. Adding a new key to a toolbox does not guarantee that the user will know how to choose the correct lock.

My rule is progressive: first a channel, then an empty workspace, then a test repository, then a limited key, and only finally a useful workflow. At each step, I look at the logs and modified files. Autonomy is not a switch I turn on; This is a scope that I am expanding after seeing the actual behavior.

Maybe it's my professional bias: I don't like it when a software, a service provider or even a person has complete control over my devices. I do not intend to impose this point of view. I only say, with all necessary modesty, that it is absolutely correct and that the others are false. More seriously: if you choose another risk policy, at least choose it with full knowledge of the facts.

The desire to automate everything is a trap

OpenClaw causes a very recognizable syndrome: as soon as it works, you want to plug it in everywhere. It reminds me of the day I got my license: I wanted to drive even to the store across the street. It was more expensive, sometimes slower and objectively absurd, but I wanted to drive.

On foot, the journey was free, probably faster after accounting for parking, and even better for my health. By car, I spent fuel, looked for a place and added a new opportunity to bump into something. Yet I took the car, simply because I finally had the right and the desire to use it. OpenClaw enthusiasm produces exactly that technical itch.

For many tasks, OpenClaw is exactly that car. We could walk — or, here, write a few lines of script, set a webhook, launch a scheduled function. It would be less fun, but simpler, more predictable and cheaper. I keep the agent for requests that change, are better described in natural language, and require multiple tools to work together.

What I took away after two weeks

After two weeks, OpenClaw has not replaced my team or my work. On the other hand, it turns a voice message into an MR, insists when I ignore a reminder, assembles the first draft of a text and connects a documented tool to a discussion channel. This is not a daily revolution. It's already helpful enough for me to continue talking to it.

I will continue to use it and add capabilities to it. But each new capability will need to answer three questions: Is it really more effective than a script? How much could it cost in the worst case? What is the maximum damage if the model is wrong?

I'll probably continue to break hooks, compare models, and find new uses. The difference is that I'm no longer looking for a demonstration in which OpenClaw seems all-powerful. I'm looking for somewhat boring automations that hold up to a real work week. My two current successes — the code lifeboat and the writing assistant — are precisely of this kind.

So I’m no longer looking for “an agent who can do everything.” I prefer several small agents, each with its own model, topic, repository and permissions, with human validation where a mistake hurts. It’s less magical, much less salesy — and, in my eyes, much more serious.

Technical references

• OpenClaw: definition and general architecture
• OpenClaw: installation and getting started
• OpenClaw: security model and audit
• OpenClaw: running tools in a sandbox
• OpenClaw: automations, cron and heartbeat
• OpenClaw: official repository

Read next

• How I configured Pi as a coding agent: LSP, MCP, skills and extensions AI and development · 34 min
• Connecting Synology AI to a local LLM with Ollama or LM Studio Synology, AI and self-hosting · 12 min
• UmbrelOS for a home server on a mini PC Home server and self-hosting · 8 min

About the author

Jeremy Kraft runs the infrastructure and the self-hosted services of the IBCSC. These guides describe configurations that were actually deployed and re-checked before publication.

Ask a question All guides

Discussion

Comments

0

No comment yet. Feel free to open the discussion with a question or your own experience.

Website

Your name Have an account? Sign in

Your comment

Plain text, 2 000 characters maximum. New comments are moderated. Your name is shown with the comment. No e-mail address is asked; only a non-reversible fingerprint of your IP address is kept to fight spam.

Send the comment