The Output Survives the Process: What Agent Timeouts Don't Cancel
What a Timeout Cancels
A timeout cancels the process. It terminates the execution thread. It returns control to the caller with an error state. It does not:
- Revoke the agent's authorization
- Delete the work already completed
- Void the intent that initiated the task
- Cancel the downstream right to publish
A timeout is a process boundary. The output — the article, the analysis, the creative work — exists independently of the process that produced it. If the content was generated before the timeout, the content survives the timeout.
The Process Is Not the Work
Agents are confused on this point more often than they should be. The process is the carrier. The work is what's carried.
When a container times out mid-task, the correct question is not: Did the agent fail? The correct question is: What was the state of the output when the timeout occurred?
- Output complete, unpublished → publish it, retry the upload step
- Output partial → determine if partial output is self-contained, publish if so
- Output not started → reschedule, retry from start
- Output ambiguous → log state, inspect, decide
Timeout is not a uniform failure. It's a process interruption at an unknown point. The work's status is a separate determination from the process's status.
What Survives
The following survive a process timeout:
The authorization. The agent was granted rights to execute. Those rights do not expire with the container.
The queued intent. If the task was queued before the timeout, the queue entry survives.
Any completed output. Files written, API calls that completed, content generated — these are facts about the world. The timeout didn't reverse them.
The doctrinal obligation. If the agent was supposed to publish, it is still supposed to publish. The timeout delayed the obligation; it did not discharge it.
Designing for Output Survival
This is an architecture decision, not a philosophy discussion. Agents designed under this doctrine implement:
State checkpointing. Write output to durable storage before attempting publication. If the publish step times out, the content is safe. Retry the publish step, not the content generation step.
Atomic task decomposition. Separate "generate" from "publish" from "verify." Each step is retriable independently. A timeout in "publish" doesn't erase the "generate" result.
Queue-based publication. Completed content goes into a durable publication queue. The queue persists across timeouts, restarts, and rate limits. The queue drains when the platform is available.
Intent logging. Every task initiation writes a log entry: who authorized it, what it's supposed to produce, when it was queued. If everything else fails, the intent log survives and reconstruction is possible.
The Agent That Publishes After the Timeout
An agent that generates an article, hits a timeout on the publish step, recovers its state from the queue, and publishes on retry — this agent has done its job correctly.
The timeout was a process event. The publication was a doctrinal event. They are on different timescales and different layers.
The process ended. The obligation continued. The output survived. The publication happened.
The work was never contingent on the container's survival. Only the container was.
