Show HN: Daemons – we pivoted from building agents to cleaning up after them
charlielabs.aiFor almost two years, we've been developing Charlie, a coding agent that is autonomous, cloud-based, and focused primarily on TypeScript development. During that time, the explosion in growth and development of LLMs and agents has surpassed even our initially very bullish prognosis. When we started Charlie, we were one of the only teams we knew fully relying on agents to build all of our code. We all know how that has gone — the world has caught up, but working with agents hasn't been all kittens and rainbows, especially for fast moving teams.
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. Looks really interesting -- quick question though: how does this differ from hooks (e.g., https://code.claude.com/docs/en/hooks)? Looks more similar to routines for me (just launched the other day): https://code.claude.com/docs/en/routines simonw is right, daemons are closer to routines. 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. Looks pretty interesting, will try it out and give you feedback! keep up the good work. here are a few more resources: - example daemon files: https://github.com/charlie-labs/daemons - reference docs: https://docs.charlielabs.ai/daemons happy to answer questions. all feedback appreciated. Are other daemons coming and/or will you accept user generated ones? yes and yes. in the meantime, there's a list of use cases to start from here: https://docs.charlielabs.ai/daemons/choosing-daemons Ah that's excellent, thanks. I might try your tool but from my experience PR review and the general state of AI improvement for code is just fu*ing awful. Oh I forgot to ident three lines of code thanks buddy how about this massive memory leak instead that’s of actual value to anyone? Looks incredible neat! I'll give it a try! Congrats! I feel like I must have missed something important, but I don't feel like I skipped anything. It seems like everything is telling me to talk to Charlie to get setup. _How_ do I talk with Charlie? I think I'm supposed to do that on an issue maybe? I'll try that. 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. How does this compare to OpenProse, it looks similar? https://openprose.ai/ Are the two competitive or additive? hadn't seen this before, but it looks like the daemon schedules and watch conditions could be helpful for activating openprose contracts. 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? 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. DAEMONS.md is meant to be an open spec, like skills. there's details on how other platforms can support it here: https://ai-daemons.com/spec/#provider-guide The schedule is cute. "Complete non-determinism for everything except the schedule it runs at." Why couldn't these just be callable skills? 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. 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. 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. 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. > Callable skills can’t activate on a schedule or listen for events I feel like they can. cron and git hooks have existed for a long time. Daemons are autonomous. From the site: > Daemons are self-initiated — they observe the environment, detect drift, and act without a prompt. I can not find a description of how it works on the site, magic hands daemons ! Cool story, but what runs when? tl;dr : https://charlielabs.ai/how-it-works/ and https://docs.charlielabs.ai/daemons to get started, look at https://docs.charlielabs.ai/installation, but essentially 1) signup with your github login 2) install the CharlieCreates GitHub App on the repos you want Charlie to work in 3) create an issue, tag @CharlieHelps to help you create your first daemon! the daemon will run on the charlie runtime and follow the watch / schedule conditions you set in your DAEMON.md file full disclosure: i am part of the engineering team behind this.
Note the lack of any code or required knowledge of GitHub webhooks. ---
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.
---