ZH version is available. Content is displayed in original English for accuracy.
The one thing we've noticed over the last 3 months is that the more you use agents, the more work they create. Dozens of pull requests means older code gets out of date quickly. Documentation drifts. Dependencies become stale. Developers are so focused on pushing out new code that this crucial work falls through the cracks. That's why we pivoted away from agents and invented what we think is the necessary next step for AI powered software development.
Today, we're introducing Daemons: a new product category built for teams dealing with operational drag from agent-created output. Named after the familiar background processes from Linux, Daemons are added to your codebase by adding an .md file to your repo, and run in a set-it-and-forget-it way that will make your lives easier and accelerate any project. For teams that use Claude, Codex, Cursor, Cline, or any other agent, we think you'll really enjoy what Daemons bring to the table.
Discussion (24 Comments)Read Original on HackerNews
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.
It seems like everything is telling me to talk to Charlie to get setup. _How_ do I talk with Charlie?
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.
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."
Are the two competitive or additive?
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.> Daemons are self-initiated — they observe the environment, detect drift, and act without a prompt.