How It Works

How Charlie Daemons Work

Daemons turn incoming signals into verified outcomes—with clear boundaries, required approvals, and durable updates at every step.

Try daemons now See use cases

Clear operating boundaries and policy-driven execution
Human-in-the-loop approvals where needed
Durable artifacts at every major checkpoint

+---------------------------------------------+
| Intake signals from operating systems       |
| GitHub | Linear | Slack | Sentry            |
+----------------------+----------------------+
                       |
                       v
+----------------------+----------------------+
| Guarded daemon run                          |
| context -> scope -> execute -> verify       |
+----------------------+----------------------+
                       |
                       v
+----------------------+----------------------+
| Durable team updates                        |
| PRs, comments, checks, checkpoint state     |
+---------------------------------------------+

Execution Loop

Seven-stage execution loop

From first signal to final update, each stage shows what the daemon does, what evidence it produces, and when people are asked to decide.

Stage	Daemon action	Artifact	Human input
Intake	Receive the signal, understand what changed, and identify where updates should be posted.	Run record with source, scope, and owner	Optional priority or owner override
Context Build	Gather the minimum repo and issue context needed to act safely.	Working context with relevant files and issue state	Asked only if a missing detail blocks safe execution
Plan + Boundaries	Set a scoped plan, clear limits, and explicit approval checkpoints.	Execution plan with scope, constraints, and assumptions	Approval for high-impact or irreversible scope changes
Execute + Delegate	Make the approved change directly or hand off focused steps to specialist workers.	Code updates, worker outputs, and linked task IDs	Preference choice when multiple acceptable options exist
Verify	Run required checks and confirm the result matches the request.	Check output with pass/fail summary	Decision if failures appear unrelated to the current change
Report	Post a clear update with links to what changed and what passed.	Commit and branch links with completion status	Final review + merge decision
Continue	Monitor for follow-up signals and resume from the latest saved state.	Next-step queue with latest run status	New priorities or policy updates

Autonomy + Approval

Autonomy and approval matrix

Routine work runs automatically. When a request affects risk, scope, or customer impact, the daemon pauses and asks for approval.

Scope	Autonomy mode	Approval gate	Notes
Classify incoming work and gather context	Automatic	Not required	Read-only steps only.
Routine metadata updates (labels, assignees, status fields)	Automatic inside policy boundaries	Not required	Blocked if the request falls outside declared permissions.
Code or config edits inside approved routine scope	Automatic after checks pass	Not required unless guardrail says otherwise	Every completion includes verification output.
Broader or riskier changes (new systems, expanded scope)	Pause and ask	Required	The daemon asks one clear approval question before continuing.
Merge/close/escalation actions outside explicit policy	Not allowed by default	Required + explicit allow rule	High-impact actions stay human-controlled unless policy explicitly allows them.

Reliability

Reliability by design

If the same event arrives twice, the result stays clean

Runs reconcile to one outcome, so teams do not get duplicate comments or conflicting status.
Retries are limited and intentional

Temporary API failures trigger bounded retries with backoff instead of noisy loops.
Work can resume after interruptions

Each stage saves progress, so a restart continues from the last safe point.
Escalation is explicit when confidence drops

If required checks fail or context is incomplete, the daemon pauses and asks for a decision.
Approval requests stay focused

When human input is needed, the prompt asks for one decision with clear options.

Control Plane

DAEMON.md policy and execution contract

Use DAEMON.md to define what each daemon can do. Most teams store these files at .agents/daemons/<daemon-name>/DAEMON.md and use the Charlie daemon docs as the source of truth for the schema.

---
name: docs-librarian
purpose: Keep docs aligned with shipped behavior.
watch:
  - when a pull request is merged into the default branch
  - when a Linear issue is mentioned in a comment
routines:
  - detect behavior changes from merged PRs
  - propose docs updates in impacted pages
  - open scoped follow-up tasks when human input is required
deny:
  - push directly to protected branches
  - close incidents automatically
schedule: "0 9 * * *"
---

## Approval
- scope expansion across repos
- publishing externally visible docs

## Verify
- bun run lint
- bun run typecheck

## Report
- artifact links
- pass/fail checks
- questions for caller

Field highlights

watch
Declares which signals start execution and where intake begins.
schedule
Cron expression for recurring sweeps when event-driven watches are not enough.
routines
Defines allowed operations the daemon may perform autonomously.
deny
Hard safety boundaries that always block disallowed actions.
body
Markdown policy that captures approval gates, required checks, and reporting expectations.

Run Artifacts

Example run artifact timeline

This timeline shows the exact record a team can follow after each run, including when human review is expected.

Time	Event	Artifact	Human touchpoint
T0	PR merged with API behavior change	GitHub merge event + commit link	None
T1	Daemon intake + context build	Run record + context snapshot	None
T2	Docs update drafted and verified	Draft branch + verification check results	Optional feedback on wording
T3	Status report posted with links	Thread comment with commit + checks	Review and approve merge
T4	Follow-up work is captured	Queue entry for next actions	Set new priorities if needed