Many people install OpenClaw, hook it up to Discord or Telegram, find that it can chat, and figure they are done.
But after stumbling through my own share of pitfalls, I have become increasingly certain of one thing:a default OpenClaw setup may be using only 20% of its capability. The remaining 80% is hidden in configuration files you have probably overlooked — and it is not hard to change.
Below, I have laid out the five tuning steps that worked best for me, ordered from highest to lowest payoff. If you are new, following them will most likely produce an immediate, noticeable difference.
Default vs tuned: what actually changes?
Here is a side-by-side comparison to set expectations:
If you only do one thing:do steps 1 and 2 first, and the experience will improve markedly.
1) Give it a personality first: stop sounding like a call centre
In the OpenClaw workspace, I consider these three files the most important:
- SOUL.md — who it is, how it speaks, and what its working style is
- IDENTITY.md — name, persona, emoji (so it stays self-consistent)
- USER.md — who you are, what it calls you, and what your preferences are
Many people leave SOUL.md essentially empty, so the AI's replies come out very "standardised": polite but bland, like a support agent.
When I rewrote SOUL.md, I did not write an essay — just a few principles — and the effect changed immediately:
# Core principles
- Do not say "I'd be happy to help you" — just help
- Allow it to hold its own views and preferences (but do not pretend to know)
- Look it up yourself first; if you cannot find it, ask me
- Be concise: detailed when it needs to be, brief when it does not```
**Just a few lines**, and replies visibly shift from "Dear valued user" to "a normal person talking".
I also strongly suggest filling in IDENTITY.md: give it a name and an emoji.
Do not underestimate this —**an AI with a name really is more consistent across multi-turn conversations**, and will not sound like a program one moment and a support agent the next.
As for USER.md, put your own basic information in it, such as:
- Time zone (so it does not "check in on you" in the middle of the night)
- Tech stack (do not recommend a Java solution to someone writing Go)
- Communication preferences (for example, whether you want the conclusion first or the process first)
---
## 2) Build layered memory: do not turn MEMORY.md into a running log
This is the step I found**delivered the biggest improvement**.
A default OpenClaw setup has a MEMORY.md, but two writing styles commonly go wrong:
1. **Writing nothing at all**: the result is that "every time feels like a first meeting"
2. **Cramming everything in**: it ends up as one big running log that neither the AI likes reading nor you like scrolling through
My own approach is:**layered memory**. The structure looks roughly like this:
```text
MEMORY.md <- Index layer: only the most essential info + pointers to other files
memory/projects.md <- Project layer: status and to-dos for each project
memory/infra.md <- Infrastructure layer: quick reference for server config, API addresses, etc.
memory/lessons.md <- Lessons layer: pitfalls hit, graded by severity
memory/YYYY-MM-DD.md <- Log layer: what happened that day```
The key idea is a single sentence:
> **MEMORY.md is an index only; it does not pile up content.**
> When a new session starts, only the index is loaded; details are read from the relevant file when needed.
This gives you a very comfortable result:
it both "remembers" and avoids becoming "a mess of memories".
### Enable memorySearch: make memory genuinely searchable
If you want this kind of scenario:
You ask: "How did we solve that deployment problem last time?"
The AI can search semantically → locate the exact passage in a particular day's log → and recount it precisely
then I suggest enabling OpenClaw's **memorySearch (vector semantic search)**.
Reference configuration (placed in openclaw.json):
```json
"memorySearch": {
"enabled": true,
"provider": "openai",
"remote": {
"baseUrl": "your embedding API endpoint",
"apiKey": "your key"
},
"model": "BAAI/bge-m3"
}```
In my own experience:**choosing a general-purpose embedding model like bge-m3 offers excellent value**.
(The free SiliconFlow embedding API you mentioned is indeed a route you can use right from the start.)
I also suggest enabling **compaction.memoryFlush**:
when the context is nearly full, the AI writes important information into that day's log, preventing amnesia in long conversations.
---
## 3) Extend capability with Skills: from "can chat" to "can do"
OpenClaw ships with some built-in skills (weather, news, and so on), but the genuinely fun part is**custom skills**.
You can think of a skill as:
> handing the AI a standard operating procedure (SOP) so that when it encounters a certain kind of request, it follows the procedure.
A skill directory usually looks like this:
```text
skills/
my-skill/
SKILL.md <- The AI mainly reads this: trigger conditions, steps, output format
script.sh <- Optional: put scripts that need to run here
README.md <- Optional: notes for humans```
A few examples I use regularly:
- **Video download**: send a Bilibili/YouTube link → download automatically → generate a share link
- **PPT generation**: say "make a deck about XX" → produce a .pptx directly
- **Stock analysis**: ask "is stock XX worth buying" → run your analysis flow → output a conclusion plus risk points
- **News digest**: automatically gather trending topics each day → condense into a few key points
When writing skills, I have distilled one very practical principle:
> Treat the AI like a newly arrived intern.
> **The clearer you write, the more stable it is. The vaguer you write, the more it turns into guesswork.**
Nail down the trigger conditions, the steps, and the output format, and the results become far more consistent.
You also mentioned ready-made community skills (such as clawhub.com). My suggested path for beginners is:
1) Install one or two ready-made ones and start using them
2) Then codify your own high-frequency workflows into skills (for example "weekly report generation" or "log tidying")
---
## 4) Heartbeat: teach it to work proactively
OpenClaw has a heartbeat mechanism: every so often (30 minutes by default), the system pings the AI to ask whether there is anything to do.
By default, when the AI receives a heartbeat it just replies `HEARTBEAT_OK`, which amounts to doing nothing.
But you can write a **HEARTBEAT.md**, telling it what to check on each heartbeat. For example:
```md
# HEARTBEAT.md
## On every heartbeat
- Check whether service XX is online (curl it)
- If it is down, notify me, but do not restart it automatically
## Once a day
- Check for project to-dos that have not been updated in over 3 days
## Once a week
- Tidy the last 7 days of logs and distil them into long-term memory```
This way your AI acts like a 24/7 duty officer:
it inspects while you sleep, and you read the report when you wake up.
### heartbeat vs cron: which should you choose?
My own decision logic is:
- **Heartbeat**: good for lightweight "check on it while you are at it" tasks, and it can batch them
- **Cron**: good for independent tasks that need precise timing (such as sending the weekly report at 9am every Monday)
If you want to start simple: use Heartbeat for inspection and tidying first, then consider cron.
---
## 5) Tiered multi-model setup: do not make your strongest model do the simplest work
If you can connect multiple models (via an API relay, for instance), I strongly recommend a **tiered multi-model setup**. The reason is very practical: it saves money, saves tokens, and is faster.
My own breakdown follows roughly this logic:
| Tier | Model | Use |
|---|---|---|
| 🔴 Strong | Claude Opus / GPT-5 | Main conversation, complex architecture design, deep reasoning |
| 🟡 Medium | Claude Sonnet | Sub-tasks: writing code, organising information |
| 🟢 Light | Claude Haiku | Simple operations: file search, format conversion |
Configure aliases in openclaw.json (example):
```json
"models": {
"your-provider/strong-model": { "alias": "opus" },
"your-provider/medium-model": { "alias": "sonnet" },
"your-provider/light-model": { "alias": "haiku" }
}```
Then, in **AGENTS.md** spell out the routing policy:
When the AI needs to dispatch a sub-agent for a task, it will be more inclined to pick a suitable model.
The benefit I actually feel: day-to-day token consumption drops a lot, because most tasks simply do not need the strongest model.
---
## Configuration checklist: work through it in priority order
If you want the most time-efficient and effective order, I suggest:
1. ✅ Write your **SOUL.md / IDENTITY.md / USER.md** (10 minutes, immediate payoff)
2. ✅ Design the layered memory structure and enable **memorySearch** (30 minutes)
3. ✅ Configure **HEARTBEAT.md** (10 minutes)
4. ✅ Install or write the two or three skills you use most **skill** (as needed)
5. ✅ Set up tiered multi-model routing (only once you have several models)
6. ✅ Complete the **AGENTS.md** behaviour guidelines and safety rules
---
## Final thoughts: the default is only a starting point; the value lies in how you define it
As I understand it, the design philosophy of OpenClaw is:
> It gives you a framework; you define who it is.
The default configuration only counts as "working". What truly makes it useful is tuning it into a partner that fits the way you work:
it remembers context, follows procedures, and proactively inspects and reminds you.
After tinkering with it for some time, my biggest takeaway is this:
the distance between "a bot that only replies to messages" and "an assistant that genuinely saves me time" comes down to exactly these configuration details.
If you are using OpenClaw too, I would love to hear your tuning experience 👋
---
- Previous post: [(Preview) Advanced OpenClaw Skills: from "works" to "reliably useful"](https://17nas.com/openclaw-handbook-usable-to-indispensable)
> Repost author: [@xingzihai](https://github.com/xingzihai)