Loud. Your finance lead approves a payment run from her phone, taps back to her inbox, and hears nothing further. The next morning she asks whoever looks after the agent what happened to it. Nothing happened to it. Overnight the software was redeployed, which is the ordinary and correct thing to do with software, and her approval arrived several minutes later at a process that no longer existed. She is certain she approved it, and she is right. Every component did exactly what it was built to do, including the one that ended the process.
What went wrong
Waiting is either something written down or something held in a running program, and the difference is invisible until something stops.
Picture the pause as it usually gets built. A piece of work reaches the point where it needs a person, so it sends the question and then sits there, keeping its place: what it has gathered so far, what it intends to do, where it will carry on from. All of that is inside one running program, the way a page you have not saved is inside one open window. The approval, when it comes, is delivered to that program. If the program is still there, the work continues. If it is not, the answer is handed to nobody, and no part of the arrangement is designed to notice.
Restarts are not accidents. Software is redeployed, machines are replaced, processes are recycled on a schedule. A pause with no expiry, which is the right way to wait for a busy human, therefore guarantees that some waits will be longer than the process doing the waiting.
The Cabinet, ArkOne’s reference design for an executive agent, treats the pause as a fact rather than a vigil. The Signature, the step placed in front of anything consequential so that a named person decides it, has one rule that reads at first like a limitation: when the person answers, the run records the decision and stops, and a person restarts it. The gate in front of a set-piece deliverable follows the same rule unchanged. Writing the decision down before anything acts on it is exactly what makes a restart survivable, because there is no live wait left to lose. The Clock, the part that acts when nobody has asked, closes the same gap from the other side: claiming a job and marking it claimed happen in one indivisible step, so a job fires once whichever copy of the software picks it up, and the design runs a single Clock because a second would only race the first. Those settings sit on the Register, and the seventeenth paper sets out the pause, the checkpoint and the ledger behind them. The related absence produces a request that gets no reply at all; there the answer never comes, here it comes and nothing is home.
The record
Suppose a distribution business of two hundred and forty people, with an agent that assembles supplier payment runs and puts each one to the finance lead before anything moves. The business, its people and the evening in question are invented for the exercise.
| Moment | Wait held in the running program | Wait written down |
|---|---|---|
| The agent proposes the payment run | Question sent; the program holds its place | Question sent; the proposal and the state are stored |
| The software is redeployed at midnight | The program ends, and the wait with it | Nothing; the stored state does not care |
| The finance lead approves at six | Delivered to a process that is gone | Recorded as a decision, with who gave it and when |
| The next morning | No payment, no error, no record of a decision | One approved run waiting for somebody to restart it |
Exhibit 1. Illustrative. One approval, given after a restart, reaching a wait held in memory and a wait written down.
Only the second row differs in anything anybody chose. The same question, the same approver, the same answer, the same restart. What separates the columns is whether the decision became a stored fact before anything depended on it still being held in the air.
This is tagged loud, and the reason is worth more than the tag. It is loud because a person was waiting for the output and chased it. That is luck about the task, not a property of the design. Put the identical gap in front of a weekly reconciliation nobody reads until quarter end, or a renewal reminder that was only ever going to be useful on the day, and the same failure makes no sound at all. What you hear is the attentiveness of the person on the other end.
Note also what the ledger does and does not do for you here. A record nobody edits, where a correction is a new entry and the old one stands, lets somebody reconstruct afterwards that the approval was given and the payment was not made. That is worth having, and it is evidence rather than a guard. Reading the gap a week later is not the same as the decision having been written down at the moment it was given.
What happens
The approval is written down the moment it is given, so a restart cannot lose it, and the work resumes from the state the approver was shown.
What your company sees
An approved run waiting to be restarted, with the decision on the record.
What it means for you
The instinct is to ask for the failure to be caught, and a timeout will be offered: if an approval has not been acted on within some window, raise an alarm. Useful, and it treats the symptom. The question underneath is where the waiting lives.
Have somebody restart the agent while a piece of work is paused for an approval, then give the approval. Watch what happens. That test takes minutes, needs no engineer to interpret, and it cannot be answered with a description.
Then ask the follow-up that separates the two designs. After the person answers, does the work carry on by itself, or is the decision recorded and the job restarted. Carrying on by itself is smoother and one step shorter, and it is smoother right up to the moment nobody can say what it carried on from. The honest cost of recording and stopping is that somebody has to come back, which is a real imposition on a busy approver, and what you buy with it is a decision that survives a restart and a second look before anything moves.
Somebody in your company is responsible for knowing which of those two you own, and if the answer has to be discovered by a finance lead chasing a payment, it was not written down anywhere.
Asked plainly
Why would an AI agent ignore an approval you gave it?
Because the thing that was waiting may not have survived long enough to hear you. If the pause is a running process holding its place in memory, then a deployment, a crash or a routine restart ends that process, and the approval arrives to find nothing listening. Nobody ignored you. There was no longer anything there to ignore you.
What happens to an AI agent's unfinished work when the server restarts?
It depends entirely on where the unfinished part was kept. Work whose state was written to storage can be picked up again by whatever starts next, because the state outlived the process. Work whose state existed only inside the running program is gone, and the only sign of it is an outcome that never arrives.
Should an AI agent continue by itself once a person approves something?
There is a real trade. Continuing on its own feels smoother and removes a step for the approver. Recording the decision and stopping means somebody has to come back, and in exchange the decision is a written fact rather than a live wait, so a restart cannot lose it and anyone can say afterwards what was approved and what then happened.