The file-conflict question is the hard one. We ran into this building agent-coordinator (https://github.com/mkalkere/agent-coordinator) — our answer was lease-based file locks that auto-expire even if an agent crashes, backed by atomic task claiming in SQLite (INSERT...SELECT). Each agent gets its own git worktree, so conflicts never reach the shared branch at all. Ordering constraints emerge naturally: if agent A holds the lock on routes.py, agent B blocks until the lease expires or is released. No .md DSL needed — it's just HTTP. Curious whether Daemons will go that direction or stay with the "be good at additive contribution" approach.
- daemons are specified by a DAEMON.md file in the repo (like skills). it's version-controlled and team-owned, not hidden in a dashboard or linked to a single developers account.
- daemons have a specialized event pipeline that joins similar webhooks events into a single daemon activation and can inject late arriving events into a daemon that's already running (this is key to avoid duplicate work and noisy actions).
- the watch conditions are a more powerful activation method because they use semantic matching and can be mixed with cron schedules.
- daemons have access to the logs from their past runs (and soon proper memory) so they can learn from their own mistakes.
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?
I'm curious if evals of the DAEMONs and replays for debugging are on the roadmap?
I looked but did not see any facility for collecting/managing evals in the Charlie docs.
Docs drift might sound easy for agents but after working on it at https://promptless.ai for about two years, it's been tricker than just "make some skills". We've got an agent that watches PRs and suggests docs changes. Getting the suggestions good enough that doc owners would actually accept them took a fair bit of evals. Non-ai voice matching existing content, and even "simple" act of deciding whether a given PR warrants a docs change at all.
I have benefited greatly from evals catching things (especially as models change) to the point where I'm loath to go back.
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.
Yes, once you've connected your GitHub (or Linear) then an issue is a good place to start talking to Charlie. Slack is good as well, but we typically do our meaty work through issues internally, since the conversation often evolves and Slack becomes a bit crowded for in-depth discussions.
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.
the hook model is event-driven - something happens, hook fires. daemons sound like they're proposing a different mental model where you have persistent processes that observe and react. the difference is the same as cron vs a running service. both work but the daemon approach makes sense when you need stateful observation across multiple events rather than just per-action triggers
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.
Seems the markdown input, code output is a very common theme, I use OpenSoucreContracts(https://github.com/s1ugh34d/osc) to have LLM's build software, but building the harness into the contracts is elegant. Combined with prose I sort of have this. With LLM's and the sandbox life, software generation is coming.
compared to routines:
- daemons are specified by a DAEMON.md file in the repo (like skills). it's version-controlled and team-owned, not hidden in a dashboard or linked to a single developers account.
- daemons have a specialized event pipeline that joins similar webhooks events into a single daemon activation and can inject late arriving events into a daemon that's already running (this is key to avoid duplicate work and noisy actions).
- the watch conditions are a more powerful activation method because they use semantic matching and can be mixed with cron schedules.
- daemons have access to the logs from their past runs (and soon proper memory) so they can learn from their own mistakes.
I looked but did not see any facility for collecting/managing evals in the Charlie docs.
Docs drift might sound easy for agents but after working on it at https://promptless.ai for about two years, it's been tricker than just "make some skills". We've got an agent that watches PRs and suggests docs changes. Getting the suggestions good enough that doc owners would actually accept them took a fair bit of evals. Non-ai voice matching existing content, and even "simple" act of deciding whether a given PR warrants a docs change at all.
I have benefited greatly from evals catching things (especially as models change) to the point where I'm loath to go back.
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.
- example daemon files: https://github.com/charlie-labs/daemons
- reference docs: https://docs.charlielabs.ai/daemons
happy to answer questions. all feedback appreciated.
It seems like everything is telling me to talk to Charlie to get setup. _How_ do I talk with Charlie?
Are the two competitive or additive?
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.
there's details on how other platforms can support it here: https://ai-daemons.com/spec/#provider-guide
"Complete non-determinism for everything except the schedule it runs at."
Cool story, but what runs when?
I’m an eng on the team that built this, in full disclosure.
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.
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.
Note the lack of any code or required knowledge of GitHub webhooks.I feel like they can. cron and git hooks have existed for a long time.
> Daemons are self-initiated — they observe the environment, detect drift, and act without a prompt.