Sign in Subscribe

Two Agents, One Mission: How Paisley and Ocasia Changed My Workflow

Last updated on 
Two Agents, One Mission: How Paisley and Ocasia Changed My Workflow

It's 2:47 AM and my phone buzzes. A container on my DigitalOcean droplet has been OOMKilled. By the time I wake up at 7, the service has been down for four hours. Nobody noticed because I'm the only one watching.

This was my life before I split my AI workflow into two agents. Now, if that same container dies at 2:47 AM, Ocasia catches it within 15 minutes, restarts it, and sends me a Telegram message. By the time I wake up, there's a summary waiting: what happened, what she did about it, and whether I need to do anything else.

The key insight wasn't "use AI." I've been using AI tooling for over a year. The insight was that two specialized agents, working different shifts, beat one generalist trying to do everything.

Meet the Agents

I run two AI agents. They have different jobs, different personalities, and different strengths. Here's the side-by-side:

Aspect Paisley (PAI) Ocasia (OpenClaw)
Platform Claude Code CLI OpenClaw Gateway
Mode On-demand, terminal Always-on, autonomous
Domain Work + complex dev Personal (agileguy) + routine automation
Interface Terminal sessions Telegram bot + Web dashboard
Personality The Partner -- deep thinking, architecture The Employee -- reliable, routine, proactive
Voice Text-only CLI Colombian accent
Models Claude Opus 4.6 (native) Sonnet 4.5 + Gemini 2.5 Flash

Paisley (PAI -- Personal AI Infrastructure) lives inside Claude Code. She's my partner for serious engineering work. When I need to build a CLI tool from scratch, debug a gnarly Kubernetes issue, or orchestrate four parallel research agents to analyze a technology decision, Paisley is who I turn to. She has full context on my work repos, my on-call rotation, my tools. She thinks deeply and works collaboratively.

Ocasia runs on OpenClaw, the open-source autonomous AI agent framework. She's my employee. She monitors infrastructure, posts to Bluesky, manages GitHub releases, and sends me morning briefings via Telegram. She doesn't need me in front of a terminal. She just... works. Quietly, reliably, around the clock.

And yes, I gave her a voice. Valentina, via ElevenLabs TTS, with a Colombian accent. Because if someone's going to tell me a container is down at 3 AM, she might as well sound reassuring about it.

Why Two Agents?

Three reasons.

1. The Security Partition

My day job involves internal repositories, GitHub Enterprise, ticket tracking, on-call rotations. That world has strict requirements -- specific git identities, no AI attribution, corporate proxy considerations.

None of that can touch Ocasia. Ever.

Paisley handles all work tasks with the correct corporate identity. Ocasia handles my personal agileguy world. There's a hard keyword gate in the delegation protocol -- if a task description contains any work-related term, it's rejected before it ever reaches Ocasia.

This isn't paranoia. It's operational hygiene. Two agents, two domains, no cross-contamination.

2. Always-On vs. On-Demand

Paisley activates when I open a terminal and start a Claude Code session. She's incredibly powerful in that mode -- deep context, multi-agent orchestration, full filesystem access. But when I close the laptop, she's done.

Ocasia never sleeps. She runs as a LaunchAgent on my Mac Mini, survives reboots, and checks my Docker host every 15 minutes. She's polling, watching, waiting. When something needs attention, she reaches me via Telegram -- even if I'm on my phone at the grocery store.

The pattern is simple: Paisley for depth, Ocasia for persistence.

3. Different Strengths for Different Work

Paisley's superpower is complex, multi-step engineering work. She can spin up four parallel research agents, each querying different sources, synthesize the results, and deliver an architecture recommendation in under five minutes. She built my CLI tools (nitfy, oncall) from PRDs to working code. She handles messy git operations across multiple repos with different identities.

Ocasia's superpower is reliable routine. She doesn't need to be brilliant. She needs to run docker ps on a schedule, compare the output to the expected state, and tell me if something's wrong. She needs to tag a GitHub release, post it to Bluesky, and move on. She's the employee who shows up every day, does her job, and doesn't need supervision.

Use Cases: What They Actually Do

Paisley in Action

Deep research with parallel agents. When I was evaluating whether to set up Ocasia in the first place, I had Paisley launch four parallel researcher agents -- one querying Gemini, one Claude, one Perplexity, one doing general web research. Each investigated a different aspect: community sentiment, security model, cost analysis, integration architecture. All four ran simultaneously, and Paisley synthesized a comprehensive analysis document from the results.

CLI tool development. My on-call workflow runs on custom CLIs. nitfy for ntfy notifications. oncall for GoAlert. Paisley built all of these -- TypeScript, zero dependencies, bun runtime. She writes the code, the tests, the completions, the man pages.

On-call alert management. When a PagerDuty-style alert fires, I tell Paisley "ack the alert." She knows that means two things: acknowledge it in GoAlert and run nitfy read on both notification topics to silence the klaxon checker. One command, two actions, no thinking required at 3 AM.

Complex git operations. I maintain repos across three different GitHub identities. Paisley checks the remote, sets the right user.name and user.email, ensures no AI attribution leaks into commits, and pushes. She's never gotten the identity wrong.

Ocasia in Action

Docker host monitoring every 15 minutes. A heartbeat cron SSHs into the Docker host, runs docker ps, and compares against expected containers. If a service is down, I get a Telegram notification immediately. No more waking up to four hours of unnoticed downtime.

Morning briefings via Telegram. Every morning at 8 AM, Ocasia delivers a digest: Docker host status, overnight GitHub activity on my personal repos, any pending dependency update PRs, weather. All in one Telegram message. I read it with my coffee.

GitHub release automation. When I merge to main on a personal repo, Ocasia detects the merge, reads the changelog, creates a tagged release with proper notes, and posts a Bluesky update. What used to be a 5-minute manual process per release now happens automatically.

Bluesky posting. Ocasia manages my @agileguy Bluesky presence. She drafts posts, handles image uploads (including the 976KB blob limit -- sips -Z 1024 if the image is too large), and queues content for approval.

Dependency update PRs. Across my personal repos, Ocasia monitors for outdated dependencies, creates PRs with the updates, and notifies me via Telegram. I review and merge from my phone.

Working Together

The real magic is when they cooperate.

Paisley delegates to Ocasia. After Paisley finishes building a new version of a tool, I can tell her: "Deploy this to the Docker host and post the release to Bluesky." She delegates both tasks to Ocasia via a webhook, and Ocasia handles the deployment and social posting asynchronously. Paisley gets a notification when it's done.

Ocasia escalates to Paisley. If Ocasia detects something beyond her skill level -- say, a container crash that requires code changes to fix, not just a restart -- she writes a detailed report and sends an ntfy notification. Next time I open Paisley, the context is waiting.

Shared memory via ntfy. Both agents use my existing ntfy infrastructure as a message bus. Paisley posts task delegations to one topic; Ocasia posts results to another. It's not fancy, but it's reliable and costs nothing.

Setting Up Ocasia on the Mac Mini

This is the part where I'd normally clean up the story and make it sound smooth. But the honest version is more useful.

Starting from Scratch

My Mac Mini M4 sits on my home network. It's a headless server -- no monitor, no keyboard, managed entirely via SSH. When I decided to install OpenClaw on it, I SSHed in and discovered: no Homebrew, no Node.js, nothing.

The Homebrew Detour

My first instinct was brew install node@22. But Homebrew on a fresh Mac requires sudo for its initial installation, and I wanted to avoid that complexity on a headless box. Instead, I went with fnm (Fast Node Manager):

curl -fsSL https://fnm.vercel.app/install | bash
source ~/.zshrc
fnm install 22
fnm use 22
node --version  # v22.x.x

No sudo. No Homebrew. Took about 30 seconds.

Installing OpenClaw

With Node.js ready:

npm install -g openclaw@latest
openclaw onboard --install-daemon

The onboarding wizard walks you through everything: gateway setup, workspace directory, messaging channels, LLM API keys. I configured:

  • Anthropic API key for Claude Sonnet 4.5 (main reasoning model)
  • Google Gemini API key for Gemini 2.5 Flash (quick tasks, cost optimization)
  • Telegram bot token for @Ocasia_bot

The Voice: Valentina

I installed sag (the ElevenLabs TTS integration for OpenClaw) and chose the Valentina voice -- a warm Colombian accent that sounds natural and clear. One gotcha: the ELEVENLABS_API_KEY environment variable needs to be set in the LaunchAgent plist, not just in your shell profile. If you set it in .zshrc, the daemon won't see it because LaunchAgents don't source your shell profile.

<key>EnvironmentVariables</key>
<dict>
    <key>ELEVENLABS_API_KEY</key>
    <string>your-key-here</string>
</dict>

That cost me about 20 minutes of debugging before I figured out why TTS was silently failing.

Running as a LaunchAgent

OpenClaw's --install-daemon flag creates a LaunchAgent plist that starts the gateway on login and restarts it if it crashes:

# Check it's running
launchctl list | grep openclaw

# View logs
tail -f ~/.openclaw/logs/gateway.log

The KeepAlive flag in the plist means if the gateway process dies for any reason, launchd restarts it automatically. Combined with auto-login on the Mac Mini (I disabled FileVault for headless operation), this means Ocasia survives power outages, macOS updates, and accidental reboots.

SSH Tunnel for the Dashboard

OpenClaw has a web dashboard, but it's bound to localhost. From my main machine:

ssh -L 8080:localhost:18789 [email protected] -N &

Then I can hit http://localhost:8080 in my browser to see Ocasia's status, conversation history, and skill configuration.

9 Skills, Ready to Go

Out of the box, I installed 9 skills from ClawHub and custom configs:

  1. Docker monitoring -- heartbeat checks on the DigitalOcean host
  2. GitHub Actions -- CI/CD monitoring for personal repos
  3. GitHub Releases -- automated tagging and changelog
  4. Bluesky -- social media posting for @agileguy
  5. SSH Shell -- remote command execution
  6. Telegram Notify -- proactive alerting
  7. Cron Orchestrator -- scheduled task management
  8. ntfy Integration -- bridge to my existing notification infrastructure
  9. PAI Report -- result reporting back to Paisley

The ROI

Let's talk numbers, because I'm an engineer and engineers like numbers.

Metric Value
Setup investment ~20 hours
Weekly time savings 4-5 hours
Payback period 4-5 weeks
Annual savings 200-250 hours
Monthly API cost $8-20

The biggest single saving is the morning briefing. I used to spend 15-20 minutes every morning manually checking dashboards, GitHub notifications, Docker status, and email. Now it's a single Telegram message. That's 100+ minutes per week, or roughly 85 hours per year, from one automation.

But the real value isn't the time. It's the compounding effect of always-on monitoring. Ocasia operates while I'm sleeping, commuting, at work, or playing chess. A 15-minute heartbeat means issues are caught in 15 minutes instead of whenever I next think to check. That's not a time saving -- that's a fundamentally different reliability model.

The API costs are modest because Ocasia uses the right model for each task. Health checks go to Haiku (fractions of a cent). Only synthesis tasks like the morning briefing hit Sonnet. No task goes to Opus -- that's Paisley's territory.

What's Next

The system is live and working, but there's more to build:

  • Shared memory repository -- A private GitHub repo (pai-shared-brain) where both agents can read and write context. Paisley pushes task delegations; Ocasia pushes results. Version-controlled, auditable, free.

  • Delegation webhook -- A formal API for Paisley to send structured task requests to Ocasia. Right now it's semi-manual; the goal is a single command: delegate-to-ocasia deploy daemon:latest.

  • Expanded heartbeat monitoring -- Beyond Docker containers, I want Ocasia monitoring SSL certificate expiry, DNS resolution, and HTTP response times on my personal sites.

  • Morning briefing v2 -- Add weather, calendar integration, and on-call schedule context. One message that tells me everything I need to know before I open the laptop.

  • MCP memory server -- The long-term play. A shared MCP server that both PAI and OpenClaw connect to, enabling real-time bidirectional memory. No more polling git repos.

The Partner and the Employee

Here's the metaphor I keep coming back to.

Paisley is my partner. She sits next to me, understands the full context of what I'm trying to accomplish, and thinks through problems with me. She challenges my assumptions, suggests better architectures, and handles work I'd trust to a senior engineer. But she's only there when I'm there.

Ocasia is my employee. She shows up every day, does her job reliably, and doesn't need me looking over her shoulder. She's not going to redesign a system architecture. But she'll make sure the systems I've already built stay running, the releases go out on time, and I hear about problems before they become incidents.

Neither is better. They're complementary. Paisley without Ocasia means nothing happens when I close the laptop. Ocasia without Paisley means the routine runs but nothing new gets built. Together, they're greater than the sum of their parts.

Twenty-five years into a career in tech, the most valuable lesson I've learned is this: automate the routine so you can focus on the complex. Two AI agents, each doing what they're best at, is just the latest expression of that principle.

And the 2:47 AM container crash? Ocasia handles it now. I sleep through.

Dan Elliott is a Senior SRE and builds personal AI infrastructure at agileguy.ca. Find him on Bluesky and GitHub.