The session held the case
An agent request ends and takes the working context with it. The next person or process has to reconstruct what happened and what was still required.
Benefit / Delivery & Operations
Crashes, timeouts
and three-day waits.
The work carries on.
Business work outlives a model call, an agent session and the service handling the request. Frozion retains the case, its decisions and its next step so an interruption does not send your team back to the beginning.
Record the state. Resume the work. Reconcile uncertain effects.
FROZIONExecution FabricGoverned from request to outcome
- Monday / proposal recorded
The agent request ends. The business case remains.
- Wednesday / evidence arrives
The case resumes with the document and the required review.
- After a timeout / outcome checked
The ERP confirms the order before the case closes.
Sample case · $68,000 purchase order · waiting is a state, not a lost session
01 / The challenge
Real work waits.
Fragile automation forgets.
A document arrives two days later. A service restarts. A destination times out after applying an update. The process needs to retain what it knows and distinguish it from what still needs confirmation.
A handoff becomes a restart
The reviewer or supplier responds later, but the waiting work has no durable place to resume. Teams create manual follow-ups to compensate.
A timeout invites a duplicate
The destination may have applied the update even though its response never arrived. Repeating the write without checking can create a second business effect.
02 / How it works
A durable case.
A deliberate next step.
Frozion keeps execution state, waiting tasks and evidence connected. Recovery starts from what was recorded, with explicit handling for work whose external effect is still uncertain.
Retain the case state
Persist the workflow’s recorded state and its connected decisions, facts and tasks. A process interruption can resume from a recorded boundary instead of relying on a live agent session.
Wait without losing the context
Hold for a human decision, document or configured event. When the required input arrives, continue with the retained case and recheck relevant authority, facts and conditions.
Keep definition versions connected
Associate running work with its workflow and policy definitions. Publishing a new definition does not make the older case’s decisions explainable only by today’s configuration.
Reconcile before repeating an uncertain write
Keep an operation identity and distinguish an attempt from a confirmed effect. Use destination-supported status checks and idempotency where available. If the result cannot be established, keep the case open for its exception path.
03 / In practice
Three days.
One continuous business case.
A $68,000 purchase order spans an interrupted agent request, a supplier document, a director’s review and an uncertain ERP response.
Purchase order PO-7730 · sample data
Follow the recorded milestones from the first interruption to the confirmed outcome.
Monday / recorded state
The agent request ends. The case does not.
The purchase-order proposal is recorded before the process handling the agent request stops. Recovery continues from that recorded boundary. Work since the last durable boundary may need to run again.
Retained case
- Proposal
- $68,000 purchase order
- Workflow
- Purchasing · version 12
- Recorded state
- Proposal prepared
- Outstanding requirement
- Supplier compliance document
- Next step
- Wait for the required document
Monday–Wednesday / required evidence
The wait has a place in the workflow.
The case waits for the supplier’s document with its proposal and next task connected. A newer workflow definition is published on Tuesday. The waiting case retains its version association; its continuation is governed by its defined change and execution rules.
Waiting state
- Case
- PO-7730
- Required input
- Supplier compliance document
- Definition association
- Purchasing · version 12
- Wednesday
- Document received
- Next step
- Review required evidence and proposal
Wednesday / director review
A late approval is still checked before action.
The eligible director approves the exact proposal with the assurance required by policy. Before placing the order, the workflow checks the relevant authority, evidence and business conditions again.
Decision state
- Proposal
- Approved revision · $68,000
- Required assurance
- FIDO2 step-up recorded
- Evidence
- Required supplier document connected
- Pre-action check
- Relevant conditions revalidated
- Next step
- Protected ERP purchase-order action
ERP timeout / reconcile
No confirmation does not mean no effect.
The ERP call times out after it may have created the order. The case records an uncertain effect and holds another write while the destination’s supported status check is used to reconcile the operation.
Reconciliation state
- Attempt
- A1 · operation identity retained
- ERP response
- Timed out
- Business effect
- Uncertain
- Another write
- Held pending reconciliation
- If unresolvable
- Case remains open for its exception path
ERP result / completion
Close the case on a confirmed outcome.
The ERP confirms that the purchase order was created by the original operation. That result is connected to the attempt and the case closes without issuing a second write. This outcome depends on the destination’s ability to identify and confirm the operation.
Completed case
- Original operation
- Confirmed by ERP
- Purchase order
- Creation receipt linked to A1
- Second write
- Not issued
- Case state
- Completed
04 / By role
Continuity for the work.
Clarity for the people responsible.
A retained case gives each team a meaningful state to work from when the expected path is interrupted.
Operations leaders
See what is waiting, what can continue and what needs investigation. Reduce manual reconstruction after a handoff or service interruption.
Fewer cases starting over.Engineering & reliability
Design recovery around recorded boundaries and explicit external effects. Keep safe retry and destination-specific reconciliation in the workflow.
A defined recovery path.Finance & process owners
Distinguish approved, attempted and confirmed work. An unresolved payment or order remains visible rather than being reported as success.
Completion that means something.05 / Scope and questions
Resume what is known.
Resolve what is uncertain.
Durability is about retaining the work and continuing safely. It does not remove the failure modes of connected services or the need to define a recovery path.
Recovery has a recorded boundary
Persisted workflow state survives the interruption. Unrecorded in-memory work can be lost or replayed, so steps and external actions must be designed accordingly.
External effects need their own checks
Use the destination’s idempotency and status capabilities. Where an effect cannot be confirmed, preserve the uncertainty and hold the case for investigation.
Yes. Durable waiting work retains its case state and required next step instead of depending on a live chat or model session. Relevant conditions are checked when the process continues.
No. Recovery resumes from recorded boundaries, and some work may be replayed. External writes need appropriate idempotency, transaction or reconciliation controls.
The case remains unresolved and follows its configured exception or investigation path. An uncertain effect is not treated as proof of either success or failure.
The case retains its definition association. Define and review how existing work should continue or migrate; publishing a new definition alone is not proof that it is safe to change an in-flight case.
Start with one business process
Bring the workflow
that cannot afford to lose its place.
We’ll map its waiting states, recorded boundaries and external effects, then review what happens when a required input or confirmation does not arrive.