Introducing Daemons: Doing the Work That Agents Leave Behind
Agents create work. Daemons maintain it. Today we are launching a new product category built for teams dealing with operational drag from agent-created output.
A taxonomy of recurring Product and Engineering work that doesn't need a human to remember it every week — just a process to hold the role.
A taxonomy of recurring Product and Engineering work that doesn’t need a human to remember it every week — just a process to hold the role.
We just launched Daemons. The pitch is simple: agents help humans do great work. They accelerate feature development, pull together context, and turn a direction into a working thing fast. Daemons handle everything after that.
“Everything after that” is the part teams underestimate. Not the features, but the work around them: issues that need labels, PRs that need a reviewer, bugs that need triaging, docs that drift from the code they describe, dependencies that slide one minor version at a time until they’re suddenly a migration project. Each piece is too small to prioritize. Together, they compound.
A daemon fills that role. You define it once — what it watches, what it does, what it won’t touch — and it handles its bounded part from there. No recurring prompt or calendar reminder. No one has to notice something fell out of date.
A good daemon isn’t “an agent that does anything in the background.” It has a narrow role, a clear wake condition, and a reviewable output. Some wake when a PR opens or an issue changes. Others run on a schedule and reconcile drift. The common thread is that each activation does one useful, bounded piece of work.
What follows is a working taxonomy of the recurring loops in a Product and Engineering org that fit this model naturally. The work is real. The patterns are known. It just needs someone to hold the role continuously.
Note: Daemons are markdown files that conform to a spec. A few of these are ready to install today when you sign up — Project Manager, Codebase Maintainer, Bug Triage, and Librarian.
The following are examples that could easily be installed in your projects today. Use these, modify them, or make your own!
Keeping signal true across GitHub, Linear, Sentry, and Slack so teams see what’s real — without doing archaeology first.
Watches Linear for new and updated issues, applies the correct labels from defined label groups, and sweeps daily for anything that slipped through on creation. Teams that label consistently plan better. This is the job that always gets skipped when it’s a human’s job.
Wakes on: Linear issue created or updated. Sweeps daily to catch misses.
Detects issues whose priority field hasn’t been touched in weeks relative to their status or linked activity, then surfaces the staleness to the owner for confirmation. Priority is product judgment. This daemon keeps that judgment honest by flagging when it’s gone stale, not by overriding it.
Wakes on: schedule; identifies issues where a priority field age exceeds a configured threshold.
Scans incoming Linear issues against existing ones and flags probable duplicates with match confidence — before two separate threads diverge. Humans decide whether to merge or close. This reduces the chance that two owners spend a sprint solving the same thing from different directions.
Wakes on: Linear issue created. Posts a comment with candidates; stops there.
Reviews new issues and feature specs for missing fields: acceptance criteria, linked designs, assigned owner, linked milestone. Posts a comment listing what’s absent. This one catches more than you’d expect — specs that seemed complete when written and weren’t.
Wakes on: issue created or transitioned to “In Review.” Outputs a comment with missing fields.
Watches GitHub for opened or updated PRs, checks that the title and description match the diff, verifies linked issues and test notes are present, and suggests reviewer additions based on CODEOWNERS and recent history. Reviewers spend less time reverse-engineering what they’re looking at.
Wakes on: PR opened or synchronized. Posts one comment with notes or suggestions; doesn’t post again until the diff changes.
Identifies PRs that have sat open without activity past a defined window. Comments, escalates to Slack, or flags for close. Stale PRs are where work goes to be forgotten — surfacing them early keeps branches from drifting too far from main to matter.
Wakes on: schedule. Outputs a comment on stale PRs and a Slack summary if configured.
Checks that modified files in merged PRs map to defined owners in CODEOWNERS — flagging missing coverage, deleted paths, and unavailable owners as Linear issues. CODEOWNERS files fall behind the codebase quickly. This keeps the gaps visible without anyone having to remember to look.
Wakes on: PR merged. Outputs Linear issues for uncovered or mismatched paths.
Connects Sentry errors to open Linear bugs by matching error signatures and stack traces, then posts the link directly in the Linear issue. Engineers stop digging across three tools to connect an error to its ticket.
Wakes on: Linear bug created via Sentry Alert. Outputs a comment with matched Sentry events.
Scans open PRs for missing issue links, matches commits and PR descriptions to probable Linear issues, and posts a suggestion for human confirmation. Keeps the connection between work and its tracking ticket intact without manual overhead.
Wakes on: PR opened or synchronized. Outputs a comment with suggested issue links.
Preventing code, docs, dependencies, and operational config from drifting while the team is eyes-forward on the next sprint.
Watches for merged PRs and detects documentation that references changed code, then opens small, source-backed PRs to update it. Scope is docs drift, not wholesale documentation generation — every change ties to a specific code change and can be reviewed before it merges.
Wakes on: PR merged.
After incidents close or infrastructure config changes merge, checks that on-call runbooks still reflect current reality and opens PRs for steps that no longer apply. Nothing slows down an incident like following instructions for infrastructure that doesn’t exist anymore.
Wakes on: a Linear issue labeled incident moves to Done. Also runs on a schedule against known runbook paths.
Monitors the dependency manifest and opens tested upgrade PRs when packages fall behind a defined threshold. Every PR is staged for human review — not auto-merged. One-line updates caught early stay one-line updates; left alone, they become migration projects.
Wakes on: schedule. Outputs upgrade PRs for review, one package at a time.
Watches for published CVEs against the dependency graph. Files a Linear issue and opens a fix PR within 24 hours of an advisory. Auto-merge is explicitly out of scope — the patch is ready, the decision is human. The window between “advisory published” and “team notices” is exactly where security debt accumulates fastest.
Wakes on: schedule. Outputs a Linear issue and a draft fix PR.
Identifies flags that shipped and haven’t been cleaned up post-rollout, then creates Linear tickets for removal. Works best when there’s a detectable flag registry, rollout state field, or consistent naming convention. Without that structure, false positives will be noisy.
Wakes on: schedule. Outputs Linear cleanup tickets for flags past their expected TTL.
Monitors Sentry alert volume and signal quality, flags chronically noisy or low-signal alerts for human review, and suggests threshold adjustments. Doesn’t touch alert configuration — it surfaces the case for changing it. Alert fatigue is a choice; most teams just never make it deliberately.
Wakes on: schedule. Outputs a report with noisy alert candidates and suggested adjustments.
Runs configured unused-code checks against the codebase and opens cleanup PRs for high-confidence findings. Scoped to what static analysis can verify — dynamic imports, plugin systems, public APIs, and generated code are excluded by default. Agents write a lot of code quickly. This clears the accumulation before it becomes load-bearing confusion.
Wakes on: schedule. Outputs cleanup PRs for high-confidence, statically verifiable findings.
Seeing recurring cycles all the way to resolution — not just flagging them.
Ensures every Sentry-linked Linear bug moves through the full cycle: triage, root cause, active fix, verified, closed. Nudges stalled items and escalates in Slack when something’s been stuck too long in one state. Bugs don’t recur because nobody triaged them. They recur because triage happened once and follow-through didn’t.
Wakes on: schedule. Outputs Slack escalations and Linear comments on stalled bugs.
After an incident closes, tracks post-mortem action items to completion — checking that the runbook is updated, the alert threshold is tuned, and the issue is formally resolved. Works best when action items are captured in structured Linear or Sentry fields, not buried in a doc nobody bookmarked after the retrospective.
Wakes on: a Linear issue labeled incident moves to Done. Sweeps on schedule for unresolved action items.
Watches for issues stuck in “In Progress” past their expected window, surfaces blockers before standup, and flags carry-forward candidates before sprint close. Blockers it can surface are those encoded in Linear — owner missing, dependency unlinked, status stale. It’s a scheduled report, not a substitute for product judgment.
Wakes on: schedule. Outputs a Linear report before sprint ceremonies.
On merge to main or a new release tag, drafts changelog entries from commit history and PR descriptions, then opens a PR for human review and edit before publish. Engineers write release notes last, under pressure, from memory. The quality reflects that.
Wakes on: merge to main or release tag created. Outputs a draft PR; humans review and publish.
On a defined schedule, reconciles the running changelog against merged PRs and flags discrepancies for review — entries that don’t trace back to a PR, or PRs that never made it into the log. Where Release Note Writer drafts individual release entries, Changelog Keeper keeps the whole record honest over time.
Wakes on: schedule. Outputs a reconciliation report with gaps and mismatches flagged.
After a feature merges, verifies that linked documentation is updated, feature flags are in their expected post-ship state, and associated Linear issues are closed out. Checks concrete linked artifacts and opens follow-up tasks for anything missing. The last 5% of shipping is the part that doesn’t happen.
Wakes on: PR merged to main. Outputs follow-up Linear tasks for unresolved checklist items.
Planning meetings that start from accurate data. New engineers who onboard to documentation that matches the code — and keeps matching it. Bugs that don’t recur because they were triaged, root-caused, and closed in a loop that someone held. Dependencies that never became migration projects because they were never allowed to drift that far.
The compounding works because these loops feed each other. Accurate issues make sprint planning better. Clean PRs give the Librarian cleaner change history to work from. Triaged bugs give incident response something real to reference. Each daemon’s output sharpens the signal the others work from.
The work doesn’t disappear. It gets assigned to a role that holds it permanently — one that doesn’t get pulled into the next sprint, doesn’t forget to follow up, and doesn’t need to be asked twice.
These are daemon shapes, not one-size-fits-all installs. Each one still needs a repo-local DAEMON.md: the wake signals, routines, deny rules, and review surfaces that match how your team actually works.
Add one daemon. Let it run for a week. Most teams can’t remember what it felt like to do that work manually — which is exactly the point.