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 we’ve seen: 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 managed hosting done right, the ritual is preserved, not flattened — on Everpod pods your agent hatches with you at the controls, because an agent whose identity someone else authored isn’t quite yours.