You think you want Loops, what you need is Daemons

Charlie Labs has introduced Daemons, a system for assigning recurring engineering work a persistent, team-owned role defined in a repo's DAEMON.md contract. Unlike Loop Engineering's orchestration primitives that require teams to build and maintain their own automation infrastructure, Daemons provide bounded, reviewable activations triggered by events or schedules. The approach aims to make recurring maintenance safe and legible by giving each task a clear purpose, finite routines, and explicit deny rules, with all outputs landing in systems engineers already use.

The Most Important Work Is the Smallest Part The best software teams save human attention for the decisions that deserve it, use agents to extend that attention, and give recurring operational work an owner. Loop Engineering gives you the parts. Daemons give recurring engineering work an owner. Addy Osmani’s Loop Engineering https://addyosmani.com/blog/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. Charlie daemons https://charlielabs.ai 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 https://ai-daemons.com/spec/ : .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. 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. 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 https://docs.charlielabs.ai/daemons , Choosing daemons https://docs.charlielabs.ai/daemons/choosing-daemons , and Testing and iterating on daemons https://docs.charlielabs.ai/daemons/testing-and-iterating-on-daemons when you are ready to widen the scope. Agents create work. Daemons maintain it.