An agent pauses for approval on Friday. A new release changes its state format over the weekend. On Monday, the approval arrives, but the worker cannot read the saved run.
Restarting from the beginning might repeat a purchase, resend a message, or discard a valid review decision.
AI workflow upgrades need a compatibility plan for work already in progress. Treat persisted state, workflow behavior, tool contracts, and approvals as related but distinct versioning problems. The following is a proposed release method to adapt to your orchestration framework.
Inventory the versions inside a running task
Record the workflow definition version, checkpoint schema, relevant tool and adapter versions, and the operation references for completed side effects. Store approval evidence against the inputs it actually authorized.
A model or prompt change can alter future reasoning without changing the checkpoint schema. That does not make the whole workflow semantically compatible. Review whether the upgraded run will ask different questions or act under different assumptions.
Temporal’s safe-deployment documentation describes replay testing against recorded workflow histories. That is a framework-specific compatibility technique, not a guarantee that arbitrary agent state can be resumed by new code.
Choose a migration decision before deploying
Do not silently fill a newly required business field with a guessed default. Missing shipping terms or a missing currency is a business information gap, not just a serialization inconvenience.
Keep an original checkpoint reference when transforming state. Record the transformation version and outcome so operators can distinguish an upgrade problem from a problem that already existed.
| Run condition | Proposed treatment |
|---|---|
| Compatible state and behavior | Resume after validation |
| Old behavior still required | Route to a supported old worker |
| State transform has an approved mapping | Migrate with a recorded transformation |
| Authority or meaning changed | Pause for review or fresh approval |
Test a resume matrix
A database migration that succeeds for idle records can still fail for active tasks. Include runs waiting on external callbacks and runs whose downstream outcome is unknown. Protect sensitive data when assembling replay fixtures.
- Build sanitized or synthetic checkpoints at meaningful pauses: before a tool call, after a submitted write, and while approval is pending.
- Load them using the candidate worker and check field interpretation, not merely successful deserialization.
- Verify that completed external actions are recognized through their execution records.
- Apply the framework’s replay or compatibility tests where supported.
- Exercise the rollback route and confirm that it can read any state the new worker has already written.
Illustrative example: a new currency field
A hypothetical purchasing workflow originally supports one currency. The new release allows multiple currencies and makes a currency field explicit.
An old paused request has an amount but no currency value. The migration can use a documented original workflow setting if it unambiguously establishes the currency. Otherwise, the request pauses for clarification. The model should not infer a currency from the supplier’s name.
If clarification changes the authorized purchase, obtain the applicable approval again. Preserve the old approval as history rather than presenting it as authorization for a different transaction.
Frequently asked questions
Is copying a checkpoint enough to restart on the new release?
No. The new worker must interpret its fields and execution history correctly. Copying bytes does not establish behavioral compatibility.
Can rolling back code undo a submitted external action?
No. Reconcile the external operation separately. Code rollback and business compensation are different decisions.
Should every upgrade migrate every active run?
Not necessarily. Routing some runs to supported older workers may be safer than transforming them immediately. Define maintenance and retirement limits for that approach.
Does replay testing replace outcome evaluation?
No. It checks the compatibility covered by the replay mechanism. Separately evaluate permissions, model behavior, and whether the business task still completes correctly.
Make resumability a release criterion
Start with one workflow that can remain open across deployments. Record its supported resume paths and test them before changing production behavior. Connect this work with LuMay’s tool contract testing so a resumable agent also understands the services it calls.
