When large language models arrived, the whole industry reached for one shape to wrap them in: you give the model a task, it thinks, it calls some tools, it returns a result. We called that an agent. It is a good shape. It is not the only one.
The thing an agent cannot do
To call an agent, you must already know that you need it. You must know the question to ask. "Review this PR." "Summarize these docs." Every one of those starts with you noticing that there is work to be done.
But a large share of the problems that actually matter are the ones nobody notices until they have already compounded. The error rate that crept up after a deploy. The customer who went quiet two weeks before renewal. The contributor's first pull request, unreviewed for twelve days, who is about to give up.
An agent could analyze any of these perfectly, if you thought to ask it. You didn't, because you didn't know. The value was never in the reasoning. It was in noticing. And noticing requires something that is always present, and allowed to act on its own judgment.
Inversion of control
The difference is structural, not cosmetic. An agent borrows your call stack: you call it, it runs, it returns, it is gone. A demon owns its own loop. The model stops being the thing in charge and becomes a subroutine the process calls, only when something observed is worth reasoning about.
What Unix already figured out
We did not invent the answer. Unix did, fifty years ago. A daemon is a process that runs in the background with no terminal and no one invoking it. sshd does not wait for you before accepting a connection. cron does not ask whether it is time. A daemon is simply there, part of the system's steady state.
And the word is older than Unix. The Greek daimon was a guiding presence. Socrates described his as a voice that never gave him tasks and never commanded, but exercised continuous judgment, mostly to restrain him. Not a servant. A standing presence with a purpose. We took the LLM out of the function-call box and put it inside that loop.
The cycle
Every cycle, the process does exactly one thing. It collects what it can observe, it asks the model a single question, and then it acts, or it waits. Most cycles, it waits.
It remembers what changed, and when
A demon that has watched your repo for a month is worth more than one started this morning. Its memory is not bolted-on retrieval. When a fact stops being true, it does not erase it. It closes that fact's validity interval and opens a new one. History is preserved, and nothing drifts.
What a run looks like
Point a demon at a domain, say the open pull requests on a repository, and it stays there. Most cycles, nothing. When something genuinely warrants action, it acts, with no prompt and no invocation.
An agent could catch any of these, if you thought to ask it. A demon did not need asking.
Four properties, together
None of these alone is new. The combination is. No wrapped agent has all four.
- Always running, never invoked. A real OS process: PID, signals, survives the terminal, restarts on crash.
- Constituted by purpose, not task. No completion state. It does not return. It keeps being true to what it watches.
- Accumulates identity over time. Bi-temporal memory that compounds, not session-scoped retrieval.
- Judgment as its primary mode. Every cycle asks one question: does anything warrant acting? Usually the answer is no.
Run one
It installs as a binary. On first run it asks once which provider should power your demons, then it is quiet until something matters.
$ npm install -g @josharsh/demon-cli $ demon start "watch open PRs on my-org/repo and flag what needs attention" $ demon logs my-demon --follow
That is the whole thing. A process, watching, with a purpose. It will tell you when something matters, and stay quiet when nothing does. We think this is a real primitive, and we think it has been missing. The best way to find out is to run one and see if it notices something you would have missed.