Most agent examples finish in one request. An input arrives, the model decides, a tool is called, and the response appears on screen.
Operational work can last for hours or days.
A shipment exception may wait for a carrier response, then for an operator decision, then for a customer acknowledgement. An invoice mismatch may pause while a supplier sends a corrected document.
That makes workflow durability a product requirement, not an infrastructure detail.
Event ──> Decide ──> Request sent ──> Wait ──> Response ──> Execute ──> Verify │ │ │ └── Re-evaluate ├── Timeout ├── Retry └── Escalate └── Reconcile
At any point, the service may restart or a newer event may change the case. The workflow has to resume from recorded business state, not from whatever a process happened to hold in memory.
A case must survive the process that handles it
The runtime needs to persist the state of the case, the events it has seen, the decisions it has made, and the actions it has attempted. It cannot rely on one in-memory chain of function calls.
For each step, the system needs to know whether it has not started, is in progress, is waiting, completed, failed, or requires another event. State transitions should be explicit and recorded with the workflow version that caused them.
This is the foundation for resuming work after a process restart and for explaining why a case is currently waiting.
Persisting only the latest state would be simpler, but it would erase how the case arrived there. Proxima keeps the transition history because recovery and explanation both depend on it. The cost is more storage and more careful state design; the benefit is that operators and engineers can reconstruct the workflow without guessing from application logs.
Duplicate delivery is normal
Webhooks and message systems commonly provide at-least-once delivery. A source may retry because it did not receive an acknowledgement even though Proxima accepted the event.
The runtime therefore needs an event ID and a deduplication policy. Seeing the same event twice should not create two cases or send two customer messages.
Action execution needs its own idempotency boundary. Two different events may legitimately propose the same action. The adapter has to determine whether they represent one retry, an updated instruction, or two separate operations.
There is no universal key for this. A notification, refund, escalation, and inventory update have different notions of sameness. The workflow and adapter contracts have to make that choice explicit.
Trying to solve duplication once at the event boundary is not enough. The same business action can be proposed by two different events, and one event can legitimately produce several actions. Deduplication therefore exists at both the event and execution layers, with different identities and policies.
Retries require judgement
An HTTP timeout does not tell us whether the target system completed the request. Blindly retrying may duplicate the action. Giving up may leave the operation incomplete.
A durable execution path records the attempt, request identity, target response where available, and retry policy. Some adapters can query the target by idempotency key before trying again. Some actions can be repeated safely. Others need reconciliation or an operator.
Retries also need limits and backoff. A broken credential should not generate thousands of calls. A carrier outage should not turn every open shipment into an immediate incident storm.
Waiting is part of the workflow
Many operational cases are waiting for something: a document, a reply, an approval, or a time boundary.
Waiting should be represented as state, not as a sleeping process. The case records what it expects and when it should wake up. A matching event can resume it. A timer can create a follow-up event if nothing arrives.
This is especially important for service levels. A case may be healthy when the first request is sent and become urgent two hours later. Timers allow the workflow to change its decision as the remaining window narrows.
Partial failure changes the business state
Suppose Proxima updates a carrier instruction and then fails to notify the customer. The workflow has not simply failed. One external side effect has happened and another has not.
The runtime needs to preserve both facts. Depending on the workflow, it may retry the notification, create an operator task, or run a compensating action. Marking the entire process as failed loses the information needed to recover.
This is why actions need individual lifecycle records rather than one success flag on the case.
Human work is also asynchronous
An operator review is not a pause outside the system. It is a workflow step with an assignee, status, evidence, deadline, and result.
The case should continue when the review decision arrives, just as it would continue after a webhook. If the review times out, the workflow may escalate or reassign it. If the underlying case changes while it is waiting, the proposal may need to be recomputed before the operator acts.
Treating human steps as first-class events makes mixed human and automated workflows much easier to operate.
It also avoids building a separate human queue beside the workflow engine. The review is part of the same case history, so a later decision can use who reviewed it, what they changed, and whether the underlying facts changed while it waited.
Replay needs side-effect boundaries
Durability also enables replay, but replay must not repeat external actions.
Proxima separates decision computation from action execution so historical events can run through a workflow version without calling production tools. The replay produces decisions and proposals in an isolated context. Those results can be compared with the original run or historical outcomes.
This boundary is useful during development, incident investigation, and workflow upgrades. It allows the team to ask, “What would the new version have done?” without doing it.
The model is only one step
A language model call may take seconds. The operational process around it may take days and cross several unreliable systems.
Durable state, event identity, retries, timers, action records, and recovery logic are the engineering that keeps that process coherent. Without them, an agent can make a good recommendation and still leave the operation in a worse state.