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

compared to routines:

- daemons are specified by a DAEMON.md file in the repo (like skills). it's version-controlled and team-owned, not hidden in a dashboard or linked to a single developers account.

- daemons have a specialized event pipeline that joins similar webhooks events into a single daemon activation and can inject late arriving events into a daemon that's already running (this is key to avoid duplicate work and noisy actions).

- the watch conditions are a more powerful activation method because they use semantic matching and can be mixed with cron schedules.

- daemons have access to the logs from their past runs (and soon proper memory) so they can learn from their own mistakes.

- example daemon files: https://github.com/charlie-labs/daemons

- reference docs: https://docs.charlielabs.ai/daemons

happy to answer questions. all feedback appreciated.

One could build a simple version of this easily - e.g. setup an endpoint that listens for the particular event you are concerned with, and fire off the headless agent with your hook specific prompt - but the amount of work involved to listen for that particular event while filtering out noise and orchestrating the task is actually not trivial.

Plus, that involves writing a lot of code. It's really magical to express all of this in natural language.

For example, this is the YAML frontmatter for a a daemon that keeps a GitHub PR in a mergeable state in the event of CI failures or branch base changes.

  ---
  id: pr-mergeability
  purpose: Keep non-draft pull requests mergeable and CI-green without changing PR intent/scope, while staying anchored to one trigger context per run.
  watch:
    - Branch sync and update events on non-draft PRs.
    - Check-status signals on non-draft PRs for checks that affect mergeability.
  routines:
    - Resolve mechanical merge conflicts when the safe resolution is clear and preserves PR intent/scope.
    - 'Apply low-risk mergeability fixes: snapshot updates, lockfile drift fixes, lint autofix, and flaky-test retries when tied to the trigger context.'
    - Escalate semantic/intention conflicts between base and branch instead of auto-resolving.
  deny:
    - When triggered by a check-status signal, do not fix or comment on unrelated failing checks.
    - Do not open new pull requests or new issues.
    - Do not review, approve, or request changes on pull requests.
    - Do not implement review-comment suggestion patches.
    - Avoid force-push by default; if force is absolutely required, use `--force-with-lease` only after fresh remote verification.
    - Do not make changes beyond mergeability maintenance.
  ---