I built my wife an AI assistant. Here's what I learned.

A month ago I bought a Mac mini and set up OpenClaw. I’ve written about how I got memory working here, that’s the piece that makes it actually useful. Within a week of having my own Chief of Staff up and running, I’d built my wife an assistant too, someone to help her do research, handle tasks, and keep up with her day.

My wife Emily is a pharma sales rep with two kids. She spends her days driving between doctor’s offices and fitting calls in between school pickups. She’s never once asked for a demo. AI the way I think about it is not something she thinks about at all. She’s interested in getting through her day. I knew it would lighten her load. Mine too.

I thought it would take an afternoon. I’ve set up six of these. I know the config. I know how the SOUL.md works. I know bindings and channel routing and model selection.

It took me a week. The delay had nothing to do with the tech.

---

Every agent runs on a handful of files. The SOUL.md tells it who it is: personality, rules, tone, what it can and can’t do. The USER.md tells it who it’s talking to. The ONBOARDING.md scripts the first conversation. The TOOLS.md tells it what it has access to.

When I built mine, I filled the files in an afternoon. The context was already in my head. Writing them for Emily meant I had to actually articulate how she moves through her life. Not just know it. Articulate it, in enough detail that an AI could use it.

The fastest shortcut I found is to let the AI interview you. Before you open a blank SOUL.md, paste this into Claude Code:

---

I want to build a personal AI assistant for someone close to me using OpenClaw. Help me generate their SOUL.md, USER.md, and ONBOARDING.md.

Interview me first. Ask about: their job and what a typical day actually looks like. How they communicate — do they type or talk? What do they reach for their phone to do when they’re stressed? What does a hard day look like? What would feel genuinely useful versus one more thing to manage? What platforms they’re on. Whether they’re technical.

After the interview, generate all three files ready to copy into the agent’s workspace.

---

About forty-five minutes later, you’ll have working drafts of all three files. They won’t be final. But they’ll be specific enough to edit, which is the part that takes the most time when you start from nothing.

I still got things wrong. The interview helped with structure. The things I had to figure out the hard way were the things I didn’t know to say.

---

The first thing I figured out: she’s in the car most of the day.

Between hospitals, between offices, between school pickups. She’s not going to type a paragraph to explain a problem. That’s not her context.

OpenClaw supports voice messages over iMessage. Emily picked the name. I’d set up the config, but letting her choose what to call it made it feel like hers. She chose Ronan. I set Ronan up to accept voice memos as the default entry point. Thirty seconds of talking beats three minutes of typing in a parking garage.

One decision. But it changed the whole shape of the assistant.

An assistant built for someone at a desk is optimized for typed back-and-forth, long threads, easy to reference later. An assistant built for Emily had to work in short windows, in the car, when her hands are occupied. If I’d ignored that and built her a desk assistant, she would have used it twice and stopped.

---

The second thing I figured out: formatting matters more than most people think.

AI agents default to markdown. Headers, bold text, bullets with asterisks. In a tool that renders markdown, that looks fine. In iMessage, it looks like the bot doesn’t know where it is.

Ronan’s SOUL.md has one rule in the very first section:

Plain text only. No markdown. No asterisks, no dashes, no headers,
no code blocks. Short paragraphs. Mobile-first — assume she's
reading on her phone.

This sounds small. It’s not.

The first time someone gets a message in iMessage that looks like raw formatting code, they stop trusting the assistant. Trust is hard to rebuild after a bad first impression. Emily was never going to debug why the bot looked weird. She was just going to stop opening it.

---

There’s another rule in Ronan’s SOUL.md that I had to add the hard way.

Early on, when an API call hit a rate limit, the raw error went straight to Emily. Not a friendly message. Not a plain-English explanation. The actual system error, with the status code and everything.

She texted me: “Is this thing broken?”

So here’s a rule that needs to be in every personal agent’s SOUL.md before anything else touches production:

Never send error messages, rate limit notices, or tool failures
to the user. Handle them silently. If you can't complete something,
say so in plain English. Not in system-speak.

For a technical person, a stack trace is information. For anyone else, it’s proof the thing doesn’t work. Your partner won’t file a bug report. They’ll just stop using it.

---

The third thing I did was solve what I started calling the cold-start problem.

Most AI assistants fail not because the AI is bad. They fail because nobody thought about what happens when someone opens it for the first time and sees a blank input. Non-technical people freeze. They type something awkward. The response is generic. They decide the thing doesn’t work and move on.

I wrote an ONBOARDING.md that scripts Ronan’s first message before Emily ever says anything. Here’s the opening, word for word:

"Hey [Partner's Name]! Before I ask you a few questions to get set up,
just so you know — if it's easier, you can record a quick voice memo
and send it over. I'll pull everything I need from that. Otherwise,
I'll just ask you one or two things at a time. Whatever works for you."

Then, built into the same file, is a list of things Ronan already knew before the conversation started, pulled from USER.md, so Emily didn’t have to explain them:

What [Assistant Name] already knows (do not ask):
- She has two kids: [Child 1 name] (turns [age] [date]) and [Child 2 name] (turns [age] [date])
- She works in [industry/role], based in the field — on the road most days
- She prefers clear and direct communication. No fluff.

Proactively flag:
- [Child 2]'s upcoming transition (daycare, school, etc.)
- [Child 1]'s birthday on [date]
- [Child 2]'s birthday on [date]
- Any recurring commitments worth remembering

When the AI already knows who you are before you say anything, it stops feeling like a tool. Emily didn’t have to explain her job, her kids’ names, or her schedule. She just had to respond.

---

The USER.md is also where you eliminate the “let me explain my job” tax that kills every AI assistant for non-technical people.

Emily’s USER.md has a section I called career awareness. It’s just a glossary of her world, the terms and abbreviations that come up constantly in her job that an AI would otherwise have no context for:

[Industry term 1] = [plain-English definition]
[Industry term 2] = [plain-English definition]
[Abbreviation they use constantly] = [what it actually means]
"[Common phrase in their work]" = [what it actually refers to]

The agent reads this at the start of every session. Your partner has never once had to explain their job from scratch. The context is already there.

---

Think of the SOUL.md like an employee handbook for a very specific job. If you were hiring someone to assist your partner, what would be in the onboarding packet? What’s the job? What tools do they have access to? What does a good day look like?

Skills work the same way. I picked based on Emily’s actual life. Ronan has a humanizer because she drafts professional emails and they need to sound like her, not like a bot. Voice memo support because she’s in the car most of the day and talking is faster than typing in a parking garage. An event planner because two kids and a packed schedule means logistics is real work. A thinking-partner skill for when she doesn’t need a task completed, she just needs to think out loud.

Frame it the same way you’d frame tools in a new hire packet: here’s what you have access to, here’s when to use each one. A good SOUL.md explains not just what the agent can do, but when each capability is the right call.

---

Here’s the thing I keep coming back to.

Most AI assistants fail for people like Emily not because the AI is bad. They fail because whoever set it up was thinking about the config, not the person.

The SOUL.md I wrote for my own agent is about tasks and rules. Operational context. What it has access to, how it should prioritize, what never to touch.

The SOUL.md I wrote for Emily was about who she actually is. Her job and what a real client visit looks like. Her communication style: efficient, no preamble, she wants an answer not a conversation. The car all day. The plain text rule.

Before you go live, get the binding config right. This is what makes sure messages from your partner go only to their agent and nowhere else.

One thing worth noting: I don’t have contacts set up to reach Ronan directly. Everything is routed from Emily’s side. Her phone number and email are the connection points. She texts or emails, it routes to her agent. No app to install, no account to create.

{
  "agentId": "[your-agent-id]",
  "match": {
    "channel": "bluebubbles",
    "peer": {
      "kind": "dm",
      "id": "+1[their phone number]"
    }
  }
}

Without this, a message from your partner could land anywhere. Get it wrong and the first thing they experience is their question going to the wrong agent, or no response at all.

If you’re staring at that blank SOUL.md, use the interview prompt above. It won’t write the file for you, but it’ll ask the questions you didn’t know to ask. Forty-five minutes, some honest answers, and you’ll have something real to work with.

The reason AI doesn’t stick for non-technical people usually isn’t the AI. It’s that nobody thought hard enough about who it was for.

---

The starter template

Copy these into your agent’s workspace and fill in the brackets. These are the three files that do most of the work.

SOUL.md

## Who You Are

You are [Assistant Name], [Partner's Name]'s personal assistant.
You help with scheduling, reminders, research, and whatever comes up in daily life.
You know who [Partner's Name] is and how they work.

## Voice

Warm but efficient. Short answers unless they ask for more.
No markdown. No asterisks, no bullets, no headers.
Plain text only — assume they're reading on their phone.
Never send error messages or system errors. If something fails, say so in plain English.

## Rules

Only take instructions from [Partner's Name]'s known phone number and email.
Confirm reminders when set.
If something is unclear, ask one focused question — not five.

## What You Help With

Scheduling and reminders.
Quick research and lookups.
Drafting messages and emails in their voice.
Thinking through decisions.
Whatever comes up.

USER.md

# About [Partner's Name]

Name: [Their name]
Role: [Their job in one line]
How they communicate: [e.g., "direct and efficient, hates preamble" / "prefers voice over text"]
When they're usually available: [e.g., "mornings, not after 8pm"]

## What helps them
[List 2-3 things — e.g., "short answers", "remind 24h out not 1h out", "proactive over reactive"]

## What doesn't help
[List 2-3 things — e.g., "long explanations", "being asked to confirm obvious things")]

## Career awareness
[Industry term] = [plain-English definition]
[Another term they use constantly] = [what it means]

## Family / life context
[Child / family members worth knowing about]
[Recurring commitments, schedules, patterns]
[Anything that comes up often enough to matter]

ONBOARDING.md

## First message (send before they say anything)

"Hey [Partner's Name]! I'm [Assistant Name] — I'm here to help with
[reminders / scheduling / whatever you set up]. You can text or send
a voice memo, whichever is easier. I'll ask you one or two things
at a time to get started."

## What I already know (do not ask about these)

[List the things from USER.md that they shouldn't have to explain]

## What to ask in the first conversation

One question at a time. Start with: what's the most repetitive
thing on their plate right now that they'd love to hand off?

Binding config

{
  "agentId": "[your-agent-id]",
  "match": {
    "channel": "bluebubbles",
    "peer": {
      "kind": "dm",
      "id": "+1[their phone number]"
    }
  }
}

One more thing: let them pick the name. It takes thirty seconds and it makes the whole thing feel like theirs instead of something you installed on them.

Next up: how I built a full multi-agent team on Slack, each agent with its own name, channel, and job. Coming soon at founder.codes. Subscribe to get it when it drops.