Launching today
Daemons by Charlie Labs
Keep PRs, issues, CI, and docs moving with AI agents
577 followers
Keep PRs, issues, CI, and docs moving with AI agents
577 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
I like the role-scoped teammate framing. This feels close to the real future of agents: not one-off prompts, but recurring responsibilities with boundaries and reviewable output. How are you measuring daemon performance over time, fewer stale PRs, faster CI recovery, fewer ignored issues, or something closer to an “owner” score for each role?
With persistent teammates working across GitHub, Linear, Slack, and Sentry simultaneously, how does the system maintain state consistency when the same issue gets updated in multiple platforms at once?
Daemons by Charlie Labs
@crystalmei I think I understand what you're asking but can you clarify? Do you mean specifically, for example, that when a PR is merged in Github it may also update the relevant Linear issue as well automatically and you'd receive both alerts as a user?
Love the role-scoped approach. Clear boundaries plus persistent execution seems much more practical than adding another general-purpose agent.
Daemons by Charlie Labs
@oreofe_oluwatipin1 We totally agree! We hope you try it out and let us know what you think!
The useful framing is not “AI writes code.” It is that unresolved operational queues finally have a worker with context and memory. PRs, issues, CI, and docs only get safer if the daemon is constrained by explicit runbooks and review gates.
Lancepilot
"Agents create work, daemons do the rest" is a sharp framing. To answer your question: the loop that falls between the cracks for me as a solo builder isn't code creation, it's keeping things alive after they ship, dependency and cert renewals, a deployed service that silently dies overnight, the small maintenance no one schedules. Curious how you set the autonomy boundary: how do you decide what a daemon fixes on its own versus what it just flags for a human to approve?
Congrats on the launch. The bit I’d watch is not only when a daemon should act, but how it proves the loop is actually done.
For CI/docs/issue cleanup, do you store a small receipt of trigger, context, action taken, and verification result, or is that mostly visible in the GitHub/Linear trail?