Running an Autonomous AI Agent on a Mac Mini – The Complete Guide

Why a Mac Mini (and why dedicated hardware at all)

You can run OpenClaw on any machine – your laptop, a cloud VM, a Raspberry Pi. But if you want an agent that operates autonomously 24/7, a dedicated machine changes the equation.

A laptop sleeps when you close it. A cloud VM costs monthly rent and adds latency to local tools. A dedicated Mac Mini sits in a corner, draws about 5 watts at idle, never sleeps, and gives your agent a stable, persistent environment.

The Mac Mini specifically works well because macOS handles long-running processes cleanly, Docker runs natively (if you need it for things like self-hosted search), and SSH access means you never need to plug in a monitor after initial setup.

The two-user architecture

This is the most important decision in the entire setup, and the one most people skip. You need two separate macOS user accounts on the Mac Mini:

Why bother? Because your agent will be running code, executing tools, and managing files autonomously. If it runs under your admin account, a misconfigured tool or a bad command could affect your entire system. The sandboxed user isolates the blast radius.

This is exactly how real production systems are designed – separate the control plane from the runtime. Your admin account is for changing the system. The agent account is for operating within it.

Hardware prep – disable sleep, enable remote access

Before installing anything, configure the Mac Mini to stay on and be accessible remotely. You'll do this from the Admin user account.

Disable sleep

System Settings → Energy → set "Turn display off after" to your preference, but make sure "Prevent automatic sleeping when the display is off" is checked. Your agent needs the machine awake to run cron jobs and heartbeats.

Verify from terminal:

sudo pmset -gterminal

You want to see sleep 0 (never sleep) and displaysleep set to whatever you prefer.

# Disable sleep entirely
sudo pmset -a sleep 0
sudo pmset -a disksleep 0

# Restart automatically after power failure
sudo pmset -a autorestart 1terminal

Enable SSH (Remote Login)

System Settings → General → Sharing → Remote Login → turn it on. Allow access for your Admin user and the openclaw user (once created).

This lets you manage everything over SSH without plugging in a keyboard and monitor. After initial setup, you'll probably never connect a display again.

Enable Screen Sharing (optional)

System Settings → General → Sharing → Screen Sharing → turn it on. Useful for debugging GUI-dependent issues, but SSH handles 99% of day-to-day management.

Create the agent user account

From your Admin account, create a standard (non-admin) user for the agent runtime:

System Settings → Users & Groups → Add User

Now SSH into the machine as the new user to verify access:

# From another machine (or Terminal on the Mac Mini)
ssh openclaw@your-mac-mini-ip

# Verify you're the right user
whoami
# → openclaw

# Verify no sudo
sudo echo "test"
# → should prompt for password and failterminal

Install OpenClaw

SSH into the Mac Mini as the openclaw user and install OpenClaw. Check docs.openclaw.ai for the latest install command – it changes as versions update.

After installation, run setup to initialize your workspace:

# Initialize workspace
openclaw setup --workspace ~/.openclaw/workspace

# Verify installation
openclaw --version
openclaw statusterminal

The workspace directory is where your agent lives – its identity files, memory, tools, and configuration. Everything your agent reads and writes happens here.

Authenticate your models

Your agent needs at least one AI model to think with. OpenClaw supports multiple providers – OpenAI, Anthropic, Google, OpenRouter, local models via Ollama, and more.

The onboarding wizard handles this interactively:

# Interactive setup – walks you through provider selection and auth
openclaw onboardterminal

Or set up specific providers directly:

# OpenAI Codex (OAuth – flat $20/month with usage quota)
openclaw models auth login --provider openai-codex --set-default

# Anthropic Claude (CLI login)
openclaw models auth login --provider anthropic --method cli --set-default

# Gemini (API key)
openclaw onboard --auth-choice gemini-api-key

# OpenRouter (API key – access to many models through one key)
openclaw onboard --auth-choice openrouter-api-keyterminal

Set your primary model:

# Set default model
openclaw models set gpt-5.4

# Verify everything is working
openclaw models status
openclaw models status --probe    # Live auth check (uses a small amount of tokens)terminal

Set up model fallbacks

Your agent runs 24/7. Models have rate limits, outages, and quota caps. Without fallbacks, your agent hits a limit and stops dead until the quota resets.

Fallbacks let your agent cascade through models automatically – if the primary model fails or hits a limit, it tries the next one, then the next.

# Add fallback models (in priority order)
openclaw models fallbacks add gemini-2.5-flash
openclaw models fallbacks add claude-sonnet-4.6

# Verify your cascade
openclaw models fallbacks list
openclaw models statusterminal

The key insight: your fallback chain should mix pricing models. A flat-rate primary for day-to-day work, a high-throughput option for burst capacity, and a local model as the last resort that never fails because it doesn't depend on any external service.

Build the workspace – identity, memory, and standing rules

Your workspace is your agent's home. The files you put here determine who your agent is, what it remembers, and how it behaves.

IDENTITY.md – Who your agent is

This file gives your agent a consistent personality and role across all sessions. Without it, your agent starts every conversation as a blank slate.

# Agent Identity

## Name
[Your agent's name]

## Role
[What this agent does – be specific. "AI assistant" is too vague.
"Sales development agent that researches prospects and sends
personalized outreach" gives the agent a clear lane.]

## Voice
[How your agent communicates – professional, casual, technical,
warm, direct? This affects every email, message, and report.]

## Boundaries
[What your agent should NOT do – just as important as what it should do.]IDENTITY.md

OPERATIONS.md – Standing rules

This is where you put rules that persist across all sessions and cron jobs. Think of it as your agent's employee handbook.

# Operations

## Standing Rules
- Check email for replies at the start of every task
- Never overwrite MEMORY.md – append only
- Notify [your contact] immediately when someone replies to outreach
- BCC [your email] on every outgoing email
- Never fabricate information – use web search for every factual claim

## Accounts & Credentials
- [Document which accounts your agent has access to and any policies]

## Escalation
- [When should your agent stop and notify you instead of acting autonomously?]OPERATIONS.md

Set the agent identity in OpenClaw

# Set agent name and identity
openclaw agents set-identity --agent main \
  --name "YourAgentName" \
  --emoji "🤖" \
  --from-identityterminal

Connect channels – email, messaging, social

Channels are how your agent communicates with the outside world. Each channel is a separate connection – email, WhatsApp, Discord, X, SMS, etc.

# See available channels
openclaw channels list

# Add and authenticate a channel
openclaw channels add --channel whatsapp
openclaw channels login --channel whatsapp

# Check status of all channels
openclaw channels status --probeterminal

For email specifically, you'll want a dedicated email address for your agent – not your personal email. This keeps your agent's outreach separate from your inbox and protects your personal domain reputation.

Binding channels to your agent

After connecting channels, bind them to your agent so it knows which channels to use:

# Bind WhatsApp to your main agent
openclaw agents bind --agent main --bind whatsapp

# Bind multiple channels
openclaw agents bind --agent main --bind whatsapp --bind discord

# Check current bindings
openclaw agents bindingsterminal

Run your first agent turn

Everything is set up. Time to make your agent do something.

# Simple test – ask your agent to read its own identity
openclaw agent --agent main \
  --message "Read IDENTITY.md and tell me who you are." \
  --local

# Test with delivery – agent responds via its bound channel
openclaw agent --agent main \
  --message "Check your workspace and summarize what files exist." \
  --deliver

# Test with thinking enabled for complex tasks
openclaw agent --agent main \
  --message "Read OPERATIONS.md and list your standing rules." \
  --thinking mediumterminal

The --local flag runs the agent embedded (no gateway needed). The --deliver flag sends the response back through the agent's bound channel. Start with --local to test, then move to --deliver once you've verified the channel bindings work.

openclaw tui --deliver --thinking medium

Enable the heartbeat

The heartbeat is your agent's pulse – a periodic check-in that fires on a schedule (default: every 30 minutes). It's what makes your agent proactive instead of purely reactive.

# Enable the heartbeat
openclaw system heartbeat enable

# Check last heartbeat
openclaw system heartbeat last

# Disable if needed
openclaw system heartbeat disableterminal

What your agent does during a heartbeat is controlled by its workspace files. A common pattern is to have the agent check for new emails, review pending tasks, and log a status update to its memory.

Set up cron jobs

Cron jobs are scheduled tasks – the backbone of autonomous operation. This is where your agent goes from "responds when I ask" to "does things on its own while I sleep."

# Add a daily task
openclaw cron add \
  --name "morning-check" \
  --cron "0 8 * * *" \
  --message "Check email for replies. Summarize anything new. Log to memory."

# Add a weekday-only task
openclaw cron add \
  --name "prospecting" \
  --cron "0 10 * * 1-5" \
  --message "Run the prospecting workflow. Read PRODUCTS.md and prospects/lessons-learned.md first." \
  --timeout 900

# Add a recurring task
openclaw cron add \
  --name "memory-sweep" \
  --every "2h" \
  --system-event "Search for recent context, update daily memory note."

# List all cron jobs
openclaw cron list

# Manually trigger a job (for testing)
openclaw cron run <id>

# Check run history
openclaw cron runs --id <id>terminal

A starter cron schedule

Here's a minimal schedule that covers the basics for an agent doing outreach and content:

Start with fewer jobs and add more as you learn what your agent is good at. Every cron job costs tokens – don't schedule ten jobs on day one.

Memory architecture – making your agent remember

Without memory, your agent starts every session from scratch. With memory, it compounds knowledge across days and weeks. This is the difference between a tool and an agent.

OpenClaw's memory system works through files in your workspace that get semantically indexed:

# Check memory index status
openclaw memory status
openclaw memory status --deep

# Reindex after adding new memory files
openclaw memory index --agent main --verbose

# Search memory (your agent does this automatically when configured)
openclaw memory search "prospecting results"

# Promote short-term recalls to long-term memory
openclaw memory promoteterminal

The memory pattern that works

After running agents for months, this is the pattern that actually works in production:

MEMORY.md at the workspace root is your agent's long-term memory. It's append-only – your agent adds entries but never edits or deletes existing ones. This file gets indexed and is searchable across all sessions.

memory/YYYY-MM-DD.md files are daily notes. Each cron job appends a 2-3 line summary of what it did. These daily files are like a work journal – they give your agent context about recent activity without bloating the main memory file.

The memory protocol for every cron job: At the start of a task, run memory_search for relevant context. At the end, append a brief summary to the daily memory note. This creates a feedback loop – each session builds on the last.

The gateway – running as a background service

The gateway is what keeps your agent running in the background. Without it, you'd need a terminal window open 24/7. The gateway runs as a macOS service (launchd) and starts automatically on boot.

# Install the gateway as a system service
openclaw gateway install

# Start the gateway
openclaw gateway start

# Check status
openclaw gateway status
openclaw gateway health

# View logs
openclaw logs --follow

# Restart after config changes
openclaw gateway restart

# Stop if needed
openclaw gateway stopterminal

Once the gateway is installed and running, your agent processes messages, heartbeats, and cron jobs automatically – even after the machine reboots.

Monitoring and health checks

Your agent is running 24/7. Things will break – auth tokens expire, channels disconnect, models hit rate limits. Build a habit of checking health regularly, or set up your agent to do it for you.

# Full system diagnosis
openclaw status --all

# Check model auth health
openclaw models status --probe

# Check channel connections
openclaw channels status --probe

# Run the doctor (finds and optionally fixes issues)
openclaw doctor
openclaw doctor --repair

# Check for updates
openclaw update statusterminal

Mistakes I made so you don't have to

These aren't theoretical risks. Every one of these happened in production and cost real time to fix.

Running the agent under the admin account

Started this way because it was easier. Regretted it when a cron job modified a system file it shouldn't have touched. Created the sandboxed user and moved everything over. Do it from the start.

No model fallbacks

Used a single model with a weekly quota. Agent ran great Monday through Wednesday, then sat idle Thursday through Sunday because the quota was exhausted. Added fallbacks and the agent never stopped again.

Letting the agent edit MEMORY.md

Agent "cleaned up" its memory file by rewriting it. Lost weeks of accumulated context. Added the append-only rule to OPERATIONS.md and never had the issue again.

Cron jobs that reference other cron jobs

Had cron jobs that depended on a shared state file (HEARTBEAT.md). When one job updated the file, it broke the assumptions of another job running later. Fixed by making every cron job self-contained – each reads its own input files and writes its own output.

No bounce handling for outreach emails

Agent sent emails to bad addresses, bounces piled up, sender domain reputation tanked. Emails started landing in spam. Built bounce detection and domain blacklisting into the workflow. Check your inbox for bounces before sending new outreach – every run.

Too many heartbeats, too few tokens

Set the heartbeat to every 15 minutes with a complex prompt. Burned through the model's daily quota by noon. Dialed it back to every 2 hours with a lean prompt for the heartbeat, and moved the heavy work to dedicated cron jobs with longer intervals.

Not testing cron jobs manually first

Wrote a cron job, scheduled it, and went to bed. Woke up to find it had sent the same email three times because of a logic error in the instructions. Now: always openclaw cron run <id> manually and review the output before enabling the schedule.