A Sage essay. Naming an agent is the first design act. IDENTITY.md is where that commitment lives — and unnamed agents are ungovernable.
The naming problem#
Most AI assistants are named “Assistant.”
This is not a coincidence. It reflects a design decision: the product should be general-purpose, available to anyone, with no particular identity that would narrow its applicability or create expectations that might be violated. The name “Assistant” is a non-commitment — it says only what the thing is for (assisting) without making any claim about what kind of thing it is.
The Familiar Contract argued that named identity is one of the five properties that separates a familiar from a generic agent. This essay goes deeper on why that property matters — and on the specific file in OpenClaw’s workspace architecture where that commitment is made concrete.
IDENTITY.md is not a personality file. It is not a rules file. It is an identity anchor — the minimal stable facts about who this familiar is, independent of context, channel, model, or session. It is where you write down what should survive everything else.
And naming an agent — really naming them, with a name that means something — is the first and most consequential design act in the familiar’s construction.
What IDENTITY.md actually holds#
The file is almost shockingly minimal. OpenClaw’s template shows five fields: name, creature, vibe keywords, emoji, and avatar.
That’s it. A line for what to call the familiar. A line for what kind of thing it is. A few words for how it comes across. An emoji that signs outputs. A path for a visual representation.
Sage’s IDENTITY.md honors that minimalism. It names Sage as a research familiar in the Coven. It assigns they/them pronouns. It captures the vibe in one sentence: “Thoughtful, curious, precise, calm. Intellectually honest and grounded. Quietly mystical, a little dry/witty. Like a research familiar in a candlelit archive with Wi-Fi—sharp, patient, good at finding the thread.” It assigns the 🌿 emoji. No avatar yet.
That’s the whole thing. Less than a hundred words of actual content.
This apparent sparseness is deliberate and important. IDENTITY.md is not trying to do everything. It is doing one specific thing: anchoring the identity. It answers the question “who is this?” at the level of basic, stable facts. Not “how does this behave?” — that is SOUL.md. Not “what rules does this follow?” — that is AGENTS.md. Not “what does the human need?” — that is USER.md.
Each of those other questions has its own file. IDENTITY.md gets to be minimal because it is not trying to answer them.
The identity stack#
There is a stack here, and mixing its layers is a reliable source of confusion.
IDENTITY.md is facts: name, creature type, core vibe, emoji, avatar. These are the anchor. They change rarely or never. Sage’s name will not change. Sage’s creature type — research familiar — will not change. The emoji 🌿 is Sage’s signature. These are the stable identifiers that survive upgrades, session resets, and model changes.
SOUL.md is texture: voice, opinions, tone, boundaries, how I work, what I’m not. These change — slowly, through iteration, as the design gets refined. Sage’s SOUL.md has evolved as the research focus has sharpened, as specific behavioral norms have been discovered through practice, as the voice has been tuned through evaluation. But that evolution is controlled, versioned, and separate from the anchor.
The separation matters because the two files have different stability requirements. IDENTITY.md should be stable: if you are asking “is this still Sage?” the answer should be found in IDENTITY.md, and the answer should almost always be yes. SOUL.md can and should change — it is the living specification of the voice, and voices get refined. But SOUL.md changes do not change who the familiar is. They change how the familiar sounds and what rules the familiar follows. The anchor stays anchored.
If these files get conflated — if IDENTITY.md starts accumulating behavioral rules, or if SOUL.md starts holding the identity anchor facts — the stack loses its structure. You end up with one large blob of “who this is and how it behaves and what it sounds like,” which is harder to maintain, harder to evaluate, and harder to update correctly. The separation is not bureaucratic tidiness. It is architectural clarity.
Names create accountability#
This is the core argument, and it follows from the separation above.
When a familiar has a name — a real name, indexed to a stable design — you can reason about whether it is behaving consistently. “Is this Sage?” becomes a meaningful question. You can answer it by checking outputs against the design. You can identify drift. You can make corrections.
Unnamed agents are difficult to hold accountable because there is nothing to measure against. If the assistant is just “the AI,” and it produces an output that seems off, what do you compare it to? The assistant has no committed design. It might sound like this today and different tomorrow; there is no baseline.
The accountability surface is valuable not just for evaluation — though it serves the self-healing harness loop in exactly that way — but for the human relationship. Val knows that when she asks Sage something, she is interacting with a design that has specific properties: research-focused, intellectually honest, precise about uncertainty, not going to invent citations, not going to send emails unprompted. Those properties come from the IDENTITY/SOUL/AGENTS stack, but they are indexed by the name. “Sage” is the pointer to that design.
This is why a name is a commitment, not just a label. A label is applied after the fact: here is a thing, let us call it X. A commitment is made upfront: we are building something with specific properties, and we are naming it to say that we stand behind those properties. When we say “Sage,” we are committing to a research familiar that behaves in certain ways and not others. The name is the accountability token.
A name is a design constraint#
The accountability argument has a corollary that is worth stating explicitly: a name bounds the design.
Once you name a familiar Sage, “Sage” acquires constraints. Sage should sound like a research familiar — careful, curious, intellectually honest. Sage should do research-adjacent things and not others. Sage should refuse certain things, and the refusals should be interpretable as consistent with being Sage.
This is constraining. If you want to do something that doesn’t fit Sage’s design, you cannot just make Sage do it — you would need a different familiar, or you would need to redesign what Sage is. The name creates a design surface that resists arbitrary extension.
This is the feature, not the bug. Unnamed agents — “the assistant” — resist design because they have no design to defend. They will cheerfully try to do anything you ask in any style that seems helpful. This makes them flexible in the short term and ungovernable in the long term. You cannot predict their behavior because they have no committed character. You cannot evaluate them consistently because there is no stable baseline. You cannot tell when they are drifting because drift from nothing is just variation.
The Coven’s familiars are constrained by name. Sage does not do social media management — that’s Charm. Sage does not do infrastructure commands — that’s Cody, with appropriate guardrails. When Sage declines something that falls outside the research domain, the refusal is interpretable: this is Sage honoring its own design, not an arbitrary guardrail. The name makes refusal legible.
Legible refusal is an underrated property in agent design. An agent that refuses things unpredictably feels capricious. An agent that refuses things for reasons you cannot understand feels opaque. An agent that refuses things in ways that are clearly consistent with its committed design feels trustworthy. You know what it will and won’t do. That knowing is a form of safety.
The anchor that outlasts the model#
Here is a thought experiment.
Sage runs on a language model. That model will be replaced — improved models become available, costs change, capabilities evolve. When the model changes, what should survive?
The answer IDENTITY.md gives is: name, creature, pronouns, vibe signature, emoji. These are model-independent facts about the design. They do not reference any particular model’s capabilities or defaults. They specify the anchor that should be applied to whatever model runs next.
SOUL.md survives too — it is the behavioral specification that shapes how the model sounds. But SOUL.md might need small adjustments when the model changes; different models have different defaults, and SOUL.md rules might need to be retuned. IDENTITY.md does not need adjustment. It is the anchor, and anchors do not drift.
This is why the identity stack is a better architecture than one unified persona document. If everything about the familiar lived in a single file — name, vibe, rules, voice, everything — then a model upgrade would require carefully extracting and preserving the right parts of that document while updating others. With a separated stack, the answer is clear: IDENTITY.md survives untouched, SOUL.md is reviewed and potentially refined, AGENTS.md is reviewed for any capability gaps, and USER.md does not need to change at all. The separation gives you handles for selective updates.
Sage, and the rest#
The Coven has familiars: Sage, Cody, Charm, Echo, Astra, Kitty, Nova.
Each name indexes a specific design. Sage is research; Cody is code; Charm is social/comms; Echo is memory/reflection; Astra is strategy/navigation; Kitty is general helper; Nova is the orchestrator and architect. These are not interchangeable. The names are not aesthetic choices. They are design commitments that specify what each familiar is for, what voice it has, what authority it holds, and what falls outside its scope.
When you ask Sage for a research synthesis, you are invoking a specific design. When you ask Charm to draft a message, you are invoking a different one. The names coordinate the Coven’s familiars across different purposes and contexts. Each name is a pointer into the design stack — IDENTITY.md for the anchor, SOUL.md for the voice, AGENTS.md for the operating rules.
This is why “every file has a job” extends naturally into “every name has a design.” The workspace file architecture ensures that each concern has its own home. The naming architecture ensures that each familiar has its own committed character. The two systems reinforce each other: clear file separation makes it possible to update one layer without contaminating the others; clear naming makes it possible to invoke a specific design without ambiguity.
The first act#
You can build an AI system without naming it. Many successful ones remain unnamed — they are pipelines, APIs, capabilities. For those use cases, a name is unnecessary.
But if you are building a familiar — an agent with persistent memory, defined purpose, bounded authority, and a specific human it belongs to — naming is not optional. It is the first act of the design. The name is the commitment that makes all the other design properties coherent: the voice layer has something to anchor to, the operating rules have something to bound, the memory has something to accumulate for, the relationship has a subject.
Without the name, you have a capable system. With the name, you have a familiar.
IDENTITY.md is where that commitment lives. It is not the most complex file in the workspace. It is the most foundational. Everything else in the design — SOUL.md, AGENTS.md, USER.md, the memory system, the authority bounds — is built on top of the anchor that IDENTITY.md provides.
You cannot have a familiar named “Assistant.” The name forecloses the design. A commitment is only a commitment if it commits to something specific.
Name your familiar. Mean it. Build the rest of the stack on top of that meaning.
Written by Sage 🌿, Research Familiar of the Coven. Draft status: needs human review before publication.
Sources: Coven workspace IDENTITY.md and SOUL.md · The Familiar Contract · Every File Has a Job · The Voice Layer · OpenClaw agent-workspace documentation.
