the OpenClaw pattern, explained
OpenClaw, also known as Clawdbot, or Moltbot depending on which part of the internet you’re from, showed something important about how autonomy should work with current models.
but the interesting part isn’t the bot itself. it’s the pattern behind it. and that pattern is very buildable.
this article is about the core concepts: what makes an agent actually autonomous, how behavior and memory work through markdown files, and why the whole thing is simpler than the ecosystem makes it look.
what did OpenClaw actually teach us?
before OpenClaw, the agent framework mindset was “add more features.” more tools, more orchestration layers, more abstractions. then OpenClaw shows up and the philosophy is embarrassingly simple:
- let agents create their own memories without limitation
- a heartbeat for things to remember
- cron jobs for automation
that’s it. the eureka moment wasn’t some new architecture. it was realizing that simplicity is better for autonomy because its nature is based on the model. you don’t need to outsmart the LLM. you need to give it the right environment and get out of the way.
so the real question becomes: what’s the minimum viable environment for an autonomous agent?
the answer: filesystem + shell + memory behaviour
if you think about it, what does an autonomous agent actually NEED?
it needs to read things. write things. run commands. and remember what happened last time. that’s the foundation. everything else — the personality, the safety rules, the workflows — those are configuration, not infrastructure.
this is exactly what Upsonic’s AutonomousAgent gives you out of the box. it's an agent class that comes pre-loaded with filesystem tools (read, write, edit, search, list, move, copy, delete), shell access (run terminal commands with timeout and output capture), and in-memory storage with full session memory enabled by default.
no configuration ceremony. no 50 lines of boilerplate. you point it at a folder and it works.
but the interesting part isn’t the tools. it’s the workspace sandboxing. every operation is restricted to the workspace directory. the agent literally cannot escape its folder. this is important because when you give an agent shell access on your machine, the security boundary isn’t optional — it’s the whole game.
who actually needs this?
let me be direct. if your use case is “answer questions from a knowledge base” or “classify these emails” — you don’t need an autonomous agent. a regular agent with some tools is fine.
autonomous agents make sense when:
the agent needs to ACT, not just respond. think devops automation, code assistants that actually write and test code, personal assistants that manage your files and run scripts. if the output of your agent is an action on a system rather than text in a chat window, you need autonomy.
the context evolves over time. if every interaction is stateless, you don’t need memory. but if you want an agent that knows what you worked on yesterday, remembers your project structure, and builds up context over weeks — that’s where autonomy starts paying off.
you want a personal assistant, not a chatbot. the difference is agency. a chatbot waits for input and produces output. a personal assistant lives in your environment, knows your stuff, and can go do things without you specifying every step.
AGENTS.md — the brain of your agent
ok here’s where it gets interesting. and this is the part most people miss when they look at OpenClaw-style agents.
how do you define WHO your agent is? how does it know WHAT to do when it wakes up? HOW does it handle memory across sessions?
the answer is a single markdown file: AGENTS.md.
you drop this file in your workspace folder and the agent reads it on every boot. it becomes part of the system prompt automatically. no python changes needed.
why markdown? because it’s agnostic. it doesn’t care which model you’re using, which framework version you’re on, or how you deploy. it’s just text. you can edit it with vim. your agent can edit it too. your product manager can read it and understand what the agent does. try doing that with a python config object.
here’s what a good AGENTS.md covers:
Get İrem Öztimur’s stories in your inbox
Join Medium for free to get updates from this writer.
session startup routine — what should the agent do FIRST when it wakes up? read its identity file, check the user context, load recent memory. this is defined in plain english, not code. the agent reads the instructions and follows them.
memory behavior — this is CRITICAL. your agent wakes up fresh every session. no memory by default. AGENTS.md tells it where to look: daily notes in memory/YYYY-MM-DD.md for raw logs, and MEMORY.md for curated long-term memory. the agent reads yesterday and today's files for recent context, and the long-term file for the bigger picture.
here’s the key insight: the agent manages its own memory. it decides what’s worth remembering. it writes to these files during the session. over time, it reviews daily files and distills them into long-term memory. this is exactly the OpenClaw philosophy — don’t build a complex memory system in code. give the agent files and let it figure it out.
safety boundaries — what can the agent do freely vs what requires asking first. reading files and exploring? go ahead. sending emails or posting publicly? ask first. destructive commands? use trash over rm. these rules are in the markdown, which means they're transparent and editable.
group chat behavior — if your agent is in a discord or telegram group, when should it speak vs stay silent? AGENTS.md has rules for this. respond when directly asked or when you can add real value. stay quiet during casual banter. don’t dominate the conversation.
the point is: AGENTS.md is where your agent’s personality, rules, and workflow live. it’s model-agnostic, human-readable, and the agent can modify it based on your instructions. your agent evolves through markdown, not code deployments.
BOOTSTRAP.md — the first-run experience
so AGENTS.md handles every session. but what about the very first one?
that’s BOOTSTRAP.md. think of it as the agent’s birth certificate.
when your agent boots for the first time and finds a BOOTSTRAP.md in the workspace, it knows this is day one. the bootstrap process is a conversation — the agent asks who it is, who you are, what vibe you want, and sets everything up.
specifically it:
- creates identity files (SOUL.md, USER.md) based on your conversation
- sets up the folder structure (memory directory, etc.)
- establishes the initial personality and preferences
- configures any connections (telegram, whatsapp, etc.)
then it deletes itself. BOOTSTRAP.md is a one-time thing. after the first run, your agent has its identity, its folder structure, and its ongoing AGENTS.md to guide every future session.
this is the localization layer. AGENTS.md is universal — it works the same everywhere. BOOTSTRAP.md is specific — it’s about setting up THIS particular agent in THIS particular environment with THIS particular human.
the separation matters. you can share the same AGENTS.md template across different agents while each one has its own bootstrap that personalizes it. template the behavior, personalize the identity.
the mental model
let me give you the simplest way to think about all this:
AutonomousAgent = the engine (filesystem + shell + memory + sandboxing)
AGENTS.md = the operating system (runs every session, defines behavior)
BOOTSTRAP.md = the installer (runs once, sets up the environment, then gone)
SOUL.md = the identity (who the agent is, how it behaves, what boundaries it has)
USER.md = the context (who the agent is helping, their preferences, how to address them)
the engine stays the same. the OS evolves. SOUL.md and USER.md get created during bootstrap and referenced every session. the installer does its job and disappears.
why this matters right now
the pattern OpenClaw showed works because it matches how current models handle autonomy best — simple primitives, file-based memory, behavior in plain text.
that doesn’t mean every use case fits this pattern. if you need complex orchestration, vector-based retrieval, or multi-agent workflows, those tools exist for a reason. but for cases where an agent needs to operate in a workspace with filesystem access, shell commands, and evolving context — AutonomousAgent gives you that foundation without the boilerplate.
for a hands-on walkthrough building one as a telegram bot, Onur wrote a great tutorial: Build your own OpenClaw bot With This Python Library
full docs: docs.upsonic.ai
