Hatching your OpenClaw agent: names, identity, and personality
OpenClaw makes a small ritual of an agent's first boot. What hatching actually sets up, why it matters, and how to shape who your agent becomes.
“Hatching” is OpenClaw’s name for an agent’s first boot: the guided moment where it takes a name, a role, and the beginnings of a personality, and writes them into its workspace as the identity files it will read on every future startup. It’s a small ritual with a real function: everything your agent becomes builds on what gets established there, and all of it stays editable afterward.
Why a ritual, and not just a settings form
The hatch is the project’s personality showing, but the design underneath is practical. An agent differs from a chatbot precisely in that it persists: it will carry whatever identity you establish across months of conversations, accumulating memory around it. Making the beginning a deliberate moment, rather than defaults silently assumed, front-loads the questions that matter: what is this agent called, what is it for, how should it carry itself? The answers become plain files in the workspace, which is OpenClaw’s recurring trick: identity is data you own, not vibes in a vendor’s model.
What actually gets established
- A name. Trivial-seeming, load-bearing: the name is how you’ll address it in chat channels and how it signs its work. Pick one you like saying; you can change it later, though names have a way of sticking.
- A role and register. What the agent understands itself to be for (a personal assistant, a research aide, an ops sidekick) and how it should sound. Specificity helps: “terse and practical, asks before acting on anything external” shapes behavior more reliably than “helpful.”
- Standing knowledge about you. The starter facts it should never re-ask: who you are, what you’re working on, the preferences that would otherwise take weeks of corrections to teach.
All of it lands in the workspace as editable files, so the hatch is a first draft, not a commitment. The healthiest pattern: hatch lightly, then let the identity thicken through real use, editing the files when the agent’s self-description drifts from what you actually want.
Three notes from operating experience
- Don’t skip it on a real agent. An unhatched or carelessly hatched agent works, but everything personal about it sits on defaults, and retrofitting identity after months of accumulated memory is messier than starting deliberately.
- The identity files are part of your backup. They live in the state directory with everything else. Lose them and you haven’t lost data so much as who the agent was.
- The hatch belongs to you, wherever the agent lives. On Everpod’s OpenClaw pod nobody authors your agent’s identity before you arrive; the hatch is yours. OpenClaw 2 puts a clock on it, on any install. Its nightly memory run (“dreaming”, on by default at 03:00) writes a
memory/folder into the workspace, and a workspace with one counts as already set up, so an agent that has not been spoken to by its first 03:00 skips the hatch. As of September 2026, a first hello on the day the agent is created meets the full ritual, while a first message after that night gets an ordinary reply, and the agent’s identity sits on the defaults until you write the files yourself. The 03:00 is the machine’s own local time, which on a fresh cloud server is usually UTC.