The server will fail. What matters is what survives it.

It is ten past two on a Tuesday night. An AI agent has worked on a long job for forty minutes. Then the server restarts. Perhaps an update, perhaps a full disk, perhaps the host moved the machine.

In the morning, someone sees the job did not finish, and starts it again. The job runs from the top, and a customer gets the same email twice.

None of this is rare. Nobody did anything foolish. This is what happens when a system meets an ordinary night.

One team reported that a single incoming call started a paid pipeline two or three times. Another found that a long tool call ran a second time after a retry, so the work and the cost doubled. A third saw an agent repeat a write it had already made, and an outside system got a duplicate. One team found, after their host moved the server, that their database was months old.

The details differ. The lesson is the same. A server that runs AI agents will stop one day, at a time you did not choose. The useful question is not how to prevent that. It is what is still there afterwards, and what happens twice.

An AI agent does not only write text. It acts on other systems through tools (see what an AI agent is). So a stopped server puts three things at stake. Keep them apart.

• The run in progress. The step the agent was on, and its place in the flow.
• The record. What the system wrote down: which steps started, what each one received and returned, which errors came up.
• The side effects. What the run already did outside: the email that left, the payment that was taken, the row written in another system.

These three do not behave the same way after a restart. A plan that treats them as one thing will fail on the one it forgot.

EpicStaff runs on your own infrastructure, so you decide when backups run and where the copies go. Run records live in your own PostgreSQL database. Back up the file store and the media volume too. Uploads and the files a run produces sit in a separate file store, and that store needs its own backup. If you back up only the database, you can restore a run record that points to files you no longer have.

The run record is written by EpicStaff as each step and tool call happens, not summarised afterwards by the model. When the server stops, the record already holds the work up to that moment. EpicStaff saves each step's start as it happens, so a run that hangs still shows the last step that started. After a restart, read that line first.

You also keep the flow. Each run keeps a copy of the flow exactly as it ran. Later edits do not hide what the broken run was doing. You can save named versions of a flow and restore an earlier one. A normal save does not create a version, so save a named one before you change a flow that runs at night.

More on what a run record should hold: The agent finished. Nobody can say what it did.

If the server restarts during a run, the run does not continue; it is marked as expired, and you start it again. Until its time limit passes, the run still shows the status "running". So after a restart, "running" does not mean alive. Wait for "expired".

You cannot restart a run from the step that failed. A new run starts from the beginning.

This shapes how you build. These points help on any tool:

• Keep long work in smaller flows. A restart then costs one short flow, not an hour of work.
• Put cheap, read-only steps first, and the steps that act on other systems last.
• Plan updates and restarts outside the hours when long runs go.

EpicStaff does not stop a step from running twice, so actions such as payments or emails need their own duplicate check. A new run from the beginning means that every step that acted outside acts again.

A duplicate check has two common forms.

The first is an idempotency key. The term is technical; the idea is not. You give each real-world action a unique label, made from data that does not change between tries. For example: the order number plus "invoice-email". You send the label with the action. If the receiving service has seen that label before, it does not do the action again. Many payment services accept such a key.

The second is a "did I already send this?" lookup. Before the step acts, it looks in a small table of its own: is this label already there? If yes, it skips the action. If no, it acts, then writes the label down. If the server stops between the action and the note, one duplicate is still possible. Where that matters, also ask the receiving system before you act.

Put the check in the code that does the action, not in the agent's instructions. A model can ignore an instruction. A lookup in code does not.

One planned restart teaches more than a month of reading. Use a test setup, a test mailbox and test data. Run these steps on any tool, ours included. EpicStaff's answer stands under each step.

1. Start a long run, then restart the server in the middle. Does the run continue? EpicStaff: no. If the server restarts during a run, the run does not continue; it is marked as expired, and you start it again. Note how long the run shows "running" before it is marked as expired.
2. Open the record of the broken run. Does it show how far the run got? EpicStaff: yes. EpicStaff saves each step's start as it happens, so a run that hangs still shows the last step that started.
3. Try to start again from the failed step. Can you? EpicStaff: no. A new run starts from the beginning. List the steps that would act again in other systems.
4. Run a step that sends an email, twice. Does the tool stop the second email? EpicStaff: no. EpicStaff does not stop a step from running twice, so actions such as payments or emails need their own duplicate check. Add the key or the lookup, run the step twice again, and count one email.
5. Restore last night's backup on a spare machine. Are the records there, and the files? EpicStaff: run records live in your own PostgreSQL database. Back up the file store and the media volume too. Restore all three. Open an old run, and open one file it produced.
6. Check which flow ran. Can you see the flow as it was, and go back to an earlier version? EpicStaff: yes. Each run keeps a copy of the flow exactly as it ran. You can save named versions of a flow and restore an earlier one.
7. Write down the result. Who starts runs again after an incident? Who checks the side effects first? When is the next drill? EpicStaff: this part is yours. It describes your team, not the software.

The server will fail. When the drill has run once, the morning after is routine work, not an incident.