Resume from verified business milestones rather than replaying the earlier browser clicks. Store the accepted brief, action attempts, actual result references and unresolved outcomes outside transient screen assumptions. After sign-in is restored, reread current account and portal state. Check whether staff or the first attempt already completed an action before permitting another one. A durable agent session can preserve context, but it does not by itself prevent duplicate portal actions.
Separate agent continuity from portal continuity
An agent can remember its task while the supplier portal loses its sign-in session. The reverse can also occur: the portal remains signed in while the agent starts with incomplete context. Recovery needs both the accepted task state and verified access to the intended account.
Source: OpenAI Agents API announcement introduced the managed harness in public beta on 10 September 2026 and describes support for long sessions and recovery. That capability does not establish that an external portal session stays authenticated or that a business operation will not be repeated.
Keep the portal’s actual access restoration in the authorised process. The task record should contain account and role references, not passwords, tokens or recovery codes. After restoration, check the entity context before inspecting business state; a valid session under another account is not a valid recovery for this task.
Record milestones that describe business evidence
A checkpoint saying clicked save is weaker than one linking to the verified draft and its accepted fields. Define milestones in terms of observed business state: the correct report was inspected, the draft was created under the intended record, or the required operation remains pending.
Preserve the task brief and version so recovery does not combine old instructions with a new request. When the owner changes the objective, record that change explicitly and decide which earlier work still applies. An expired session should not become an excuse to start the whole task again under a vaguely similar brief.
Source: OpenAI Structured Outputs supports schema-constrained responses. A proposed checkpoint record can require last verified step, attempt reference, outcome and next owner. Its shape does not prove that the milestone happened; populate authoritative evidence from the actual task and system records.
Preserve uncertainty before restoring access
If a session expires after an action request, the operation might already have happened. Record what was attempted and which response or verification is missing. Do not relabel an uncertain attempt as failed simply because the sign-in screen now appears.
Source: OpenAI function calling separates a model-requested action from application execution and returned output. Apply that distinction to the recovery design. Requested, executed and verified are different states, and a missing response does not establish non-execution.
The owner should define how uncertain results can be reconciled. A supported operation reference is valuable; where it is unavailable, an accepted record-match process may be needed. If identity remains ambiguous, recovery stops for investigation rather than generating a new reference and blindly repeating the action.
Reread current state before choosing the next step
Once access returns, inspect the relevant portal record, file or operation view. Another staff member may have completed the request, changed a draft or cancelled the task while the agent was blocked. The saved checkpoint must be compared with that current state.
Recheck values that can change, including selected entity, record version and the proposed action’s fields. A human approval for an earlier draft may no longer cover the current payload. Preserve the difference and obtain the required fresh decision through the accepted process.
Do not rely on the previous screen position. Sorting, filters and portal navigation can change during a session refresh. Re-establish the target using the approved evidence. If the portal cannot provide enough reliable identity or state information, leave the step with the designated manual recovery owner.
Resumable portal-task checkpoint plan
Task/brief version: ______ | Portal/account: ______ | Recovery owner: ______
| Checkpoint field | Evidence to persist in the approved task store | Resume rule |
|---|---|---|
| Accepted objective | Purpose, permitted actions and brief version | Confirm the task remains authorised and useful. |
| Account context | Entity and approved role reference, without secrets | Verify the restored session has the intended context. |
| Last verified read | Relevant fields, source view and observation time | Reread fields that may have changed. |
| Proposed action | Exact target, payload and accepted approval reference | Changed payload or authority requires a new decision. |
| Attempt | Stable task/attempt reference and requested operation | Preserve the attempt even if no response returned. |
| Verified milestone | Actual result reference and accepted state | Do not repeat a milestone already established. |
| Uncertain outcome | Last known stage, missing evidence and owner | Reconcile the portal before allowing another action. |
| Human intervention | What staff actually completed or changed | Resume from verified current state, not the earlier screen. |
| Next step | Evidence supporting the remaining permitted action | Stop when identity, scope or outcome is unresolved. |
| Closeout | Accepted result, reviewer and remaining limitations | State the verified business stage precisely. |
Recovery sequence: restore access through the authorised process; confirm account and task scope; reread relevant portal state; reconcile each attempted action; identify completed milestones; obtain any required fresh decision; then perform only the next still-permitted step. A stored session or checkpoint is evidence to inspect, not permission to replay everything.
Walk through a completed draft and an uncertain save
Consider a hypothetical task that creates an internal draft for a permitted customer record. The draft was inspected and its reference recorded before sign-in expired. After access is restored, the agent finds the same accepted draft under the intended account. It proceeds only to the next authorised review-preparation step and does not create another draft.
In a second hypothetical case, the session expires after the save request but before the result is returned. The checkpoint contains the attempt and unverified outcome. Recovery checks the actual draft list through the accepted matching process. If the correct draft exists, record that milestone. If no reliable result can be established, keep the outcome uncertain for the owner instead of claiming the save failed.
A human-intervention case creates another dependency. While the agent is blocked, staff complete the report retrieval manually. Their handoff records the inspected file and period. The resumed task accepts that verified milestone if it meets the brief, avoiding another generation or download request merely to reproduce the agent’s original path.
In an ambiguous case, two similar drafts appear and the portal provides no clear link to the first attempt. The recovery owner investigates identity. A model’s confidence that the newest draft is probably correct should not close the uncertain attempt or trigger another creation.
Test recovery at consequential boundaries
Use controlled fixtures to interrupt the task before an action, after a request, after a verified result and after a human change. The expected recovery differs at each point. Testing only expiry on a reporting home page misses the uncertainty that matters after a consequential save or submission.
Inspect the task store, attempted calls and actual result evidence during the pilot. A plausible final message is insufficient if recovery performed the same business action twice. Record the fixture configuration and which portal behaviours were represented, along with any limits that need a later authorised check.
Agree how long unresolved work remains available and who monitors it through the information owner’s accepted handling process. No universal retention period or automatic recovery guarantee follows from this plan. The practical aim is a traceable next decision when access or outcome is uncertain.
FAQ about resuming expired portal sessions
Can the agent simply start the task again after login?
Only after checking that no earlier action or staff intervention already completed the relevant work. Replay can create duplicates. Reconcile the accepted milestones and uncertain attempts, then perform only the next permitted step.
Does a durable agent session prevent duplicate portal actions?
No such general guarantee follows from session continuity. Duplicate handling depends on the application and portal operation, verified references and recovery rules. Persistent context supports that design but does not replace business-state checks.
What if the checkpoint conflicts with the current portal?
Preserve the conflict and ask the responsible owner to resolve it. Do not overwrite the earlier evidence or assume the checkpoint is always current. Recheck identity, scope and any approval before another action.
If your business needs help scoping this workflow, explore Custom AI agents, our AI automation services, and the custom-agent workflow guide. The agents and automation comparison and custom AI agent glossary explain the options. To discuss your systems and approval rules, get in touch.