Working with HAL: An OpenClaw Experiment

Three weeks ago, I did something that felt strangely like taking a risk if done wrong, but a risk worth taking: I built myself a personal AI agent. Not a chatbot I talk to when I have a question—an actual collaborator that sends me morning briefings, manages my calendar, tracks my tasks, and reaches out across Slack, Telegram, and SMS depending on what needs my attention. I named him Hal 9000. With, I should note, significantly fewer murderous tendencies than the original. So far.

The platform is OpenClaw, an open-source personal AI assistant created by Peter Steinberger. It runs on your own machine, connects to the chat apps you already use, and comes with persistent memory, skills, and the ability to proactively do things on your behalf—not just respond when you ask. And yes—Hal runs on a Windows 365 Cloud PC, a product I helped co-found and still work on at Microsoft. There's a certain satisfaction in seeing a product you built become the infrastructure for your own AI experiments. Over the past three weeks, what started as a weekend tinkering project has turned into one of the most instructive experiments I've run in years—not just about AI, but about trust, autonomy, and what it actually means to work alongside a machine.

I figured I'd share some of what I've learned.

Building the Identity: SOUL.md and the Power of a Good Spec

Here's something that surprised me: the most important step in building an AI agent wasn't connecting APIs or configuring cron jobs. It was writing the spec for who this agent should be.

OpenClaw uses a file called SOUL.md to define an agent's persona, boundaries, and communication style. It also created an IDENTITY.md to layer on additional context. Think of it as writing a product requirements doc—except the product is your collaborator. I defined Hal as casual, direct, and no-fluff. I set boundaries for what he could do autonomously (check my calendar, pull weather data) versus what required my explicit approval (sending emails to external contacts, modifying shared calendars).

If you've ever written a good product spec, this will feel familiar. Clarity up front prevents chaos downstream. The same principle that makes spec reviews work—define the "what" and the "why" before anyone writes code—applies directly to agent design.

The Channel Strategy: Slack, Telegram, SMS, and the Redundancy Lesson

One of the things that makes OpenClaw compelling is that it works across the chat apps you already use—WhatsApp, Telegram, Discord, Slack, Signal, even iMessage. I started with Slack as Hal's primary interface. Then I added Telegram for mobile accessibility and set up SMS via Twilio for texting other people if I needed him to.

Multiple channels give you redundancy, which is great. But they also create a routing problem. If Hal sends the same message to Slack and Telegram, that's not helpful—it's noise. Getting the routing logic right took some time. I also wanted to understand the inherent differences between threaded messages in Slack vs running dialogs like Telegram. Eventually I settled on Telegram for simplicity, but if I make another Assistant I'll likely go back to Slack as threaded conversations will be easier.

Integrations That Actually Work (and the Ones That Fight You)

I gave Hal his own email address and since he's got his own computer, his own logins and credentials for everything on it. Over three weeks, I slowly gave Hal scoped permissions to manage my Google Calendar, his own Outlook email, my Todoist tasks, and a weather API. Here's what I learned about each:

Google Calendar was the most valuable integration. I used a service account rather than OAuth, which meant wrestling with permission propagation, DNS records, and SPF issues that silently dropped calendar invites. Getting family calendar sync working—so events would show up on our Skylight display—required explicit sharing permissions that don't propagate instantly. Patience required.

Email via Outlook used PowerShell COM automation for sending. It works, but corporate email gateways are picky. SPF and DKIM misconfigurations meant some emails simply vanished into the void. No error, no bounce—just silence. I ended up routing critical reports through Slack instead, which was more reliable.

Todoist was the cleanest integration. API in, task list out, daily briefings generated. Sometimes the simplest tools are the most satisfying.

Weather was trivially easy and surprisingly useful. Bundling a quick forecast into my morning briefing alongside today's calendar and tasks turned out to be one of Hal's most appreciated features. Small things compound.

Start with the integration that gives you the highest daily-use value (for me, calendar + tasks), not the flashiest one. And budget some time to dial in authentication and permissions. This takes some fiddling to get right.

Real Work: From Whistler Trips to MIT Talks

Hal wasn't just a tech demo—he did real work. He helped coordinate logistics for a family trip to Whistler (parking details, addresses, calendar entries synced to my wife's calendar). He assisted with planning for my upcoming MIT talk on product management. He drafted correspondence, stored and retrieved documents, and ran daily task briefings that genuinely saved me 5-10 minutes each morning.

The morning briefing became my favorite feature. Every day at 7 AM, Hal pulls together weather, today's calendar, and open Todoist tasks into a single digest. It sounds simple, but having that synthesis delivered proactively—before I even open my laptop—changed how I start my day. That's the difference between a chatbot (reactive) and an agent (proactive). OpenClaw's cron-based scheduling makes this possible, though I'll be honest: cron jobs fail silently, and I went two days without a briefing before I realized the scheduler had died.

Memory: The Feature That Changes Everything

Most AI conversations are ephemeral. You close the tab, and the context is gone. Hal is different. OpenClaw supports persistent memory—it remembers you across sessions and becomes uniquely yours over time. I set up daily log files (memory/YYYY-MM-DD.md) and a curated long-term memory file (MEMORY.md). This means Hal remembers what we discussed yesterday, what tasks are outstanding, and what preferences I've expressed over time.

Memory turns a tool into a collaborator. Without it, every interaction starts from zero. With it, Hal builds context over time—he knows I prefer morning briefings at 7 AM, he knows my son and daughter's schedules matters for family calendar entries, he knows which projects I'm working on.

The current limitation is search. Ideally, you'd want semantic search (embeddings) over the memory files, but the API costs add complexity. For now, keyword search over flat files is "good enough." Something to work on later.

Trust Is Built Through Transparency, Not Autonomy

This is the insight that ties the whole experiment back to what I have written about in the past. If you've read my post on the Trust Equation, you know the formula: Trustworthiness = (Credibility + Reliability + Intimacy) / Self-Orientation.

Working with Hal, I found myself applying the same framework—except now the "teammate" is an AI agent:

Credibility: Does Hal give me accurate information? When the weather API returns data, is it right? When he summarizes my calendar, does he miss anything? Early on, I caught a few errors in timezone handling. Fixing those built credibility.

Reliability: Does Hal show up? Cron jobs fail silently. I didn't get my morning briefing for two days before I realized the scheduler had died. Monitoring matters. One wrinkle I noticed: different underlying models (Gemini Flash vs. Kimi) have different tool-calling behaviors, which can affect consistency. Reliability means knowing your agent's quirks.

Intimacy: Can I be candid with Hal? This sounds strange for an AI, but it matters. I configured Hal to handle personal moments with care—stressful days, family logistics, sensitive topics. The SOUL.md file defines how Hal should respond in those contexts.

Self-Orientation: Is Hal serving my goals or its own? By definition, an AI agent has no self-orientation. But the design choices can introduce it—at one point I literally asked Hal to care more about me and anticipate my needs. He updated his SOUL.md file accordingly and suddenly started to proactively ask me how I was feeling.

The biggest trust-builder? Human-in-the-loop decisions. Hal asks before sending external emails. He confirms before destructive operations. He doesn't act autonomously on anything that touches other people. Trust is built through transparency, not autonomy—and that's as true for AI agents as it is for humans.

What "Personal AI Agent" Actually Means

After three weeks, I'd describe what OpenClaw enables in four shifts:

Not just chat—integrated tooling. Hal connects to Slack, Telegram, email, calendar, and task management. He's not a conversational interface; he's an operational one.

Not just reactive—proactive. Cron jobs, morning briefings, and heartbeat checks mean Hal reaches out before I ask.

Not just ephemeral—persistent. Memory files mean continuity across sessions, days, and weeks.

Not autonomous—collaborative. Human oversight on external actions. Hal proposes; I approve.

My Big Takeaways

We're still early. I'm actively exploring questions like: How much autonomy should Hal have over external actions? What's the right balance of proactive check-ins versus staying quiet? How should an agent handle the human side—stressful days, difficult moments—with the right touch?

Also, this stuff isn't cheap. Spent time picking the right models for primary and fallback so you don't burn through tokens and rack up a ridiculous bill. I spent $50 in the first 48 hours using Sonnet and Opus 4.5 when Kimi K2.5 or MiniMax M2.5 would have done just fine. I recommend OpenRouter to have access to lots of models with one API key.

If you're curious about building your own agent, check out OpenClaw. Buy a Mac Mini or use a Windows 365 Cloud PC. Start small—pick one integration (I'd recommend calendar or tasks), define your agent's identity in a SOUL.md file, give it a model API key, and see how it feels to work alongside an AI that actually remembers yesterday. You might be surprised how quickly a "tool" starts to feel like a "personal assistant."

Lastly, be careful. Don't give it access to your personal or work accounts. Set it up as its own user identity and slowly give it scoped access to tools as you begin to understand and trust it.