riley tomasek (@rileytomasek) on X

X (formerly Twitter) ·

6 min read Original article ↗

Daemons clean up the mess that agents leave behind: Keep PRs mergeable, documentation accurate, issues up to date, and bugs out of production with a new type of AI background process.

The Problem: Operational debt accumulates faster than teams clear it

Stale PRs. Drifted issue metadata. Untriaged errors. Rotting documentation. Aging dependencies. Engineering teams accumulate this work faster than they clear it. Each task is too small for an engineer to prioritize, so the rational move for every engineer is to skip it. The result is a tragedy of the commons.

Operational debt is the maintenance work that accumulates across a codebase and everything around it — the project graph, the docs, the error inbox, the dependency manifest.

Planning suffers: Stale issues, incorrect labels, out of date priority fields. Every planning meeting starts with archaeology.

Onboarding drags: Documentation drifts from the codebase and is months out of date. New engineers learn outdated patterns and ship code that doesn't follow standards.

Bugs recur: Issues don't get triaged, and linger. The same alert patterns recur, get glanced at, and get dismissed

Dependencies rot: Security patches accumulate. Minor bumps become major migrations. A one-line update becomes a migration project.

The Multiplier: Agents multiply the output. Nobody multiplies the maintenance.

Agents let teams ship more code, faster, which also creates operational debt faster. More code, more docs, and more issues to maintain. Agents can fix operational debt if you ask. But someone has to notice the problem, frame the task, and prompt the agent each time. The debt scales with the output. The human attention doesn’t.

Keeping a codebase healthy isn’t a task you finish. It’s an ongoing role. On most teams, nobody fills it. Agents complete tasks. Daemons fulfill roles.

Task vs. role:

Duration: Discrete vs Continuous

Initiated by: A human prompt vs The environment

Done when: Deliverable ships vs Never

Example: “Fix this bug” vs “Keep PRs mergeable”

The Solution: What a daemon is

A daemon fills the maintenance role. You define the role once — what it watches, what it does, what it can’t do — and the daemon handles it from there. Daemons work in your team’s existing tools: GitHub PRs, Linear issues, Slack threads. No dashboard required. The name comes from Unix: a long-lived background process that maintains system health. That’s what these do for engineering teams.

Daemons have the following characteristics:

Persistent: Daemons are always running on cloud infrastructure, and accumulate context over weeks and months, getting sharper the longer they run.

Self-initiating: A PR is opened, CI fails, a Sentry alert fires. The daemon observes a condition and acts. No human prompted it. It reacts through configured watch conditions.

Role-based: Each daemon has one job: keep PRs mergeable, keep issues accurate, keep docs current, triage every bug.

Daemon Roles: A daemon for every domain

Each daemon has one job and a clear boundary around it. Narrow scope means predictable behavior and output your team can trust.

Some concrete examples of work before and after daemons:

PR Helper

Before: PRs sit for days. Descriptions drift from the diff. Merge conflicts pile up. CI fails on lint and formatting.

After: Conflicts get resolved. Failing checks get fixed. Descriptions match the diff. Humans review clean PRs.

Project Manager

Before: Issues have the wrong status, labels are missing, priorities get stale. Planning always starts with cleaning up the mess from the last iteration.

After: Metadata reflects reality accurately. Blockers are surfaced before standup. Planning becomes data-driven, not reactive.

Bug Triage

Before: Error tracker alerts are ignored or dismissed, and the same errors recur. No root cause analysis is possible.

After: Every error gets triaged within minutes. Recurring patterns get connected. Issues arrive with root cause analysis and reproduction context.

Codebase Maintainer

Before: Dependencies age. Security patches pile up. Minor bumps become major migrations.

After: Dependencies stay up to date. Security patches are promptly applied. PRs arrive tested and ready.

Librarian

Before: Docs drift within weeks. READMEs describe APIs that no longer exist.

After: Docs stay current. Stale content gets caught and updated. New engineers read docs that match the code.

The Flywheel effect: Daemons compound

Every action a daemon takes is one a human didn’t have to notice, decide on, and initiate. That overhead disappears permanently. The operational debt shrinks instead of growing.

Zero marginal attention: Agents need a human to notice, frame, and prompt every time. Daemons act on their own. The hundredth action costs the team nothing.

Learn norms: Over weeks, the daemon builds a model of your team’s conventions: labeling schemes, review preferences, escalation patterns. It stops needing correction.

Earn trust: The daemon file is a spec in your repo. The team tunes it like any other config: tighten a threshold, add a deny rule, narrow the scope. Predictable behavior earns autonomy.

Reinforce each other: Each daemon’s output is input for the others. Clean PRs mean accurate project data. Triaged bugs mean targeted fixes. More daemons, better signal.

Eventually, you forget they're running. That's the daemon working.

Landscape: Daemons vs. everything else

Daemons aren’t a replacement for coding agents. They fill the gap agents leave behind.

A local agent starts when you type a prompt in your terminal. A cloud agent starts when you assign it a task. Both wait for a human to decide something needs doing. A daemon starts when something happens in the environment — a PR is opened, CI fails, a Sentry alert fires.

Agents excel at novel work: building features, designing APIs, refactoring modules. The problem is different every time, so a human frames it. Daemons excel at ongoing work: the judgment is real, but the pattern is known and a daemon file can encode it once. Use agents to build. Use daemons to maintain what you’ve built.

Human-initiated vs. self-initiated systems:

Isolated: Local agent (Claude Code, Codex CLI)

Shared: Cloud agent (Devin, Codex)

Shared + self-initiated: Daemon

Conclusion

Agents help teams ship more, faster, which also means more operational debt, faster. The maintenance scales with the output. The human attention doesn’t. That’s a role, not a task, and on most teams nobody fills it.

Daemons do, without adding to anyone’s workload. A PR Helper keeps PRs mergeable. A Bug Triage daemon triages errors within minutes. A Librarian keeps docs in sync with the code. They run continuously in the background, learning your team’s norms and acting on what they find. No prompt. No reminder. No human in the loop.

Agents create work. Daemons maintain it.