{"slug": "you-think-you-want-loops-what-you-need-is-daemons", "title": "You think you want Loops, what you need is Daemons", "summary": "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.", "body_md": "### The Most Important Work Is the Smallest Part\n\nThe 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.\n\nLoop Engineering gives you the parts. Daemons give recurring engineering work an owner.\n\nAddy 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.\n\nHis 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.\n\nPut 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.\n\nThere is one catch: your team now owns the schedule, discovery logic, prompts, connectors, state format, retries, concurrency, permissions, verification, and notification behavior.\n\nCongratulations. You built a small internal orchestration product. Please add it to the maintenance backlog it was supposed to reduce.\n\n[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/):\n\n```\n.agents/daemons/<daemon-id>/DAEMON.md\n```\n\nThe 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.\n\nThe role persists, but each activation is bounded. A routed GitHub, Linear, or Slack event can match `watch`\n\n, or a five-field UTC cron `schedule`\n\ncan 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.\n\nThat 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.\n\nA 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.\n\nAddy’s most important warning is that loops do not remove human judgment. Verification still matters. Faster unattended execution can produce mistakes faster too.\n\nDaemons 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.\n\nThe 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.\n\nIf you want to experiment with orchestration primitives, Loop Engineering is a useful map. If you want recurring engineering debt handled, start with the role.\n\nAsk Charlie in Slack, Linear, or GitHub:\n\nInspect 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\n\n`DAEMON.md`\n\nfile with a small rollout plan.\n\nReview 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.\n\nAgents create work. Daemons maintain it.", "url": "https://wpnews.pro/news/you-think-you-want-loops-what-you-need-is-daemons", "canonical_source": "https://charlielabs.ai/blog/you-think-you-want-loops-what-you-need-is-daemons/", "published_at": "2026-06-09 00:00:00+00:00", "updated_at": "2026-06-11 18:08:33.060158+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-products", "ai-infrastructure", "mlops"], "entities": ["Addy Osmani", "Loop Engineering", "Charlie Labs", "Charlie daemons", "GitHub", "Linear", "Slack"], "alternates": {"html": "https://wpnews.pro/news/you-think-you-want-loops-what-you-need-is-daemons", "markdown": "https://wpnews.pro/news/you-think-you-want-loops-what-you-need-is-daemons.md", "text": "https://wpnews.pro/news/you-think-you-want-loops-what-you-need-is-daemons.txt", "jsonld": "https://wpnews.pro/news/you-think-you-want-loops-what-you-need-is-daemons.jsonld"}}