5 minutes to cross the skill gap between openclaw pros and beginners

the strongest features of openclaw are the ones you never see in a conversation. a few months ago i opened it for the first time and thought it was just a better claude. chat, ask questions, get it to write some code. worked fine. i figured i had it down.

then i watched a friend who does AI infra demo his setup. he opened a terminal, ran a few commands, had three agents running in parallel, telegram pushing results in real time, and he wasn't even sitting at the keyboard. i asked what advanced features he was using. he said they're all basic features, you just haven't touched them.

i didn't believe him at first. went back and tried it myself. got humbled by the third one.

this article is what i pieced together over the next few months. the goal is simple: help you cross the line between someone who uses openclaw and someone who actually runs it.

flip 1: you think it's a chatbot

it's closer to a gateway-driven task system.

a chatbot is ask-and-answer. close the browser, it's gone. openclaw's gateway is a persistent process that handles message routing, sessions, tool calls, and agent lifecycle.

you send a message from telegram, gateway picks it up, routes it to the right agent, agent finishes, result gets pushed back. you don't need to sit at a terminal the whole time.

while the gateway is running, your agent is alive. you can walk away. the gateway is the source of truth for sessions. after a restart, chat history and session state are usually still there. but a task that was mid-run won't seamlessly resume, and some pending results might need to be re-sent.

what this means for you: you're dispatching a system that works on its own and reports back. no need to stare at a chat window.

flip 2: you think it only lives in the terminal

i'm putting this one early because it's the real aha moment for a lot of people.

the terminal is just one way in. most of my time now is spent using openclaw through telegram. send messages, receive results, approve tasks, check output. phone is enough.

openclaw supports telegram, discord, signal, plus a web dashboard and control UI. the experience differs slightly across surfaces, but the most common control actions work fine from a chat window.

for example:

! ls -la runs a shell command directly !poll checks background task status !stop kills a running task

these run via host bash. the prerequisite is that your channel and agent have the corresponding command capabilities enabled. once that's set up, a lot of daily work can move from terminal to phone.

if you've been avoiding openclaw because you didn't want to open a terminal, start with telegram. it's the lowest barrier entry point.

flip 3: you think context manages itself

i thought so too. after a while, my agent started getting dumber. repeating itself. forgetting things i'd said ten minutes ago. i assumed the model was the problem.

had nothing to do with the model. working memory was full.

every model has a context window, basically how much it can hold in its head at once. your messages, files the agent reads, tool output, all of it piles up. once it's full, things start getting dropped.

what experienced users actually rely on is a set of commands:

/compact

compresses the conversation history into a summary, freeing up space. the model rewrites a shorter version of what happened, keeping the important parts, dropping the noise. you can even steer it:

/compact focus on the API design decisions, ignore the debugging session

the system also auto-compacts when you approach the limit, but manual control lets you decide what to keep and when to clean.

one caveat: compact doesn't only trim fluff. it can also lose technical details. important configs, commands, error messages, better to write those to a file or memory before compacting.

/context list

shows every file currently injected into context and how much space each one takes. first time i ran this, i realized half my context wasn't conversation at all. it was injected files and tool definitions.

/context detail

goes deeper. shows the size of top tool schemas. most people have no idea that tool definitions themselves are eating tokens.

/new

starts a completely fresh conversation. don't try to keep compacting forever. past 85% and still clinging to the same session, things will probably get messier.

my routine now: check /context list first. over 70%, run /compact. over 85%, just /new.

if you only take one section from this article, take this one. most people who think their agent gets dumber over time aren't dealing with a model problem. they're dealing with unmanaged context.

flip 4: you think CLAUDE.md is enough

if you've used claude code, you know CLAUDE.md. one file for everything.

openclaw takes a different approach. it splits the agent's long-term configuration into a set of workspace files. default workspace is usually at ~/.openclaw/workspace

these files get injected into context on every agent run, every turn of conversation. large files get truncated at a default cap of 20,000 characters per file.

the key ones:

AGENTS.md operating instructions. the agent reads this every time it wakes up. workflow, tool rules, priorities. think of it as the work contract you sign with your agent.

SOUL.md personality and tone. directly shapes how the agent talks. my X manager's SOUL.md says: answer first, explain second, have opinions, don't hedge. the difference is immediate.

USER.md who you are, what you're working on, your timezone, communication preferences. the agent stops having to guess every session.

TOOLS.md usage notes and gotchas for tools. more like operational reminders for the agent. hard permission controls go through tool policy, approvals, and sandbox.

IDENTITY.md name, emoji, identity.

MEMORY.md long-term memory, persisted across conversations.

memory/YYYY-MM-DD.md daily logs. what happened, what was discovered. note: daily memory files aren't auto-injected into context by default. the agent typically reads them on demand through the memory tool, so they don't eat startup tokens.

the real strength here is separation of concerns.

CLAUDE.md reads like one big master document. openclaw's workspace files are more like shaping a long-term collaborator. you hired an assistant but never told them who you are, what you're working on, or how you want them to talk. of course they'll drift.

where to start if you're new: don't try to fill everything at once. write SOUL.md and USER.md first. 3-5 sentences for tone in SOUL.md, a short paragraph about yourself in USER.md. thirty minutes to an hour, enough to get a first version running.

flip 5: you think permissions are a single switch

until i upgraded to 3.31 and got humbled.

after the upgrade, exec commands started popping approval prompts. i changed tools.exec.security to full in the agent config. still popping.

turns out i'd only changed one side. the defaults in ~/.openclaw/exec-approvals.json were still on the old values.

the part that trips people up is the layers.

layer 1: authentication

pairing is device authentication. a node has to pair before it can connect to the gateway. it controls who gets in, not what they can run.

layer 2: execution permissions

two orthogonal dimensions:

security controls which commands can run: deny / allowlist / full ask controls whether to confirm before running: off / on-miss / always

they operate independently and combine into the final behavior.

examples: security=allowlist + ask=on-miss = allowlisted commands run directly, everything else pauses for approval security=full + ask=always = anything can run, but it asks every time

this policy can be written in two places: agent config and exec-approvals.json defaults.

when the same field appears in both, the stricter value wins. this comparison is field-by-field, not between the security and ask dimensions themselves.

my mistake was changing agent config but leaving the approvals file untouched. the behavior followed the more conservative side.

one more thing that's easy to miss: exec approvals take effect on the execution host. running on the gateway host means gateway-side approvals apply. running on a node means the node's local approvals apply.

layer 3: isolation

sandbox isolates the execution environment. off by default. when enabled, the agent no longer runs directly in your host workspace.

sandbox isolation mainly covers tool execution. the gateway process itself still runs on the host. elevated host execution can bypass the sandbox, so keep that in mind. simple way to think about it: sandbox controls what the agent can touch once it's running.

note for newcomers: you don't need to configure all of this on day one. just remember: if approval behavior suddenly changes after an upgrade, come back to this section.

flip 6: you think one agent is enough and automation means writing your own scheduler

i'm combining these because they point to the same thing: openclaw can grow structure.

multi-agent

i used to throw everything at one agent. drafting posts, checking data, replying to messages, managing files. all one session.

the most ridiculous moment was when i asked it to draft a tweet and got a debugging log spliced into the middle. context was tangled. roles were tangled.

i split things up: one agent for content ideas and material, one for code tasks, one for external messages. each agent has its own workspace and session store.

what this gives you is state isolation. important distinction: state isolation and process-level fault isolation are different things. one session going sideways won't automatically contaminate another session's context. but the gateway is still the coordination center. don't think of it as a naturally fault-tolerant multi-process system.

if you want to try it, the simplest starting point:

openclaw agents add work

add a new agent, carve out one category of tasks, try it for a day.

hooks

automation doesn't have to mean writing cron jobs.

openclaw has event-triggered hooks. something happens, the corresponding logic runs. the most useful built-in ones:

session-memory: automatically writes key information to memory when a session ends command-logger: records every command the agent executes boot-md: runs initialization tasks from BOOT.md when the gateway starts

i have a hook that writes drafts to a specific directory and updates memory every time a content task finishes. i don't remind it. event fires, logic runs.

the difference from saying "please remember to do this" in a conversation: the trigger lives at the gateway event layer, independent of whether the current conversation context survived.

that said, it's not bulletproof. disk full, permission issues, gateway itself going down, all of these affect it. it's just significantly more reliable than a casual reminder in chat.

if you're new: just know this exists. you don't need to set it up today.

flip 7: skills + clawhub

this is the one i discovered last, and i wish i'd found it sooner.

skills are packaged capability modules. a skill directory typically contains:

SKILL.md tells the agent when to read it and how to use it scripts/ for execution scripts references/ for reference material

the priority order matters:

/skills (highest) → ~/.openclaw/skills → bundled → extraDirs (lowest)

a same-named skill in your workspace overrides the system built-in.

my own example: x-writer. it packages tone rules, banned words, structure guidelines for writing tweets. every time the agent needs to draft X content, it reads this skill first, then writes. i don't repeat the rules every conversation.

if you don't want to build your own, clawhub is the public skills registry. think of it as an early-stage skill marketplace. nowhere near app store scale yet, but there are already useful packs available.

openclaw already has many typed tools as core capabilities. skills are more about packaging methods, rules, and calling patterns so the agent knows when and how to use them.

the real value of this section isn't installing a skill. it's realizing that things you keep repeating in conversations should have been a skill all along.

where are you: 5-question self-test

do you know what /compact does? no → still on the surface yes but never used it → just touched the door used it with a custom instruction → you're in
how many words are in your SOUL.md? what's SOUL.md → surface it exists but only a few lines → just starting 300+ words with specific tone rules → you're in
do you know the difference between security and ask? no → surface one controls scope, one controls confirmation → system layer know they stack with multiple config locations → system layer
have you run multiple agents working at the same time? no → not there yet tried but unstable → on the way stable multi-agent setup → ecosystem layer
have you written or modified a skill? no → not there yet used someone else's skill → on the way written your own, know the priority rules → ecosystem layer

cheat sheet

what you assumed → what it actually is

| what you assumed            | what it actually is                      |
| --------------------------- | ---------------------------------------- |
| chatbot                     | gateway-driven task system               |
| terminal only               | telegram / discord / signal / dashboard  |
| context manages itself      | /compact + /context + /new               |
| CLAUDE.md one file          | workspace files, separation of concerns  |
| permissions are a switch    | authentication + permissions + isolation |
| one agent does everything   | multi-agent state isolation + routing    |
| automation means schedulers | hooks, event-triggered                   |
| capabilities from scratch   | skills: package, reuse, override         |

common commands:

| command                              | what it does              |
| ------------------------------------ | ------------------------- |
| /compact                             | compress context          |
| /compact focus on [topic]            | compress with direction   |
| /context list                        | check injected file sizes |
| /context detail                      | check tool schema sizes   |
| /new                                 | fresh conversation        |
| ! ls -la                             | run shell command         |
| !poll                                | check background task     |
| !stop / /stop                        | stop current task         |
| /usage                               | conversation usage / cost |
| openclaw status --usage              | full provider usage       |
| openclaw gateway status              | gateway status            |
| openclaw gateway restart             | gateway restart           |
| openclaw agents add <name>           | add new agent             |
| openclaw hooks list                  | list hooks                |
| openclaw hooks enable session-memory | enable memory hook        |

first step for newcomers: set up telegram, spend 30 minutes writing SOUL.md and USER.md. then send /context list to your agent and see what it's actually carrying into every conversation.

closing

every one of these flips, i learned the hard way.

the most expensive lesson was the permission system. spent half a day after the 3.31 upgrade figuring out why my config changes weren't taking effect. turned out i'd only updated agent config and left the approvals file untouched. the best surprise was skills, because i finally realized that the things i kept repeating in every conversation were never supposed to stay in conversations.

the gap between someone who gets it and someone who doesn't isn't about knowing fancy features.

it's about when you start moving rules out of chat and into the system.

want to see these agents at work? i write about building with AI agents, share real setups, and ship products on top of them at Voxyz AI.