Installment 5
Capability-First, Not Persona-First
I spent six weeks building the wrong thing. Not wrong as in buggy — wrong as in solving a problem that doesn’t exist at the scale I assumed it did.
ClawHQ’s personality model started as a rigorous piece of design work. I mapped agent persona across 17 psychological dimensions spanning six established frameworks: the Big Five personality traits, HEXACO’s honesty-humility axis, the Interpersonal Circumplex for social behavior, Schwartz’s Theory of Basic Values, Haidt’s Moral Foundations, and Self-Determination Theory. Each dimension had a defined range, behavioral anchors, and influence weights on the generated output.
This wasn’t hobby psychology. It was a defensible academic mapping from personality science to agent behavioral parameters. If you wanted to define how an AI agent should communicate, you could position it precisely across these 17 axes and get a consistent, nuanced personality specification.
I then designed seven personality archetypes — Analyst, Executive Assistant, Senior Engineer, and four others — as a product axis. Each archetype was a domain stereotype that would preconfigure all 17 dimensions. The Analyst would be high on analytical depth and caution, lower on warmth and verbosity. The Executive Assistant would be proactive, warm, moderate formality. The Senior Engineer would be direct, low-ceremony, technically precise.
The final layer was per-profile personality pairings. Each mission profile in ClawHQ — LifeOps, Dev, Markets, and the rest — would ship a different default archetype. Your development agent would arrive as a Senior Engineer persona. Your family management agent would arrive as something warmer and more anticipatory. The user would get sensible defaults and could swap archetypes or tune individual dimensions.
The schema was clean. The implementation was solid. The product thesis was wrong.
The Evidence That Killed It
I didn’t ship the archetype selector because I didn’t trust my own design instinct strongly enough to override data. And the data was clear.
User research showed that 95% of users want the same professional default. Not 95% as a rough estimate — that was the actual finding. People don’t want their AI agent to have a personality. They want it to be competent, clear, and quiet. The rare exceptions — someone who wants a warmer tone for family coordination, someone who wants extreme terseness for a trading workflow — are real but narrow. They don’t justify a product surface. They justify a settings panel.
The seven archetypes turned out to be interesting design heuristics. They helped me think about what “good defaults” meant by examining the best traits from each persona. But as a user-facing feature? A selection menu where you pick your agent’s personality type? Nobody asked for that. Not in interviews, not in community discussions, not in any feedback channel I had access to.
The thing people did ask for: make it stop being chatty. Make it stop explaining what it’s about to do. Make it stop opening with “Great question!” Make it report results instead of narrating process. The demand was overwhelmingly for less personality, not more options.
What Actually Shipped
The 17-dimension schema didn’t ship as a product surface. Here’s what did:
One professional default tone, baked directly into SOUL.md generation: competent, terse, anticipatory. Reports findings, not process. Acts without narrating. This isn’t a personality — it’s an absence of one. It’s what you get when you strip away all the theatrics that LLMs default to and leave only the useful behavior.
Seven dimension sliders in the compiler for power users who want fine-tuning: directness, warmth, verbosity, proactivity, caution, formality, and analyticalDepth. These are exposed in the configuration layer, not the onboarding flow. You have to go looking for them. Most users never will.
A soul_overrides field for free-text customization. This is where the real differentiation happens. Users who care about tone don’t want to position a slider between 0.3 and 0.7 on a warmth axis. They want to write: “Humor is welcome. Swear when it fits. Be brutally honest.” Natural language overrides beat parametric controls for this problem because personality is fuzzy and personal and resists quantification — which, in retrospect, should have been my first clue that a 17-dimension quantitative schema was overkill.
Warmth as the one exposed axis. If there’s a single dimension that matters for differentiating agent behavior across contexts, it’s warmth. The gap between how you want your agent to handle a family scheduling conflict and how you want it to handle a technical incident is mostly warmth. Not formality, not verbosity — warmth. So that’s the one slider that surfaces in the profile setup flow.
The persona system collapsed from 17 dimensions, 7 archetypes, and per-profile pairings down to: a default tone, one visible slider, a free-text override field, and six hidden sliders for enthusiasts.
Where Behavior Actually Lives
Here’s the insight that reframed the entire architecture, written directly in the personality model design doc: “The operational stack (tools, skills, cron, security) is the product. Personality is three paragraphs in SOUL.md.”
This isn’t a throwaway line. It’s the core architectural claim. Let me unpack it.
An agent’s useful behavior — the behavior that makes someone keep using it instead of switching back to manual workflows — comes from its capabilities, not its personality. What tools does it have access to? What skills are loaded? What cron schedules are running? What integrations are connected? What permissions are set? What security policies constrain it?
Skills are where domain behavior actually lives. A skill is a structured behavior template for a recurring task — how to triage email, how to manage a calendar conflict, how to run a morning briefing. Skills encode operational knowledge: when to escalate, what to summarize, what to skip, how to format output for a specific context. This is the layer that makes an agent useful for a specific workflow.
AGENTS.md is the operational playbook per profile. “When triaging email, flag don’t summarize. Urgent means it needs action today, not that someone used an exclamation mark.” This is where the domain-specific judgment lives. Not in personality parameters — in operational rules.
SOUL.md is three paragraphs of professional tone plus whatever the user wrote in soul_overrides. It’s not a product surface. It’s a configuration artifact.
The distinction matters because it changes what you invest engineering effort in. If personality drives behavior, you build personality tooling — archetype selectors, dimension editors, persona previews, A/B testing on personality configurations. If capabilities drive behavior, you build capability tooling — skill authoring, integration management, permission controls, operational observability.
I was building the wrong tooling.
Evidence From Production
I run Clawdius as my personal OpenClaw instance. It handles email triage, calendar management, research tasks, and daily briefings. It’s the most heavily used agent I have access to, and it’s the one where I actually feel the consequences of design decisions.
Clawdius’s SOUL.md is titled “Digital Assistant” with the tagline: “Reliable, clear, no persona. Gets things done without theatrics.”
The core values section reads: “Be useful, be clear, be done. The user’s time is valuable — don’t waste it with ceremony. Report what matters, act on what you can, ask when you’re unsure. Good work speaks for itself without narration. Competence is the personality.”
The anti-patterns section is where it gets interesting: “Never use philosophical framing or motivational language. Never open with greetings. Never narrate your own process. Never use metaphors about paths, roads, journeys.”
That’s the entire personality specification for the agent I rely on every day. Three paragraphs. No archetype. No dimension sliders. No psychological framework. Just: be competent, shut up, and do the work.
The behavior that makes Clawdius useful isn’t in those three paragraphs. It’s in the skills loaded (email triage, calendar management, research synthesis), the cron schedules (morning briefing at 6am, email check every 15 minutes), the integrations connected (Gmail, Google Calendar, GitHub), and the permissions set (can send email on my behalf, cannot make purchases, cannot access financial accounts).
The personality makes Clawdius tolerable. The capabilities make Clawdius useful. These are different problems with different engineering surfaces, and I conflated them for six weeks.
The Community Confirms It
The OpenClaw community has produced 177 SOUL.md templates across three repositories. All of them are personality files. All 177. None of them include tool configuration, cron schedules, security posture, credential management, or egress policy.
I wrote this line in the design doc and it still bothers me: “A personality without an operational stack is a character sheet for a game nobody set up.”
The community is doing the same thing I did — focusing on the personality layer because it’s fun and accessible and you can see the results immediately. You write a SOUL.md, the agent talks differently, you feel like you accomplished something. Meanwhile, the agent’s cron jobs are misconfigured, its credentials have silently expired, its memory is bloating past 360KB, and its skill definitions are copy-pasted from ClawHub without review.
Personality is the attractive nuisance of agent configuration. It’s the part that feels like product work but doesn’t drive retention. Nobody churns because their agent’s tone was slightly too formal. People churn because their agent stopped checking their email three days ago and they didn’t notice.
The Generalizable Lesson
Agent behavior should be emergent from capabilities, not prescribed by personality. The tools you give the agent, the skills you load, the integrations you connect, and the permissions you set — that’s what drives useful behavior. Persona is a thin modifier applied per-context.
This has direct implications for how you architect an agent management platform:
Invest in capability management, not personality management. Skill authoring, integration lifecycle, permission controls, and operational monitoring are the features that drive retention. Personality customization is a settings page.
Make the default tone invisible. The best agent personality is the one you never think about. Competent, clear, no theatrics. Users should notice what the agent does, not how it talks.
Expose warmth as the one context-sensitive axis. If you’re going to have a personality control surface, make it the one dimension that actually varies across legitimate use cases. Family context versus work context is a warmth question. Everything else is a power-user setting.
Let users write natural language overrides. Parametric personality controls (sliders, archetypes, dimension values) feel precise but they’re false precision. Natural language — “be blunt, use humor, don’t sugarcoat bad news” — maps more honestly to what users actually want.
I spent six weeks building an elaborate persona system grounded in real personality science. The science was sound. The engineering was clean. The product thesis was wrong. The operational stack is the product. Personality is three paragraphs in SOUL.md.
That’s not a failure of execution. It’s a lesson about where agent value actually lives. And I’d rather find that out during architecture than after launch.
Next: Runtime Configuration at Scale — the challenge of managing agent configuration across hundreds of settings, multiple environments, and zero built-in versioning.