An agent writes a report, creates a file and then sends a message. Then the process aborts. On restart, the chat says: “I’m sending the result now.” Has the message gone out? Does the file have to be created again? A smooth conversation history does not answer these questions.
On 19 October 2026, Vercel published durable-harness. The project records agent steps and results so that work can be resumed, and treats interrupted tools differently depending on their replay property. The release is an occasion to think more carefully about the state of work. The example in this article is our own model, not a test we ran on the project.
Intention, call and result are three different things
An intention describes what is supposed to happen next. A started call shows that the work has begun. Only a stored result documents what your own process knows about it. If these levels are mixed up, a restart can easily produce duplicate work or skip something that was never finished.
For the report, the entry “Export done” is therefore not enough. It needs a reference to the input used and to the file actually created. If the source document changes, an earlier export may still exist but is no longer the right result. Reuse begins with clear attribution.
Step: export-17
Input: bericht-v3
State: completed
Result: bericht-v3.pdf
Next step: notificationThis is a readable control card, not an API format. It shows the essential difference between a file name mentioned in a conversation and a traceable result of a specific step. In a real process, the matching file would have to exist in a verifiable way.
A safe restart knows the unclear states
Consider three points at which the process could abort. Before the export, there is no result yet. After the export but before the message, the file can be reused. While the message is being sent, the situation is more difficult: the recipient may already have received it while the confirmation is missing from your own log.
The local state “no confirmation stored” therefore does not prove “not sent”. Blindly repeating the step could turn the uncertainty into a duplicate message. A sensible process marks this step as unclear and checks with the external service, provided that the service offers a suitable status query.
This is exactly where actions differ. Reading an existing file again normally changes nothing for the recipient. Another message, order or payment, by contrast, can trigger a new effect. A durable log does not resolve these differences on the external system’s behalf.
Idempotency is a property of the operation
A repeatable operation should be identifiable in such a way that the same request does not accidentally create a new job. If a service supports a key intended for this purpose, the same logical operation must keep the same key. A key generated afresh on every restart would lose precisely this relationship.
Whether and how this works reliably depends on the actual service contract. An agent framework cannot make an action safely repeatable just by giving it a friendly label. Nor is “exactly once” a free consequence of logs being stored durably.
A small abort test explains more than a successful run
In your own development environment, a harmless exercise suggests itself: first replace the sending step with a local log, interrupt the process at the three points mentioned and look at which states exist on restart. Note in advance which steps may be repeated and which need a check. Do not use real payments or messages for this first investigation.
The insight does not lie in an invented success rate. It lies in being able to name the state boundaries in your own process. Durable-harness is one concrete technical approach to this. A good restart, however, always begins with the same question: what has demonstrably happened, and where do we not yet know?
Sources and status
Research and documentation as of 25 October 2026. Making every harness durable.
