Show HN: Daemons – we pivoted from building agents to cleaning up after them | AI Paper Digest

TL;DR Highlight

DaemonMD automatically manages operational debt from AI-accelerated code generation with a single Markdown file.

Who Should Read

Development team leads and DevOps engineers who’ve adopted AI Agents (Cursor, Copilot, etc.) and are now struggling with operational overhead like abandoned PRs, documentation inconsistencies, and unclassified issues.

Core Mechanics

Unlike Agent-driven tasks initiated by humans, Daemons operate autonomously, monitoring the environment and triggering actions when changes are detected—crucially, they function without explicit prompts.
Daemons are defined within a repository using a single .md file, declaring their name, purpose, watch conditions, routines, prohibited actions, and execution schedule (in cron format) within the YAML frontmatter.
The Markdown body below the frontmatter details the Daemon’s behavior in natural language, outlining operational policies, output formats, escalation rules, and execution limits—allowing role definition without code.
Daemon behavior is explicitly restricted using ‘deny’ rules. For example, an issue-labeler Daemon might be permitted to add labels but prohibited from removing them, changing issue status, or adding comments.
The ‘limits’ section restricts processing volume per execution. The example issue-labeler limits processing to the triggering issue on creation events and a maximum of 20 issues during daily scheduled runs, preventing excessive automation.
Daemons can operate in a hybrid mode by combining ‘watch’ conditions and schedules, reacting to events immediately while periodically processing missed items.
Daemon files are designed in an open format, enabling portability across providers supporting the specification, facilitating team sharing and library creation.
Officially provided Daemon libraries include tools for maintaining PR review readiness (pr-helper), issue labeling (issue-labeler), bug triage, dependency updates (Codebase Maintainer), and documentation synchronization (Librarian).

Evidence

"A question arose regarding collision handling when two Daemons simultaneously modify related files. The developer of agent-coordinator shared their experience implementing atomic operation preemption using SQLite’s INSERT...SELECT and assigning separate git worktrees to each agent to prevent conflicts from reaching the shared branch. The community wondered whether Daemons would lean towards additive-only behavior or explicit ordering declared in the .md file.\n\nA question compared Daemons to Claude’s Hooks feature. A comment clarified that Hooks execute once per event, while Daemons are persistent processes maintaining state across multiple events—analogous to the difference between cron and a constantly running service. Daemon’s stateful monitoring across events is suitable when single-event triggers are insufficient.\n\nMultiple comments criticized the lack of explanation regarding how Daemons integrate with existing workflows on the website. One user complained about being repeatedly told to ‘talk to Charlie’ without guidance on initiating the conversation, while another noted the absence of explanations regarding execution timing. The team responded by sharing example Daemon files and reference documentation.\n\nQuestions comparing Daemons to competing products like OpenProse were also raised, along with skepticism about whether callable skills could achieve similar results. One comment pointed out that only the schedule component is deterministic, while the rest is entirely non-deterministic.\n\nA question asked whether connecting the repository to a cloud platform would trigger the platform to read and execute the Daemon files. A clear answer wasn’t provided in the comments, with the community identifying a lack of official documentation regarding the operational architecture."

How to Apply

"If PR review quality is inconsistent and PRs frequently lack adequate descriptions, deploy the pr-helper Daemon to automatically suggest improvements and flag missing reviewer context when PRs are opened or updated.\n\nIf Linear or GitHub Issues accumulate unlabeled issues, create an issue-labeler DAEMON.md file combining issue creation events with a daily scheduled run, and use deny rules to allow only label addition, ensuring safe automation without altering existing data.\n\nLeverage the open format of Daemon files to template operational automation by version controlling shared Daemons in a .agents/daemons/ directory and copying them for reuse in new projects.\n\nGiven the current lack of transparency regarding Daemon collision handling, narrowly define deny rules for each Daemon or design them with an additive-only approach to prevent conflicts."

Code Example

snippet

# .agents/daemons/issue-labeler/DAEMON.md example
---
name: issue-labeler
purpose: Ensures every Linear issue has the correct labels from the type and touchpoint label groups.
watch:
  - when a Linear issue is created
routines:
  - add missing labels to a new Linear issue
  - find issues with missing labels and add them
deny:
  - remove labels from issues
  - replace or change existing labels on issues
  - comment on 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.
- If an issue already has a label from a group, do not touch that group.
- Apply the single best-fit label from each missing group.

## Limits
- On issue-created events, process only the triggering issue.
- On the daily sweep, label at most 20 issues per activation.

---

# .agents/daemons/pr-helper/DAEMON.md example
---
name: pr-helper
purpose: Keeps PRs review-ready.
watch:
  - when a pull request is opened
  - when a pull request is synchronized
routines:
  - suggest PR description improvements
  - flag missing reviewer context
deny:
  - merge pull requests
  - push to protected branches
schedule: "0 9 * * *"
---
## Policy
Focus on short, actionable feedback.

## Output format
1. Findings
2. Suggested edits
3. Questions for author

Terminology

DaemonOriginating in Unix, a background process that runs autonomously without direct human intervention. Here, it refers to an AI agent that monitors repository state and automatically performs maintenance tasks.

operational debtSimilar to technical debt, this refers to the accumulation of tasks related to operations—PR management, issue triage, documentation updates, dependency patching—that slow down team velocity.

frontmatterA YAML-formatted metadata section enclosed in `---` at the beginning of a Markdown file. It’s used to declare structural settings for the file in a machine-readable format.

watch conditionA trigger that determines when a Daemon activates and begins execution. It monitors for events like 'when a Linear issue is created' or 'when a pull request is opened'.

driftThe phenomenon of code, documentation, and issues becoming outdated or inconsistent over time. Daemons are designed to detect and rectify this.

git worktreeA feature allowing simultaneous checkout of multiple working directories from a single Git repository, enabling parallel work without conflicts. Useful when multiple agents operate on the same repository.

Show HN: Daemons – we pivoted from building agents to cleaning up after them