When an AI workflow loses access to a connector, restore the authorized connection and reconcile the interrupted work before resuming. A new login does not roll back earlier writes or tell you which requests completed. Restarting the entire task can repeat actions that already succeeded, and the second copy of a sent report or a posted payment is harder to undo than the interruption was.
The operator needs a per-item recovery record: what was attempted, what the destination confirms and what remains unknown. That record determines where to continue. The connection’s status is one input to the decision, not the workflow’s completion status. This guide separates the access problem from the work problem, classifies each interrupted item into one of six states, reads the protocol definitions that distinguish expiry from revocation, walks through a partial batch, and names the reconnections that did more damage than the outage.
- 01Identify the access failure.Expired access, revoked access and insufficient permission are different conditions with different authorized fixes. The error code alone does not say which.
- 02Reconcile prior actions.Read the destination or job record before repeating a write with an uncertain outcome. Reconnecting restores credentials, not knowledge.
- 03Resume by item.Continue known unfinished work rather than assuming the whole batch failed together. One connector failure leaves items in several states at once.
- 04Keep reconnection and replay apart.Restoring access is a maintenance event. Deciding which items may be retried is a workflow decision with its own evidence and owner.
01 — The SplitTwo problems that share one error message
When a connector stops working mid-run, the agent sees one thing: an authentication failure. Behind it are two separate problems. The first is access: why did the credential stop working, and what is the authorized way to get it back? The second is work: of the items the workflow was processing, which finished, which failed, and which are in a state nobody can see? The error message answers neither, and the instinct to “reconnect and rerun” treats them as one.
They have different owners and different evidence. The access problem is resolved by whoever controls the credential, using the mechanism the protocol allows. The work problem is resolved by reading the destination system, item by item, against the record of what was attempted. Solving the first does nothing for the second, and solving the second does not require the first to be solved first; reconciliation can begin from the records while the reauthorization is still with the owner.
“For each item this run touched, what do I know about its state right now, without the connector?” The answer, written down, is the recovery record. Reconnecting before writing it means reconnecting without a plan for what to do once the connection returns.
02 — The StatesRecover from the last known item state
A connector is the integration through which the agent accesses another system. Reconnecting may restore credentials, but the workflow still has its own state. Use the table to classify each affected item, keeping request and destination identifiers where available. These are editorial recovery choices, not a promise that every service exposes the necessary lookup; where a service does not, the item lands in the unknown row and stays there until a person decides.
The first three rows are the comfortable ones: the evidence is clear and the action follows. The last three are where batches go wrong. An unknown outcome is not a failure to be retried; a confirmed write is not undone by the outage that followed it; and a revoked authorization is not a credential problem but a scope decision that has been taken away from the agent.
| Item state | Evidence available | Recovery action |
|---|---|---|
| Never attempted | No request was issued for this item. | Continue after checking access and current task relevance. |
| Explicitly rejected | The response establishes rejection for this attempt. | Correct the access condition, then retry within scope. |
| Pending job | A service identifier points to unfinished work. | Inspect the existing job before submitting another. |
| Confirmed write | The destination confirms the intended item. | Retain evidence; do not repeat merely because access expired later. |
| Unknown outcome | The request was attempted but no reliable result is known. | Reconcile using identifiers; escalate if the state cannot be resolved. |
| No longer authorized | The owner revoked access or changed the task boundary. | Keep completed evidence and obtain a new scoped decision if needed. |
03 — The ProtocolRead the error before calling it expiry
RFC 6750, section 3.1 uses invalid_token for tokens that are expired, revoked, malformed or otherwise invalid. It distinguishes insufficient_scope for requests needing greater privileges. A bare authentication failure therefore does not prove the token simply aged out, and an agent that reports “the token expired” on the strength of invalid_token has guessed. A revoked token and an expired one call for different responses: one is routine, the other is someone’s decision.
RFC 6749, section 6 describes refreshing an access token when a refresh token was issued. It requires validation and does not permit requesting scope beyond the original grant. Reconnection should use an authorized mechanism and the intended account; broadening access is a separate decision, and an agent that fixes an insufficient_scope error by asking for more scope has made that decision on the owner’s behalf.
These protocol rules establish access behavior, not the outcome of prior business actions. The time-limit reference separates credential validity from task deadlines. An access fix may be successful even when the useful time for the original task has passed.
The token is not accepted
One code, four causes. Expiry has an authorized refresh path when a refresh token was issued. Revocation means an owner acted and needs to be asked. Malformed points at the client. The agent cannot tell which from the code alone.
The token is valid but too narrow
Not an access outage. The credential works; the task has reached beyond it. Widening scope is a new authorization, never a retry parameter.
Getting a working token back
The authorized route for genuine expiry: same account, same or narrower scope, validated by the server. Anything else is reauthorization by the owner.
04 — The ExampleResume a partially completed workflow
Consider a hypothetical agent saving a set of reports to a shared review location. Some writes have confirmed destination identifiers. One request was submitted but its response was lost. Later requests are rejected because access is no longer valid. The batch has several states; “connector disconnected” cannot summarize them all, and “rerun the batch” would write the confirmed reports a second time while doing nothing to resolve the lost one.
After restoring access, read back the confirmed items and inspect the uncertain item using its operation or destination reference. If the service exposes a pending job, follow that job. If it confirms rejection before any write, a new attempt may be appropriate within the task’s authorization. If no reliable lookup exists, preserve the uncertainty for an owner decision; the choice between “accept a possible duplicate” and “accept a possible gap” is a business judgment, not a retry policy.
The tool-error reference covers routing a failure response. This recovery record adds the surrounding item history, which is what prevents a single reconnection from becoming an indiscriminate replay.
05 — The IdentityCheck the reconnected account and destination
A login screen can restore a valid session for the wrong workspace or account. Verify the intended identity, resource and required scope before dependent work resumes. A successful read of some folder does not establish access to the folder named in the original task, and a batch resumed into the wrong tenant is a data incident with a perfectly healthy connector.
Preserve the existing task boundaries. A revoked connection may require an owner to reauthorize it, rather than an agent searching for another credential that happens to work. The agent identity guide covers credential ownership; this article concerns recovery after access has interrupted work.
Keep secrets out of the recovery record. Account identifiers, operation references and outcome evidence are useful; raw access or refresh tokens are not required to explain which item remains unfinished, and a record that contains them cannot be shared with the person who has to make the decision.
06 — The FailuresFour reconnections that did damage
Each illustrative case below restored the connection successfully. The harm came from what the agent did next, and each maps to a row of the state table or to the identity check that was skipped.
The full replay: access is restored and the batch is run from the top, so every confirmed write happens twice and the review folder holds two of each report. The scope fix: an insufficient_scope error is “solved” by requesting broader permission on refresh, and the agent now has access nobody granted. The wrong tenant: the login prompt is completed with a credential that works, for a different workspace, and the remaining items are written where no one is looking for them. The retried unknown: the lost-response item is treated as failed and resent, and the destination, which had accepted it, now has a duplicate with a later timestamp that wins the next sort.
Confirmed write, no longer authorized, identity check, unknown outcome. The list is short; these are simply the mistakes a working connection makes easy.
Until an item’s state is known, it may not be retried. “Unknown” is a hold, not a failure. A retry policy that treats a lost response as a rejection has chosen duplicates over gaps without asking anyone.
07 — The SeparationKeep reconnection separate from replay permission
For each item, record the intended operation, last attempt, observed outcome, lookup evidence and next action. If a service supports a documented duplicate-prevention mechanism, retain its original operation key as required by that contract. Do not invent a new key and assume it refers to the earlier request; a fresh key is a fresh request as far as the service is concerned.
An idempotent operation is one whose intended effect does not multiply when the same request is repeated. RFC 9110, section 9.2.2 limits automatic retries of non-idempotent requests unless the client knows repetition is safe or the original was not applied. The exact service contract still matters, and “the HTTP method is idempotent” is a statement about the method, not about what the service does with a second copy.
Finish with a recovery summary that distinguishes completed, resumed and unresolved items. If part of the task no longer makes sense, stop that part and state why. Restoring access is a maintenance event; deciding what work should still happen is the operator’s workflow decision, and the same ownership rule that governs a half-finished task handed between agents applies to a half-finished batch handed back by an outage; our guide to who owns unfinished work sets it out. Teams that want the state table built into their connector error handling rather than reconstructed after each outage can work with our AI transformation practice.
08 — DecisionA restored connection is where recovery starts, not where it ends
Resume from evidence, item by item.
Restore the intended access, reconcile prior attempts and continue the work that remains authorized and useful. Keep unresolved outcomes visible instead of replaying the entire workflow, because an indiscriminate replay can turn an interruption into an incident.
For implementation support, explore our AI transformation services.