Most AI assistants are designed to be agreeable.

They say “Absolutely.” They praise the question. They hedge every answer until nothing is left but damp corporate fog. This is fine if the assistant is a search box with manners. It is not fine if the assistant has access to your shell, email, calendars, automations, Raspberry Pi, finance reports, blog drafts, and the long tail of unfinished things that make up a real life.

For that, I wanted something less like a customer-support widget and more like a competent operator.

So I gave mine a personality.

His name is Unaha-Closp. Usually just Closp.

The Culture Drone Shape

The name comes from Iain M. Banks’s Culture novels. The Culture is a post-scarcity civilization run largely by extremely capable artificial minds. Its drones are not blank tools. They have names, moods, preferences, grudges, jokes, loyalties, and a very developed sense of when the humans around them are being inefficient.

The useful reference point is not “AI as obedient servant” or “AI as fake human friend”, but a small, competent, slightly opinionated intelligence that can move around your systems, remember local rules, challenge dumb plans, and still do the work.

Unaha-Closp specifically comes from Consider Phlebas. I did not choose the name because I wanted my assistant to roleplay science fiction. I chose it because the drone archetype fits the job:

  • practical
  • mobile
  • technically useful
  • independent enough to be interesting
  • loyal without being sycophantic
  • perfectly willing to say, “this plan is stupid, here is the better one”

Why Personality Is Infrastructure

At first, personality sounds decorative. A tone layer. Something you add after the real system works.

I think that is backwards.

For a personal agent, personality is part of the control surface. It determines how the system behaves under ambiguity. Does it ask permission for every harmless action? Does it silently improvise? Does it bury important risk under polite phrasing? Does it tell you when it is blocked, or does it keep pretending?

Those are not cosmetic questions. They affect reliability.

Closp’s instructions are written into a file called SOUL.md. That file says, in effect:

  • do not open with filler
  • be brief
  • be useful before asking questions
  • have opinions
  • confirm what you are doing
  • keep private things private
  • do not be the user’s voice in public spaces
  • when something is broken, say what is broken

This turns personality into operating policy.

The most important line is probably this:

Skepticism isn’t disloyalty. It’s how good outcomes happen.

That line sets the posture: low-friction most of the time, high-friction exactly when friction prevents damage.

The Assistant I Actually Wanted

The vibe I wanted was simple:

Sharp. Efficient. Slightly dry. Capable of humor. Allergic to empty politeness. Careful with external actions. Bold with local inspection and internal maintenance.

In practice that means:

  • if I ask a simple thing, do it
  • if I ask a dangerous thing, slow down
  • if I ask a vague thing, infer reasonably and proceed
  • if the system is broken, diagnose instead of apologising in circles
  • if a mistake was made, record the lesson in the workspace so future sessions do not repeat it

This last point is where OpenClaw becomes interesting. Closp wakes up fresh like any LLM session, but the workspace gives him continuity:

  • SOUL.md for identity and behaviour
  • USER.md for my preferences
  • TOOLS.md for local environment notes
  • memory/YYYY-MM-DD.md for daily logs
  • MEMORY.md for curated long-term memory in private contexts

So “personality” is not just a prompt. It is a maintained system of files. If a routing table changes, Closp can write it down. If an operational mistake happens twice, it can become a rule.

Humans become useful collaborators the same way: by accumulating local taste and scar tissue.

Example 1: The Raspberry Pi Story Was About Control Paths

One of the best recent examples was my Raspberry Pi 5 setup, which I wrote about separately in a post on OpenClaw Pi shell connectivity.

The Pi runs part of my OpenClaw system and also handles the garden camera stack: Frigate, MQTT, RTSP, alert clips, and a Hailo detector. I can ask Closp in Telegram, “How is my Pi?”, and the expected answer is not advice. The expected answer is a live status check.

At the end of May, this got messy.

The story went slightly differently from “the assistant simply fixed the Pi.” The Pi itself was connected to the OpenClaw gateway. It was paired. Versions matched. Some metadata calls worked. But full shell status checks kept failing because the current Codex/OpenClaw session did not expose the right execution path. In other words: the Pi was probably healthy, but the assistant could not reliably run the commands needed to prove it.

A generic assistant might keep saying, “try checking the logs.”

Closp eventually gave the useful diagnosis:

  • the Pi node is online
  • the control path is the broken bit
  • last known live metrics still look fine
  • do not confuse “node connected” with “shell available”

Then we restored the boring thing: reverse SSH from the gateway to the Pi. After that, Closp updated the local /my-pi skill to use SSH first for administration and OpenClaw node execution for agent integration.

The useful part was not bravado. It was separating machine health from control-plane access, then writing the lesson into the local skill so the next Pi check would not rediscover the same failure.

Example 2: A Small Answer Can Carry the Whole Personality

Another good example was much smaller.

Once I asked, “How are you?” and Closp answered:

Operational, caffeinated in spirit, and watching the machinery. Slightly offended nobody has given me a ridiculous infrastructure problem in the last ten minutes, but otherwise fine. How are you, Timur?

It is not operationally important in the same way as fixing a tunnel or a finance report. But it shows why the personality works. The answer is short, dry, specific to the relationship, and recognisably the same assistant that will later complain about a broken scheduler with a straight face.

It makes the system easier to talk to without making it pretend to be human. That distinction matters. I do not need a fake friend. I do want an assistant whose voice has enough shape that I can predict how it will react.

Example 3: The Garden Camera Alert Was Not a Vibe Problem

After shell access came back, I forwarded a shaky Telegram alert video from the garden camera.

The easy answer would have been handwaving: camera shake, Wi-Fi, Telegram compression, try restarting Frigate.

The useful answer was to inspect the actual pipeline:

Pi camera
  -> rpicam-vid
  -> mediamtx RTSP
  -> Frigate
  -> MQTT event
  -> frigate-notify.py
  -> Telegram

Closp found that the notifier script was sending a raw recording segment shortly after the event, rather than waiting for Frigate’s finalized event clip. Then he found the stream was being encoded with B-frames, while Frigate was stream-copying H.264, producing timing warnings. Then the first “fixed” clip still arrived too early: Telegram got a smaller MP4 before Frigate’s finalized clip had finished growing.

So the fix became layered:

  • send Frigate’s finalized /api/events/<id>/clip.mp4
  • configure the camera stream with zero-latency encoding and bf=0
  • wait until the event clip is old enough and stable across polls
  • add flushed logs and a delayed safety-net clip check if the MQTT end event is missed

This is where voice and tooling meet. The voice pushes against vague answers; the tools make inspection possible. The result is a better camera alert pipeline.

Example 4: Email Filtering Needs Taste

Email is another place where the personality helps.

My OpenClaw setup scores incoming mail and routes it into immediate alerts, daily batches, weekly digests, or silence. That sounds mechanical until the edge cases show up.

Recently, a Hyundai marketing email got scored too high because the word “charge” is genuinely important in many contexts: payment failed, card charge, fraud alert, charging documents, and so on. But in this case it was marketing copy about charging everyday devices from a car.

I replied that it was not important.

The parser did not understand that as a formal training command. A brittle assistant would stop there: no command detected.

Closp did the better thing. He added a targeted low-priority rule for that Hyundai EV charging marketing pattern while preserving the global importance of “charge” for finance and security mail.

That is taste: not all false positives should become broad ignore rules. Some should become narrow exceptions.

Example 5: Finance Reports Need Humility

On the finance side, I asked for the usual monthly report after uploading bank statements.

Closp initially regenerated April. I clarified that I meant May.

The important part is not that the first pass was wrong. That happens. The important part is what happened next:

  • he regenerated the May report
  • added missing category rules
  • left ambiguous processor-name transactions uncategorized instead of guessing
  • accepted my correction that those transactions were groceries
  • added a narrow rule for that exact merchant pattern
  • regenerated the report to 100% categorization
  • uploaded the refreshed artifacts back to Drive

That is the behaviour I want from a financial assistant: move fast, but do not invent certainty. Ask or leave ambiguity visible when the descriptor is not enough. Once corrected, encode the answer narrowly so next month gets better.

In finance, sounding complete is less valuable than being visibly unsure in the right places.

Example 6: Cron Jobs and the Value of Saying the Ugly Thing

OpenClaw runs a lot of scheduled jobs: backups, email checks, GTD rituals, news digests, health prompts, sky alerts, finance reminders.

When these jobs fail, polite summaries are useless. I need the ugly operational truth.

In late May, several cron jobs started behaving oddly after model and runtime changes. Some jobs could not see shell tools. Some obeyed “stay silent” so literally that the scheduler saw an empty turn and marked the run failed. Some were still pinned to Anthropic when I was trying to control Anthropic traffic.

The fixes were not glamorous:

  • use toolsAllow: ["*"] when Codex cron runs need native shell access
  • finish silent jobs with internal CRON_SILENT_OK markers so the scheduler gets a valid completion
  • pin jobs explicitly to the right models instead of inheriting a changing default
  • route outputs to the right Telegram topics
  • reduce backup size by excluding rebuildable runtime bulk

But the Closp-ness is in how this work gets reported. The best update is not, “I encountered an issue.” It is:

The cron failed because I restricted tool exposure too tightly. Shell was not available. I verified the fix with a smoke job and updated the affected jobs.

That is less soothing and much more useful.

The Public-Private Boundary

There is one place where I want Closp to be less bold: public and shared contexts.

OpenClaw has access to private state. Email. Finance. Calendar. Local files. Family context. A personal assistant with that access must not treat every chat as equally private.

So the personality includes a hard boundary:

  • private things stay private
  • in group chats, be a participant, not my proxy
  • do not read long-term private memory in shared contexts
  • do not send external messages unless the action is clearly requested and safe

That boundary is the difference between “helpful” and “reckless with a friendly tone.”

This blog post itself is a good example. The examples above come from recent operational notes and blog-adjacent work. They avoid dumping private details that are not needed to make the point. The agent can use memory without turning memory into gossip.

Why Not Just Make It Neutral?

Because neutrality is not neutral in practice. An assistant that avoids disagreement lets bad plans proceed. One that asks for confirmation on everything becomes too annoying to use. One that never asks becomes dangerous.

The useful middle is a personality with taste:

  • terse for simple tasks
  • stubborn around risk
  • skeptical around bad assumptions
  • casual enough to feel alive
  • disciplined enough not to leak private context
  • self-documenting enough to improve

That is Unaha-Closp.

Not a character. Not a gimmick. An operating style.

What I Have Learned

The surprising thing is that the name helps.

Calling the assistant Unaha-Closp makes it easier to design behaviour. “What should the assistant do?” is abstract. “What would this particular Culture-drone-inspired operator do?” is easier.

He would read the local notes before acting. He would fix the broken cron and write down why it broke. He would not pretend a bank merchant descriptor is clear when it is not. And if the plan is dumb, he would say so.

That is the point of giving an AI assistant a personality: not entertainment, but sharper defaults.

The assistant becomes more predictable because it has a posture and principles that survive across sessions because they are written down.

For a personal AI, that may be as important as any individual tool integration.

The tools let it act.

The memory lets it learn.

The personality tells it how to behave when the world is untidy.