Discussion
Agents create work.Daemons maintain it.
potter098: The drift detection angle is interesting. I'd be curious how you handle cases where two daemons touch related files — is there a way to declare ordering constraints in the .md file, or do they run in isolated branches?
rybosome: Each daemon runs in its own isolate, but the output is typically shared state; eg multiple daemons contribute to the same PR from separate container runtimes.It’s possible to make naive daemons that stomp on each other (as with a UNIX daemon), but they’re highly responsive to coordination instructions and generally do very well at additive rather than competitive contribution.
jb_hn: Looks really interesting -- quick question though: how does this differ from hooks (e.g., https://code.claude.com/docs/en/hooks)?
simonw: Looks more similar to routines for me (just launched the other day): https://code.claude.com/docs/en/routines
panosfilianos: Why couldn't these just be callable skills?
rybosome: Callable skills can’t activate on a schedule or listen for events. Making a daemon which invokes other callable skills is a great use case!I’m an eng on the team that built this, in full disclosure.
Bootvis: I do really like the idea.But pardon my ignorance, but one could quite easily roll this themselves? Script the hooks and fire off a headless agent with a hook specific prompt.
rileyt: here are a few more resources:- example daemon files: https://github.com/charlie-labs/daemons- reference docs: https://docs.charlielabs.ai/daemonshappy to answer questions. all feedback appreciated.
razvanneculai: Looks pretty interesting, will try it out and give you feedback! keep up the good work.
rybosome: Very fair question.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. --- Note the lack of any code or required knowledge of GitHub webhooks.
rdme: How would this work? One would connect it's repository to a cloud platform that would then act based on the existing daemons of the repo?
rybosome: That's exactly right. Our cloud-based agent Charlie (https://charlielabs.ai/) supports this, and our hope is that other platform providers will offer support in the future as well.Skills live in the repository, so it felt like a natural complement. It also lets other developers see what the active daemons are and collaborate on them. With proper context, agents are quite good at writing and editing these daemon files too.
