# Agents vs Daemons

"Agent" and "daemon" describe two structurally different kinds of AI processes:

- **Agents** are human-initiated. You give one a prompt, it does a task, it reports back, it stops. Building features, fixing bugs, shipping code.
- **Daemons** are self-initiated. They observe an environment, detect drift, and act without being prompted. Keeping PRs mergeable, documentation accurate, issues up to date, dependencies patched.

[[charlie-daemons|Charlie Labs]] introduced the explicit framing in their product marketing — their tagline is *"Agents create work. Daemons maintain it."* — but the distinction applies beyond any specific product.

## Why the split matters

Both are LLM-driven processes running tools against a codebase; they look similar from 50 feet away. The interesting differences show up in design:

**Direction.** Agents require direction every time. Task 500 costs the same human attention as task 1. Daemons require direction once (when you write the file) and then less over time as they learn the codebase and team conventions.

**Trigger.** Agents wait for prompts. Daemons subscribe to events (new PR, new issue, new error) and wake on them, optionally plus a scheduled sweep.

**Unit of work.** Agents execute tasks — bounded, with a definition of done. Daemons fulfill roles — open-ended responsibilities that don't finish.

**Evaluation.** Agent quality is measured per-task: did it ship the feature? Daemon quality is measured over time: has operational debt accrued faster or slower since this daemon started watching?

## The operational-debt thesis

[[charlie-daemons|Charlie Labs']] argument is that the interesting post-agent-wave problem isn't agents themselves — it's what agents leave behind. Every feature-shipping agent creates PRs that need descriptions tidied, tests that need maintenance, docs that drift, dependencies that fall behind, issues that pile up. The faster teams ship with agents, the faster this operational debt accrues. Daemons are the response: narrow, specialized background processes whose whole job is to pay that debt down.

This reframes "AI in software development" away from "code generation" and toward "continuous maintenance." The former is what the headlines are about; the latter is what keeps production software actually working.

## Declarative daemon specs

The interesting engineering move in [[charlie-daemons]] is the daemon-as-Markdown-file pattern:

```yaml
---
name: issue-labeler
purpose: Ensures every Linear issue has correct labels from type and touchpoint groups.
watch:
  - when a Linear issue is created
routines:
  - add missing labels to a new Linear issue
deny:
  - remove labels from issues
  - change issue status, priority, assignee, or any field other than labels
schedule: "0 2 * * *"
---

## Policy
- Only add labels. Never remove, replace, or overwrite existing labels.
...
```

The frontmatter is the role contract — what the daemon is for, what triggers it, what it can and can't do. The body is the policy — how it makes decisions when a situation is ambiguous. Critically, `deny` is declarative and first-class, not buried in a system prompt. That makes the capability surface auditable.

This is the same shape as [[claude-code]] skills and [[mcp-vs-skills|MCP]] tool manifests: small YAML/Markdown files describing what an LLM process is allowed to do, where the format itself is part of the contract.

## Design patterns that travel

Whether or not you use Charlie's specific product, several of its design choices generalise:

**Define a role, not a task.** Write the spec as "what is this agent responsible for indefinitely" instead of "what should this run do." Roles compose; tasks don't.

**Hybrid activation.** Event-driven + scheduled sweep catches downtime gaps without double-processing. A daemon watching for new issues also runs a daily sweep that catches anything missed while the system was down.

**Additive-only and rate-limited.** The example issue-labeler can only add labels, never remove them, and processes ≤20 issues per activation. Additive-only semantics means the blast radius of a bug is bounded; rate limits keep it from overwhelming humans.

**Predictable beats capable.** A small daemon that reliably does one narrow thing (label issues from a fixed taxonomy) earns more autonomy over time than a large agent that does many broad things. Operators can trust the daemon to stay in its lane.

## Where this overlaps with other patterns

Daemons overlap with several existing patterns, but aren't reducible to any of them:

- **GitHub Actions / bots.** Similar activation model (event-driven, scheduled), but bots are typically task-based, not role-based, and don't carry persistent judgment. A Dependabot run is "here are the PRs for outdated deps"; a daemon is "I am responsible for dep freshness and will decide how to address it."
- **Continuous monitoring.** Daemons watch, but unlike Prometheus alerts they're supposed to act, not just notify.
- **Reactive programming and [[behavior-tree|behavior trees]].** Same spirit (self-driven processes responding to events), but daemons operate on semantic targets (PRs, issues) via LLM reasoning, not deterministic logic over game state.

## Limitations of the concept

- **Open-ended isn't always the goal.** For one-shot migrations or specific bug hunts, a task-shaped agent is the right unit. Daemons are for ongoing hygiene, not for "close these 50 Jira tickets by Friday."
- **"Daemon" is marketing in parts.** Any sufficiently opinionated cron job + LLM call meets the definition. The interesting part is the declarative spec + deny rules, not the word.
- **Trust has to be earned per daemon.** Even a well-scoped daemon can go wrong when the underlying codebase state shifts under it (renamed labels, moved repos, deprecated APIs). The file-as-contract model helps but doesn't eliminate the need for review.

## Related

- [[charlie-daemons]] — the specific implementation this concept came from
- [[behavior-tree]] — different flavor of autonomous decision-making
- [[mcp-vs-skills]] — related file-based declarative AI tool pattern
- [[sandboxing-ai-agents]] — daemons need sandboxing too, probably more than one-shot agents do
- [[agent-memory-decay]] — relevant for daemons that accumulate context over months
- [[ai-assisted-workflow]] — human-in-the-loop pattern for agents; daemons are the other end of the human-initiation spectrum