A workflow must run for hours and survive process restarts. What matters most in the design?
Why A is the answer
Durable state and checkpoints outside the model
Conversation context is not a durable store. Keep progress in your own storage so that a run can resume after a failure.
In detail
- Conversation context is not a durable store.
- Keep state and checkpoints in your own storage.
- A run can then resume after a failure.
- Make steps safe to repeat, because a restart may run one twice.
Use case
An illustrative scenario, not a real incident.
A nightly data review runs for hours, and a restart loses everything. Saving a checkpoint after each step lets it resume from the last finished step.
See it in different ways
stateDiagram-v2 [*] --> SingleCall SingleCall --> Workflow: steps are known Workflow --> Agent: path depends on findings Agent --> MultiAgent: evals show overflow or specialist failures MultiAgent --> [*]
stateDiagram-v2 state "Step finished" as s0 state "Checkpoint saved" as s1 state "Next step" as s2 state "Restart" as s3 state "Complete" as s4 [*] --> s0 s0 --> s1 s1 --> s2 s2 --> s3: process fails s3 --> s1: load the last state s2 --> s4: all done s4 --> [*]
Key point: Progress lives in your storage, not in the conversation.
Why the other options are wrong
- B. A longer system prompt describing every step that has been completed so far
- A prompt is lost with the process, and it keeps growing.
- C. A very high max_tokens value, so that one request can carry the whole job
- One request cannot carry a job that runs for hours.
- D. Keeping one streaming connection open for as long as the workflow is running
- A connection will not survive a process restart.