You think you want Loops, what you need is Daemons

Addy Osmani’s Loop Engineering gets the direction right: stop manually prompting coding agents and design systems that find work, execute it, and check the result.

His stack is sensible. Automations discover work. Worktrees isolate parallel agents. Skills preserve project knowledge. Connectors reach tools like GitHub, Linear, and Slack. Sub-agents separate the maker from the checker. External state carries progress between runs.

Put it together and an agent can survey failed checks, draft fixes, verify them, open PRs, and update the issue tracker without waiting for the next prompt.

There is one catch: your team now owns the schedule, discovery logic, prompts, connectors, state format, retries, concurrency, permissions, verification, and notification behavior.

Congratulations. You built a small internal orchestration product. Please add it to the maintenance backlog it was supposed to reduce.

Daemons own the job

Charlie daemons start one level higher. A daemon is a repo-defined operating role for recurring maintenance or operational work. The team reviews that role in the DAEMON.md contract:

.agents/daemons/<daemon-id>/DAEMON.md

The file defines the daemon’s purpose, the events or schedule that can wake it, the finite routines it performs, and any actions it must deny. The Markdown body adds operating policy: limits, verification, freshness checks, communication rules, and when to stop or ask for help.

The role persists, but each activation is bounded. A routed GitHub, Linear, or Slack event can match watch, or a five-field UTC cron schedule can fire. Charlie loads the daemon policy and available context, performs the scoped routines, and then acts, no-ops, or asks for input. The activation ends.

That distinction matters. The difficult part is rarely making an agent do something once. It is making recurring work safe and legible after the repo changes, while humans and other agents are already working nearby.

A daemon makes the job team-owned. Its scope and guardrails live in the repo. Its output lands in the systems where engineers already review work. When its behavior needs to change, the team changes the policy in a PR.

Keep the engineer in charge

Addy’s most important warning is that loops do not remove human judgment. Verification still matters. Faster unattended execution can produce mistakes faster too.

Daemons follow the same principle. Start with one narrow, under-owned job: stale PRs, failed checks, drifting docs, aging dependencies, bug triage, or mismatched GitHub and Linear state. Give it observable wake conditions, reviewable output, explicit deny rules, and a small action limit. Widen the role only after several correct, low-noise activations.

The goal is not an immortal agent roaming the infrastructure. It is a persistent owner for recurring work, with a clear reason to start and a definite point to stop.

Skip building the plumbing

If you want to experiment with orchestration primitives, Loop Engineering is a useful map. If you want recurring engineering debt handled, start with the role.

Ask Charlie in Slack, Linear, or GitHub:

Inspect this repo and recommend the narrowest useful daemon for recurring work we neglect. Define one purpose, two or three finite routines, explicit deny rules, and a concrete watch condition or UTC schedule. Keep every output reviewable, then open a PR adding the DAEMON.md file with a small rollout plan.

Review the PR, merge it to the repo’s default branch, and wait for Charlie to ingest the merged version. Only then is the daemon eligible for live activations. Watch the first few closely. Read the daemon overview, Choosing daemons, and Testing and iterating on daemons when you are ready to widen the scope.

Agents create work. Daemons maintain it.