One of the first architectural decisions about an agent is whether it should live between tasks. It is also one of the decisions most often made by accident: a framework's default, or a demo that happened to run as a long-lived assistant, quietly becomes the production design.
The choice shapes almost everything that follows — testing, cost, security, memory, monitoring and governance. This note sets out the two shapes, argues for a default, and describes the pattern the Guild recommends when an agent genuinely needs to persist.
Two shapes
An ephemeral agent is created for one task. It receives the inputs and context the task needs, does the work, returns a result, and disappears. Anything that should outlast the task is written to a system of record before it ends.
A persistent agent has a lasting identity and lasting responsibility. It owns a queue, keeps commitments over days or weeks, watches for signals, and acts without being asked — on a schedule, on an event, or because a promise it made is due. It remembers things between tasks.
| Ephemeral | Persistent | |
|---|---|---|
| Lifetime | One task | Ongoing |
| Starts because | Someone or something asks | A schedule, a signal, a due commitment, or a request |
| State | Passed in; results written out | Kept between tasks |
| Memory | None of its own | Selected, with provenance and expiry |
| Credentials | Short-lived, scoped to the task | Long-lived identity; credentials rotated |
| Typical failure | A bad run | Slow drift, or silently stopping |
| Testing | Replay the task | Replay the task, plus behaviour over time |
| Governance | Mostly at the template | At the template and the running instance |
Default to ephemeral
Most agent work is a request followed by a result: classify this, draft that, resolve this ticket, reconcile that invoice. For this work the ephemeral shape has every advantage.
- It is reproducible. The same inputs, instructions and tools can be replayed, which makes evaluation straightforward and failures diagnosable.
- It contains damage. A bad run ends with the task. Nothing carries a mistaken belief into the next customer's case.
- It scales simply. More work means more instances, and no instance depends on another.
- It keeps credentials short. Access can be granted for one task and expire with it.
- It costs nothing when idle. You pay when there is work.
The complete guide to AI agent architecture puts the rule in one line, and it is worth repeating: default to ephemeral; make an agent persistent when the work genuinely continues.
When persistence earns its keep
Some work does not end when the response is sent. Persistence is justified when at least one of these is true:
- Commitments over time. The agent promised to follow up on Thursday, chase a document, or check that a payment arrived.
- Watching. The value lies in noticing something — a queue backing up, a metric crossing a threshold, a contract approaching renewal — without anyone asking.
- Ownership of a queue. The agent is responsible for a stream of work with service levels, not for a single item.
- Waiting on people. The task pauses for an approval or a customer reply that may take days, and must resume with its context intact.
- Continuity that matters to people. The customer or colleague expects the agent to know what was agreed last time.
If none of these applies, persistence adds cost and risk without adding value.
Persistent in name, ephemeral in execution
Here is the design the Guild recommends, and the most important idea in this note: a persistent agent does not need a process that runs forever. Persistence is a property of identity, responsibility and state. Execution can still happen in short, ephemeral runs.
The pattern has four parts.
- Durable state outside the model. The agent's queue, its open commitments, task checkpoints and any memory live in stores built for them, with provenance and expiry — not in a context window that has been running for a week.
- Triggers instead of loops. A schedule, an event, a due commitment or an approval decision starts a run. Nothing polls in an endless loop.
- Each run is fresh. It loads the state it needs, acts, writes back what changed, and ends. It uses the current version of the instructions, tools and model.
- Checkpoints and idempotency. Each step that changes something outside the agent is recorded before the next begins, and carries an idempotency key, so a run that fails halfway resumes rather than repeats. A retried run must never send the second invoice.
This gives you the usefulness of a persistent agent with most of the safety of an ephemeral one. Every action can be replayed and evaluated like a single task. A bad run still ends. And because nothing lives only in memory, pausing the agent, upgrading it or moving it is an operational routine rather than a surgical procedure.
Merlin note — When someone asks me for an agent that "is always on", I ask what it should do at three in the morning when nothing is happening. If the honest answer is "nothing", it needs triggers, not a heartbeat that burns money while it waits.
What persistence costs
Even with the pattern above, a persistent agent brings obligations that an ephemeral one does not.
- Lifecycle. Persistent agents have to be created, versioned, paused, retired and handed over. Each needs an entry in the agent register and an owner.
- Memory hygiene. Whatever it keeps between tasks will go stale. Memory needs a write policy, provenance, expiry and a way for people to correct it; Memory is not a database covers this in detail.
- Version drift. Over a long life the model, the instructions and the tools will change underneath the agent. Record the version of each with every action, so that "which agent handled this case?" always has a precise answer.
- Silent failure. An ephemeral agent that fails, fails loudly, in front of whoever asked. A persistent agent that stops simply stops, and its commitments quietly lapse. It needs a liveness check: something outside the agent that notices when expected work did not happen.
- Credential lifetime. A standing identity holds standing access. Rotate its credentials, scope them to what the agent actually does, and make revocation a single step.
Governance differs too
For ephemeral agents, governance lives mainly at the template: the instructions, tools, limits and evaluation thresholds are versioned and reviewed, and every instance inherits them. For persistent agents, the running instance needs governance of its own: a named owner, a pause switch that works without a deployment, scheduled review of what it remembers, and autonomy granted per action rather than per agent. The Citadel trust model applies to both, but a persistent agent will usually spend longer at each level, because its behaviour over time is part of what is being judged.
In the Citadel, the agent layer holds roles, tools, memory and limits, and the Agent Console answers a question that matters most for persistent agents: which agents are active, capable, healthy and within policy?
A worked example
Illustrative example, not a client engagement.
A finance team wants help with overdue invoices.
The ephemeral part is straightforward. When the accounting system emits an "invoice overdue" event, a run starts with the invoice, the customer's payment history and the reminder policy. It drafts the appropriate reminder for a person to approve, or sends a routine first reminder within its limits, and ends.
Then a customer replies that they will pay on Friday. That promise has to outlive the run. It is written to the accounting system as a dated commitment against the invoice, not kept in the agent's memory. On Friday a scheduled trigger starts a new, fresh run, which checks whether the payment arrived and either closes the commitment or drafts the next step.
To the finance team this looks like one persistent "collections agent" that remembers what customers promised. Architecturally it is a named identity, a queue and a set of commitments held in the system of record, worked by short runs that can each be inspected, replayed and evaluated.
A decision checklist
- Does the work continue after the first response is sent?
- Must the agent act without being asked — on a schedule, a signal or a due commitment?
- Does it need to remember something that the systems of record do not already hold?
- Would anyone notice, quickly, if it stopped?
- Is there a named owner for the running instance, and a pause switch that works?
- Can each run be replayed and evaluated on its own?
If the first three answers are "no", build an ephemeral agent. If any is "yes", make the agent persistent in identity and state, keep its execution ephemeral, and make sure the last three answers are "yes" before it goes live. Designing this split is part of the reasoning-system work described on the AI engineering page.
