Most writing about "AI operations" assumes you run Kubernetes and enjoy it. This article is for the other case: you are technical enough to edit a config file and run a command, but you have no interest in becoming a server administrator. You have several agents doing real work on your machine, and you want them to keep working without becoming a second job.
The good news is that the pattern is small. Four pieces — a way to keep things running, a place to see their state, a way to be told when something drifts, and written instructions for fixing it — cover almost everything.
The four pieces, in plain English
launchd is the building manager. On macOS, launchd starts services, restarts them when they crash, and defines what "running" means for each one. If your agent dies at 3am, launchd brings it back before you wake up. (The Mac operations centre article covers how services and ports work in more depth; this article is about what to do when they misbehave.)
The ops board (Semaphore) is the lobby directory. One page that shows the state of every service: running, stopped, failing, when it last checked in. When something looks wrong, this is the first place to look, because looking in five places is how incidents get missed.
Alertmanager is the alarm system. It watches metrics and decides what deserves your attention. Alarms route to Telegram, which means your phone is the pager. A good alarm says what broke and links to what to do about it; a bad alarm says nothing and trains you to ignore it.
Runbooks are the SOPs. A runbook is one document per failure mode: what the alarm means, the exact commands to run, how to verify the fix. Written while the failure is still understood, so the version of you at 3am doesn't have to reconstruct the reasoning.
From alarm to recovery, in order
The sequence matters more than the tools. Any alerting system that doesn't end in a runbook produces anxiety, not recovery.
The before and after of having a runbook
This is the highest-leverage habit in this discipline's daily work, and the cheapest one to adopt: one document per failure mode.
What this looks like on a real Mac
The rig this describes runs launchd jobs for each agent, a Semaphore ops board in a local container, Alertmanager wired to Telegram, and runbooks in a docs tree. Grafana gives the context behind each alarm. Nothing here needs a public port — the Mac operations centre article covers how that works.
Why this matters outside the terminal
The transferable claim is not "run launchd". It is that any automated system you depend on needs four things — a keeper, a window, an alarm, and a written fix — and agencies that automate tagging, reporting, or QA pipelines need exactly the same four. The tools change; the loop does not.
Where to go next
- The agent telemetry stack, explained from first principles — where the metrics that feed the alarms come from
- What should be an agent — and what should be normal code? — deciding what deserves this operational care at all