Agents create work. Daemons maintain it. Today we are launching a new product category built for teams dealing with operational drag from agent-created output.
In our previous post — Charlie V2: Introducing the Coding Agent Operating System (CAOS) — we laid out the runtime needed to run agents safely in real production workflows: durable tasks, delegated execution, guardrails, and native operation across tools. This post is a continuation of that story.
Today, we’re launching Daemons — a new product category built for teams that have moved past early experimentation with using agents and are now dealing with operational drag from agent-created output. If your team is already using agents and feeling the maintenance burden, you can sign up to try Daemons now at charlielabs.ai.
The core thesis is simple: “Agents create work. Daemons maintain it.”
That line captures a shift many engineering organizations are now living through. Agent tooling has dramatically increased output: more pull requests, more generated issues, more alerts, more docs, more dependency change. But output volume is only one side of the equation. The harder side is keeping the systems that require all of that work healthy over time.
Most teams no longer struggle to produce drafts, patches, or proposals. They struggle to keep the system coherent after generation. Stale PRs accumulate. Bug reports miss triage context. Docs drift from source behavior. Dependency updates age out and become riskier to merge. Alert streams become noisy and unactionable.
This is operational debt, and it compounds. Human operators end up doing repeated framing work: noticing what changed, deciding what matters, and turning recurring maintenance tasks into action. The bottleneck is no longer content generation; it’s maintenance throughput.
Daemons are not one-off prompts. A daemon is a persistent role definition that tells the system:
The role is defined once — the daemon keeps running that responsibility over time. Instead of asking an agent to perform the same maintenance task repeatedly, you deploy a daemon that continuously owns that loop.
Just as importantly, daemons are designed to operate inside your existing systems — GitHub, Linear, Slack, and the rest of your operational surface area — with explicit attribution and auditable outputs. This is not unconstrained autonomy. It is scoped, policy-aware maintenance automation.
Daemons are configured through a contract in DAEMON.md, stored under .agents/daemons/<daemon-name>/. The spec at docs.charlielabs.ai/daemons/daemon-md-reference defines the shape and lifecycle.
At minimum, a daemon definition includes name, purpose, and routines, plus at least one activation mechanism: watch and/or schedule.
watch handles event-driven activation (for example, changes in external systems).schedule handles time-based activation.Each activation follows a clear lifecycle: wake, execute routines, complete. Under the hood, runtime responsibilities include event mapping, schedule evaluation, lifecycle state management, and reliable execution semantics.
This matters because maintenance work is not just about calling an LLM. It requires durable state, retries that don’t duplicate side effects, and outputs that land in native team tools where work is actually coordinated.
Daemons are built for operational environments where control and traceability matter. The model includes explicit deny boundaries, action attribution on native platforms, persistent execution context, and idempotent retry expectations.
There is also an important caveat: parts of daemon behavior are model-interpreted. That means safety depends on role quality and boundary clarity, not just runtime mechanics. Good daemon design is explicit about intent, limits, and escalation paths.
For organizations utilizing agent systems at scale, this is the practical path forward: pair high-output generation with first-class maintenance infrastructure.
The value becomes obvious in recurring operational loops:
Each role reduces coordination tax and returns human attention to higher-leverage engineering decisions.
For an up to date view of existing daemons, please see the repository at github.com/charlie-labs/daemons.
Daemons are launching now because the post-agent era is already here. Teams don’t need more ways to generate work; they need reliable systems to keep generated work healthy.
If that describes your current bottleneck, sign up to try Daemons today at charlielabs.ai.
And if you want the implementation contract behind the product, read the spec here: docs.charlielabs.ai/daemons/daemon-md-reference
Charlie V2 is a runtime for durable, multi-step coding work across GitHub, Linear, and Slack. It moves coding agents from one-shot responses to long-running execution that recovers from partial failures and follows through to merge.
Coding agents are moving from chat to systems that execute real engineering work. Charlie V2 is a runtime and infrastructure layer for durable, multi-step software execution.