Launching today
Daemons by Charlie Labs
Keep PRs, issues, CI, and docs moving with AI agents
548 followers
Keep PRs, issues, CI, and docs moving with AI agents
548 followers
Charlie Labs gives engineering teams always-on AI daemons that keep work moving after coding agents create it. Define recurring roles in your repo, then let Daemons monitor PRs, issues, CI, docs, and Sentry errors over time. Instead of waiting for another human prompt, Daemons leave reviewable updates where your team already works: GitHub, Linear, Slack, and Sentry.
Free Options
Launch Team / Built With
Daemons by Charlie Labs
Hi Product Hunt — we're Charlie Labs and we built Daemons for software teams that are already using coding agents and discovering a second-order problem: faster code creation also creates more operational debt.
Daemons are persistent, role-scoped teammates that work across GitHub, Linear, Slack, and Sentry.
📜 Our thesis is simple: agents create work. Daemons do the rest.
How it works:
Teams define the roles and boundaries in Markdown.
Daemons then keep recurring loops moving — issue hygiene, docs and dependency maintenance, bug triage, CI repair, and follow-through — with reviewable PRs, issues, reports, escalations, fixes, etc.
Continue to improve the underlying Daemons with Charlie's help
We would especially value feedback from teams using coding agents today: which recurring engineering or operational loop is still falling between the cracks for you?
Most teams can run several daemons consistently on our free plan.
Start here: https://charlielabs.ai/
@jerrod_engelberg This feels like a natural extension of coding agents, focusing on the messy on operational side that usually gets ignored.👍
The daemon model is clever here. Persistent watchers that accumulate context over time solve the state gap that one-shot agents miss. Building async coordination pipelines, you'll realize fast that handoffs degrade without a continuous observer. How do you handle conflicting writes when two daemons simultaneously target the same PR thread or Linear issue?
Daemons by Charlie Labs
@anand_thakkar1 good question. A design decision really important to us early on was to have the daemons, respectively, have visibility into other daemon runs. The knowledge then becomes context of the existing daemon run.
Raycast
Love the name.
Love this framing. Coding agents have gotten good at creating work but not at shepherding everything that comes after (PR reviews, CI failures, stale issues). Do the daemons leave a comment and wait when the right action is ambiguous, or do they try to resolve it automatically? Congrats on the launch.
Daemons by Charlie Labs
@i_sanjay_gautam thanks Sanjay!
The short answer to your question is that Daemons can do both, and can be tuned to be more or less aggressive to act.
Here is an example of a daemon (resolving failing CI checks) that will be more aggressive in acting because the trigger is clear (failing CI): https://github.com/charlie-labs/daemons/blob/master/daemons/pr-check-repair/DAEMON.md
On the other hand, here is a daemon (docs drift) that will be more modest about when it comments because often, if your docs haven't drifted, you don't really want to hear from this daemon 😊: https://github.com/charlie-labs/daemons/blob/master/daemons/docs-drift-maintainer/DAEMON.md
@Daemons by Charlie Labs This feels like a practical step beyond code generation , keeping the follow through work moving is where many teams still struggle .
Daemons by Charlie Labs
@nora_bennett2 We've noticed that ourselves, and in the early trials people have been reporting back on with Daemons, it's been noted that adding Daemons helps agent work go faster and be less of an operational burden.
Liked the approach of "operational hangover" created by coding agents. My concern or rather a query is; as organizations will deploy dozens of specialized daemons, does the coordination cost between daemons become the next bottleneck? In other words, who manages the managers? thoughts on that ?
Daemons by Charlie Labs
@faisal_2420010 that's a very good question and one that we are even running into internally --> we now have dozens of daemons set up on our largest repo and typically run several hundred daemon jobs per day.
A few things that can help:
1.) Daemons are not in a silo, they have access to other daemon runs from Charlie and have enough intelligence to bring that awareness into their own run.
2.) If you start getting overwhelmed, you can always add our built-in agent, @charliehelps to your Github as a collaborator and ask @charliehelps for daemon clean up or look for potential overlap.
3.) If you want to go really meta, you can write a daemon to keep your daemons up to date 🤯 / not conflicting with one another
In my experience the operational debt quietly stacks up behind the create step but everyone's still optimizing that create step. How's the aggressiveness dial? The docs-drift deciding when to shut up is the hard one. Is that threshold hand-tuned in your md.file? Congrats with the launch!
Daemons by Charlie Labs
@artstavenka1 Thanks, Art! Yes, how often a Daemon runs, and the condition it runs on, are all tuned via the markdown file. For more info, check out the Use Cases page here which has various Daemon definition Markdown files on it https://charlielabs.ai/use-cases/
Daemons by Charlie Labs
@artstavenka1 @mrb_bk agreed. To add on to that even further, providing clear guidelines when the daemon should `no op` is really helpful.
Here is the specific part of the daemon default for docs-drift, for example.
https://github.com/charlie-labs/daemons/blob/master/daemons/docs-drift-maintainer/DAEMON.md