The answer depends on where the agent's progress is stored. If progress is held in the memory of the process running the agent, that progress is lost when the process dies, and the task restarts from the beginning.
If progress is written to a durable journal as each step completes, the agent resumes from the last completed step, on a different machine if necessary, and the steps that already ran are not repeated.
An agent doing real work is a multi-step process. The agent calls a model, calls a tool, writes a result, calls another model. The process holding those steps can stop at any point: a rescheduled pod, a drained node, a rolling deployment, a dependency that times out.
Most agent frameworks keep the run's progress in the memory of the process executing it. Some add checkpointing, where progress is serialized to an external store between steps. Checkpointing works, and it puts the store in your hands: you operate it, size it, and keep it available. The recovery path is as good as the checkpoint frequency you configured.
Durability can instead be a property of the runtime executing the agent. Every state change is appended to a journal as it happens, so a failure loses no progress.
A task that restarts from the beginning pays for its completed steps twice. The model calls already made are billed again. The tools already invoked run again, and any side effect they caused happens a second time: a payment submitted, a ticket opened, a record written.
The cost of repeating a side effect decides whether an agentic system can act on anything that matters. A duplicated payment is an incident. Teams that hit this build idempotency keys, deduplication tables, and reconciliation jobs around the agent, and then maintain them.
The Akka SDK provides these as runtime properties. State is durable by default and replayable from its event journal, so an agent that fails mid-task resumes from where it stopped. The same runtime handles clustering, failover and rescheduling.
Checkpointing solves part of it. Persisting progress between steps means a failure loses at most the work since the last checkpoint. You still operate the checkpoint store, choose the checkpoint frequency, and handle the window between checkpoints. The recovery guarantee is the one you configured.
The runtime has to record the outcome of the call. Without that record, a resumed run cannot tell a call that never happened from one that succeeded before the failure, and it has to guess whether to repeat the action.
For as long as the thing it is waiting for takes. A run held for a human approval should survive crashes, deployments, and days without polling, replay, or lost state.
A prototype rarely meets it. Prototypes run short tasks, on one machine, with side effects that are safe to repeat. The behaviour starts to matter when tasks get longer, traffic runs concurrently, and the actions touch systems of record.
The component model and runtime where durability and rescheduling are guaranteed.
What a per-service agent stack bills you for, and what removes it.
Who owns the availability SLA, durable execution, and governance.
