Viktor.comAn AI coworker that actually does the work
Promoted
Daemons by Charlie Labs
Keep PRs, issues, CI, and docs moving with AI agents
587 followers
Keep PRs, issues, CI, and docs moving with AI agents
587 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
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?
FetchSandbox
the "after coding agents create it" framing is exactly right, that's the gap most teams feel but can't articulate yet. curious how Daemons handles CI failures that are flaky vs actually broken by the agent's changes, that's usually where async signal gets noisy and the daemon would need to know the difference to avoid spamming reviewers. congrats on the launch.