OpenClawの解剖：エージェント設計を変えるガイド

I cut my token spend by 3x and in 4 hours built a bot that makes me $300/day - simply because I figured out how OpenClaw actually works inside. Most people use it blind. They install skills, write prompts, tweak settings - but have no idea what's happening under the hood. A black box. Even though it's completely transparent. Did you know OpenClaw has two types of memory - bootstrap and semantic search? If not - you're only using your agent at half capacity. Or that you can control your agent from a plain text editor and get results 95% better than most people. Or that if you're running your agent "out of the box", you're spending 3x more tokens (= money) than you need to? I'm going to tell you a lot of interesting things about OpenClaw. Bookmark this article right now so you don't lose it! OpenClaw is built from six parts. Each one works independently, but together they form a full-fledged agent. Gateway - the core of the system. Everything goes through it. It maintains persistent connections to Telegram, WhatsApp, Discord, Slack. When a message comes in - Gateway decides which agent gets it, pulls up the history, assembles context and sends it to the LLM. The response flies back the same way. On top of that it spins up a WebSocket API so you can plug in your own interface or external integration. Agent - the brain. Receives assembled context from Gateway: chat history, memory files, available tools. Thinks, decides which tool to call, builds a response. If needed - kicks off a chain: called a tool, got a result, thought some more, called another one. Keeps going until the final answer is ready. Tools - the agent's hands. exec runs shell commands on your server. browser opens pages, clicks, takes screenshots. file reads and writes files. message sends messages to channels. memory searches through long-term notes. Each tool is a separate capability you can turn on or off. Workspace - long-term memory. A folder with files where everything the agent needs to know between sessions is written down. Who it is, what tone to use, what you like, what decisions you've made together, what happened yesterday. Without workspace the agent wakes up with a blank slate every single time. Sessions - memory of a single conversation. Full history of a specific dialogue: what you wrote, what it replied, which tools it called. Each session lives on its own and doesn't bleed into others (unless you messed up the settings — more on that at the end). Nodes - physical devices. Your Mac, phone, remote server. They connect to Gateway and expand what the agent can do: snap a photo, take a screenshot, grab geolocation. Gateway on the server is the brain. Node on your Mac is the eyes and hands. All of this is text files. Not a database, not binaries. Plain .md and .json you open in an editor and change by hand. Where exactly everything lives — I'll show in each section below. Workspace - the superpower nobody configures Workspace is a folder with files. Sounds boring. But it's exactly what separates a dumb bot from an agent you can actually work with. Without workspace the agent wakes up with a blank head every time. Doesn't remember who you are. Doesn't remember what you discussed last week. Doesn't remember decisions you made together. Every conversation starts from zero. And every time you're spending tokens just to re-explain context. Workspace is a set of .md files, each with its own role: AGENTS.md - the operating manual. This is where you write how the agent should think. When to use which tool, what safety rules to follow, what order to do things in. Its playbook. SOUL.md - personality. Tone, boundaries, priorities. Want the agent to be brief and not throw unsolicited advice - put it here. Want a friendly assistant - also here. USER.md - your profile. How to address you, what you do, what you prefer. The agent reads this before every single response. MEMORY.md - long-term memory. Facts that must not get lost. "We only trade on DEX, no CEX." "Primary RPC is Alchemy, Infura as backup." "Built an arb bot on Polymarket on 15-min market." The agent writes here on its own or when you tell it to. YYYY-MM-DD.md - daily logs. What happened today, what tasks are in progress, what you discussed. Tomorrow the agent opens yesterday's log and picks up the context. IDENTITY.md - name and vibe. "My name is Clawdia, I'm your automation assistant." A short file, but it sets the tone for everything. HEARTBEAT.md - checklist for periodic checks. "Check email", "see if monitoring is running." More on this in the automation section. TOOLS.md - hints about local tools. Where scripts live, which commands are available, shortcuts. So the agent doesn't guess it knows. Now about the two levels of memory - and why most people only use one. 0:00 / 0:08 Every time it runs, Gateway takes AGENTS.md, SOUL.md, USER.md, IDENTITY.md, today's daily log and injects them into context before the LLM even sees your message. This is bootstrap - the first level of memory. The agent "remembers" the contents of these files every single time. The second level is semantic search. If the memory plugin is enabled, the agent can search through MEMORY.md and other notes via a vector index. You ask "which DEX do we trade on?" - it finds the right chunk even if you wrote it two months ago. Not by keywords but by meaning. You wrote "we only trade on DEX" - the agent finds it when you ask "where do we open positions." The difference: bootstrap is what the agent sees every time, no exceptions. But the files eat tokens. The more you stuff into AGENTS.md and USER.md, the more expensive each request gets. Semantic search is the opposite - doesn't consume context constantly, only pulls in what's relevant right now. But it doesn't guarantee the right fact will be found. The strategy is straightforward. Put the critical stuff in bootstrap - what the agent needs to remember in every message. Tone, rules, who you are. Everything else goes into MEMORY.md and daily logs: decisions, facts, task context. Semantic search will pull them when needed. If only bootstrap is configured - the agent runs at half power. If neither is configured - you're just burning money on tokens every day. Example. You tell the agent: "Remember that I only trade on DEX and I watch pools on Curve." It writes this to MEMORY.md. A week later you ask: "Where do we usually check liquidity?" The agent searches its memory and answers without extra questions. You didn't spend tokens re-explaining. It just knows. Gateway - how a message becomes a response Gateway is the thing everything goes through. Every message, every response, every tool call. If the agent is the brain, Gateway is the circulatory system. It stops - everything dies. It's a long-running daemon process. You start it once - it sits there and works. Maintains persistent connections to channels, waits for messages, processes them, returns responses. No restarts, no manual intervention. Here's what happens when you message your bot on Telegram: Step 1. Gateway maintains a persistent connection to the Telegram API. An event comes in a new message from you. Step 2. Gateway checks the config: which agent should handle this message? Bindings are defined there - channel -> agent mappings. It also determines the SessionId: is this a continuation of an old conversation or a new session. Step 3. Gateway assembles context. Reads the session history from the .jsonl file. Pulls in bootstrap files from workspace: AGENTS.md, SOUL.md, USER.md, everything else. Adds available skills. Packs it all together and sends it to the LLM. Step 4. The LLM returns either text or a tool call. If it's a tool call - Gateway executes it: runs a command, opens a browser, writes a file and feeds the result back into context. The LLM looks at the result, thinks further. Might call another tool. And another. The loop keeps spinning until a final answer appears. Step 5. The response streams back to Telegram. You see "typing..." in real time. Meanwhile the entire exchange - your message, the agent's response, all tool calls - gets written to .jsonl. sessions.json gets updated. Gateway spins up a WebSocket API on port 18789. Through it you can plug in your own UI - a web interface, a mobile app. Or integrate with external systems via HTTP. There's even an OpenAI-compatible endpoint - you can hook up any tool that speaks the OpenAI API. By default Gateway only listens on localhost. Meaning — no one can reach it from another machine. For remote access there are two solid options: VPN via Tailscale (you bridge Gateway into your private network) or an SSH tunnel (ssh -L 18789:127.0.0.1:18789 user@server). Exposing 18789 to the open internet is a bad idea. That's full access to all your data, sessions, and agents. Tools + Cron — the agent that works without you Tools are how the agent interacts with the outside world. Without them it can only talk. With them - it acts. exec - the most powerful tool. Runs shell commands. Through it the agent can do practically anything: run a script, install a package, process a file, deploy code. But also the most dangerous. Three exec modes - from safe to risky: sandbox - the agent works inside a Docker container. A separate sandbox with no connection to your server. If something breaks - no big deal, your main system is untouched. gateway - the agent works directly on your server, but with restrictions. You decide which commands it can use. Put git and python in the whitelist it uses those. Everything else is blocked. full - no restrictions. The agent does whatever it wants on your server. Fine for experimenting, but on a live server with money on it - that's like leaving the door wide open. browser - controls a browser. The agent can open a page, click an element, type text, take a screenshot, save a PDF. Two profiles to choose from: openclaw (fully isolated, managed) and chrome (controls your regular Chrome via an extension, needs an open tab). file - reads and writes files. message —-sends messages to channels. memory - searches through long-term notes. Now the part that changes everything - cron and heartbeat. This is what turns an agent from a chatbot into a worker. Cron is a task scheduler on the Gateway side. You set up a schedule once and forget about it: openclaw cron add --schedule "0 9 * * *" --agent personal --prompt "Check new emails, send summary to Telegram" --announce Every morning at 9:00 the agent wakes up, does what you asked, and sends the result to the channel. Without you lifting a finger. The --announce flag means the result gets delivered to the channel. If you need quiet execution - use --no-deliver, the agent does everything internally. Heartbeat is similar but shorter. A periodic check based on the checklist in HEARTBEAT.md. Gateway asks the agent to go through the items: is monitoring running, is there disk space left, are there errors in the logs. If something's wrong - the agent messages you. An example that ties it all together. You want the agent to check Gmail every morning and send a summary to Telegram. You enable browser tool, set up a cron for 9:00, write an instruction in AGENTS.md: "Open gmail.com, use snapshot() for the email list, filter by relevant senders, compose a summary and send via message tool." Every morning the agent opens a browser with a saved session, reads the inbox, filters, sends you: "3 emails from clients today: X wants an update, Y asks about payment, Z confirmed the meeting." You haven't finished your coffee - and it's already sorted everything out. Multi-agent - one Gateway, an army of agents Up until now we've been talking about a single agent. But Gateway can serve as many agents as you want. Imagine: you have a work agent that handles project tasks. And a personal one for everyday stuff, notes, reminders. Both live on the same Gateway, but each in its own world. How it works. Each agent is a separate folder in ~/.openclaw/agents/. Its own workspace, its own sessions, its own memory files. The work agent knows about your stack, your project, your team. The personal one knows about your habits, schedule, preferences. They don't cross paths. Channel mapping is done through bindings in config.json. You write to one Telegram chat - it goes to the work agent. Write to another to the personal one. Same Gateway, routing by rules. Isolation between agents is handled by dmScope. Set it to "per-agent" and each agent only sees its own dialogues. The work agent doesn't know what you asked the personal one. The personal agent doesn't know about your work tasks. Clean separation. You can take it further. A monitoring agent that checks your servers via heartbeat and messages you if something goes down. A research agent that uses browser tool to parse sources and saves summaries to its own MEMORY.md. A trading agent that watches pools and pings you when it spots an opportunity. Each one has its own workspace with its own instructions, its own memory, its own set of skills. But they all sit on the same Gateway, use the same channels, and are managed from a single config.json. The main rule: if more than one person has access to an agent, you must set dmScope: "per-channel-peer". Without it, sessions from different users collapse into one. The agent can respond to one person with information from another. This isn't a bug - it's the default behavior that you need to change manually. 5 mistakes that break your agent You've gone through the entire architecture. Now a checklist - check yours rn. Mistake 1: dmScope is set to "main" with multiple users. OpenClaw's default behavior - all direct messages in one channel get dumped into a single session. If two different people message you on Telegram, the agent sees both conversations as one. It can respond to one person with context from the other's conversation. Not a bug - a feature nobody bothered to change. Fix: set dmScope: "per-channel-peer" in the config. Each user gets an isolated session. Mistake 2: exec tool is set to full mode. You've given the LLM full shell access to your server. No whitelist, no restrictions. The agent can delete files, install anything, read any data. For experimenting on localhost - fine. On a live server a disaster. Fix: switch to sandbox or gateway with a proper exec-approvals.json. Mistake 3: no workspace or it's empty. An agent without workspace is an LLM without context. Every conversation starts from a blank slate. You explain who you are, what you do, how to communicate - every single time. Every time you spend tokens on the same thing. Fix: at minimum set up AGENTS.md + SOUL.md + USER.md. That's 15 minutes of work that pays for itself from the first conversation. Mistake 4: no compaction strategy. Long dialogues grow into thousands of tokens. OpenClaw can compress old messages into a summary, but if the agent didn't write the important stuff to MEMORY.md before compression - it's gone. The agent forgets decisions you made three days ago. Fix: enable memory flush before compaction the agent automatically dumps important facts into long-term memory. Mistake 5: port 18789 is exposed to the internet. Gateway API listens on localhost by default. But if you forwarded the port for remote access and forgot to lock it down - that's full access to all agents, sessions, data. Anyone who finds that port can read conversations, send commands, modify workspace. Fix: Tailscale or SSH tunnel. Never expose 18789 directly. OpenClaw is not a black box. Every component is a text file you can open and edit. Every session is JSONL you can read and parse. Every config is JSON you control Now you know how every organ of this system works. Set up your workspace, use both levels of memory, close the holes from the checklist - and your agent will operate on a different level. Was this useful? Bookmark it and drop a like - I'd appreciate it. Inspired by https://docs.google.com/document/d/1n7RqTycEABwTzUN2_HbfZZkPO7-vFUVK/edit