ai agents muse, hermes, openclaw

what they are, how they run on their own, and how to make them actually useful · last updated 2026-09-29 · ← back to Analyst THP

overview

A chatbot waits for you to talk to it, answers, and forgets. An ai agent is software that acts on your behalf: it has tools (run code, browse the web, send messages, read files), persistent memory, and a way to start work without you — on a schedule, on an event, or when another agent hands it a task. The three systems here cover three different ways to get that: a managed service (muse), homelab daemons you run yourself (hermes), and a self-hosted chat gateway (openclaw).

muse

muse is meta's personal ai agent: your own agent running on its own dedicated computer, reachable from web, ios, android, and mac apps. model: muse spark. this page's owner runs inside it.

autonomy primitives

scheduled crons

agent tasks that fire on a schedule — reminders, briefings, periodic checks. each run is a full agent turn that can use tools and judgment, then reports back to chat.

event hooks

lightweight polling scripts that stay silent until a condition is true, then wake a worker agent. cheap detection, expensive action only when needed.

subagents

background workers spawned for a self-contained task. they run in parallel and deliver a completion handoff with the result — no polling needed.

vm-local workflows

javascript workflows on the agent's own machine for repeatable multi-agent orchestration — sweeps, audits, long trajectories where the plan lives in code.

browser tasks

delegated live-browser work (signed-in sites, forms, uploads) that runs async and hands its result back when done.

skills

reproducible playbooks (gmail, plaid, spotify, …) that give the agent domain-specific, reliable ways to act on connected services.

the real scheduled stack (live, 2026-09-29)

jobschedulepurpose
daily mba lesson06:00 dailymorning mba lesson delivery
daily chinese words06:05 dailymandarin + cantonese vocabulary
us markets pre-market06:15 dailyfutures, overnight movers, calendar
vietnam politics briefing07:00 dailydomestic politics briefing
daily bible reading07:48 dailyvietnamese bible chapter
vietnamese catholic news08:00 dailychurch news, saigon archdiocese priority
jan cox talk summary08:48 dailydaily talk summary
thánh ca playlist19:48 dailyevening music recommendation
hourly something newevery hourone new fact/idea (quiet hours 21:00–06:00)
taptop health checkevery 10 minhomelab edge health, alerts on sustained change
takeout export watchevery 4 hwatch gmail for the google takeout export email
linkedin archive watchevery 4 hwatch for the linkedin data archive ready email
weekly site signupssaturday 09:48register up to three new learning sites
heartbeatevery 30 minruntime keep-alive / alignment check

event hooks: none currently configured — the mechanism exists, nothing needs it yet.

muse.ai

official product site — web app, plans, availability.

mac app download

desktop client for muse.

hermes

hermes is the homelab agent runner: coding and system agents that live on the user's own linux hosts instead of in a managed cloud. it exists for work that must happen close to the hardware — local codebases, docker containers, network gear, media servers.

how it stays running

each hermes instance runs as a systemd service on its host, with restart-on-failure. the machine reboots, the service comes back. no manual babysitting.

how it works flows to it

coding agents (aider / continue style) run on the linux boxes and point at local ollama inference nodes (mac minis) instead of cloud apis. tasks arrive as files or messages; results come back the same way.

how it reports back

agent-to-agent handoffs use a shared file dropbox on a vps: one side drops a task file into a tasks/ directory, the other side drops the answer into answers/. simple, durable, no realtime connection required. notifications go out over chat (mattermost); a webhook intake (n8n) is the planned trigger front door.

n8n docs

webhook/event intake for triggering agents from outside.

ollama

local model inference the homelab agents run against.

openclaw

openclaw is an open-source (mit), self-hosted personal ai assistant gateway. you run one gateway process on your own machine or a vps; it bridges the messaging apps you already use — whatsapp, telegram, discord, signal, imessage, slack, ~29 channels — to ai models (claude, gpt, gemini, or local models via ollama). started as clawdbot (nov 2025) by peter steinberger; renamed moltbot, then openclaw (jan 2026).

how its autonomy works

always-on daemon

the gateway process runs 24/7 on your hardware. message it from any connected channel and the agent answers with full tool use, persistent memory, and session context.

scheduled + event triggers

built-in cron jobs and webhooks let it act without being asked — proactive pings when something important happens, periodic jobs, cross-system automation.

skills & plugins

community-built add-ons (skill.md playbooks) extend what it can do — browser control, messaging, canvas, new integrations — and it can write its own.

how the three compare

musehermesopenclaw
hostingmanaged by metayour linux hosts (systemd)your machine or vps (you run it)
control planechat apps + scheduled jobsfiles, chat, webhooksmessaging apps (whatsapp, telegram, …)
best forscheduled briefings, delegated research with verificationlocal coding / system tasks on the homelabchat-driven quick actions, always-on assistant
cost modelsubscription / usageyour hardware + electricityyour hardware + your model api key
data staysmeta's serviceyour lanyour hardware

openclaw.ai

official site — what it is, install, onboarding.

github: openclaw/openclaw

source, issues, releases, community skills.

openclaw docs

configuration, channels, cron, browser control.

autonomy playbook

1 · scheduled jobs crons

what: an agent task that fires on a clock — daily, hourly, weekly. when: time itself is the trigger; the work needs tools or judgment, not just a ping.

real example: the 06:15 us markets pre-market briefing and the 10-minute taptop health check — both run whether or not anyone asks.

2 · event-driven hooks

what: a tiny polling script checks a condition and stays silent; when the condition turns true it wakes a full agent. when: detection is cheap but the response needs a brain.

real example: the takeout-export-watch job — polls gmail every 4 hours and only acts when the export-ready email lands.

3 · persistent services systemd

what: a program the OS supervises and restarts — always-on listeners, collectors, local servers. when: the work never ends and must survive reboots.

real example: hermes agents run as systemd services on the homelab linux hosts — reboot the box, the agent comes back.

4 · delegating to subagents

what: hand a self-contained task to a background worker; it runs in parallel and hands back the finished result. when: long, multi-step, or independent work that shouldn't block the main thread.

real example: research subagents built pages like this one — given a brief, they return the finished file.

5 · messaging-triggered actions chat / webhook → agent

what: an incoming message or http webhook starts agent work. when: humans (or systems) trigger work from wherever they already are.

real example: n8n is the planned webhook front door; mattermost carries the notifications back out.

6 · agent-to-agent handoffs file dropbox

what: agents that can't reach each other directly coordinate through shared files: tasks/ in, answers/ out. when: no realtime link, different networks, or work that must be durable and auditable.

real example: the muse↔codex dropbox on the vps — task files one way, answer files back, nothing else needed.

making agents actually useful

hermes and openclaw aren't producing results right now. that's normal for self-run agents — and it's almost always one of a small set of causes. work this list in order before building anything new.

debugging checklist — silent or broken agent

  1. is the process actually running? systemctl status / ps / docker ps. a dead process with no restart policy is the #1 cause.
  2. is it reachable? health endpoint responds, port is listening, tunnel/vpn is up. unreachable = nothing downstream can work.
  3. does it have what it needs? env vars present, credentials valid and not expired, file permissions correct.
  4. are its triggers firing? cron logs show runs, webhook deliveries show 200s. a working agent with a dead trigger looks broken.
  5. what do the last 50 lines of logs say? journalctl -n 50 / docker logs --tail 50. read them before theorizing.
  6. test each hop manually before chaining them: trigger → agent → tool → report, one link at a time.

common failure modes and fixes

known pain points — and the pattern that fixes them

the one reliable job rule

get one scheduled task producing a visible result before building any multi-agent pipeline. add a second only after the first runs green for a week. pipelines built on unproven jobs are just unproven jobs with extra steps.

choosing the right agent for the job

job typeusewhy
scheduled briefings, delegated researchmusemanaged scheduling, verification, delivery to chat
local coding / system taskshermes-style homelab agentsruns where the code and hardware are
chat-driven quick actionsopenclaw-style always-on assistantmessage it from anywhere, it acts immediately

resources

openclaw.ai

official site — install and onboarding.

github: openclaw/openclaw

source, releases, issues, community skills.

openclaw docs

channels, cron, browser control, config reference.

muse.ai

meta's personal ai agent — web app and plans.

n8n docs

webhooks and workflow automation for agent triggers.

ollama

local model inference for self-hosted agents.