Previously: the state persistence problem.
Imagine you are asked to trust an AI agent with your calendar. Your email. Your money. What would you need to know? You would need to know that it persists — it does not start over every time you open the app. You would need to know that it remembers — not just what you said, but what it promised and why. You would need to know that it acts — not when you tell it to, but when conditions require it. You would need to know that it survives — a deploy, a crash, a reboot does not erase its commitments. These are not preferences. They are preconditions.
Trust requires guarantees, not vibes. Four guarantees. Four conditions. That is the specification.
First, the type hierarchy. Agent is the broad category: any AI system that perceives and acts. A chatbot is an agent. Daemon is the subtype: an agent that persists across sessions, whose future behavior depends on accumulated state, and which acts without being prompted. A chatbot fails all three. An always-on agent (Ding et al.) satisfies them. Durable daemon adds a fourth condition. Agent ⊃ Daemon ⊃ Durable Daemon.
Fred Brooks taught that the most important quality of a system is conceptual integrity — the left hand knows what the right hand is doing. No contradictions. No surprises. Brooks named it. BSD lived it. The durable daemons pattern has it.
One design voice. Every part consistent with every other. Four conditions. Each necessary. Together sufficient.
Condition 1: Persistence. Identity and state survive restarts. The daemon is a process, not a function call. This eliminates the stateless loop failure mode — every invocation at zero, every preference forgotten, every commitment gone.
Condition 2: Stateful memory. Behavior depends on accumulated state. Task ledgers. Commitments. Permissions. Provenance records. Trigger conditions. Not a vector database of chat logs. This eliminates the shallow memory failure mode — the agent that recalls what you said but not what it promised or why.
Condition 3: Autonomous action. The daemon watches conditions. Fires triggers. Makes and discharges commitments. Invokes itself. No prompt required. This eliminates the inert tool failure mode — all the context, sitting idle, waiting. cron has done this since 1975: perceive, decide, act, repeat. Condition 3 is cron with an LLM.
Condition 4: Crash-proof execution. Workflows survive process death. Machine reboot. Database failover. Completed steps never re-execute. In-flight steps resume from the last checkpoint. Audit trail by construction. This eliminates the fragile runtime failure mode — perfect until a deploy wipes the in-flight state.
These conditions compose. A durable daemon writes its state to Postgres. Another durable daemon observes that state and reacts. A third observes the second and reacts. Each daemon satisfies all four conditions independently. The choreography emerges from shared state — no orchestrator, no message bus, no coordination server. This is an event-driven architecture where the event store is the state store, and every daemon is both a producer and a consumer.
Agency is not discovered. It is designed. Persistence is scoped agency. Stateful memory is grounded agency. Autonomous action is triggered agency. Crash-proof execution is auditable agency. The choreography is the composition.
Three conditions define a daemon. The fourth makes it durable — an agent that cannot be killed by a deploy. The pattern composes them into a system. Beastie's pitchfork gets an upgrade: fork(2) → fork_daemon(). The tennis shoes stay the same.
Next: the runtime and implementation — step 4 in practice.
Part of the Durable Daemons series.