Pausing an AI agent can prevent the next action. It does not settle who owns the work left behind. Before a workflow resumes, the operating team needs an answer to both questions: who is carrying the unresolved item, and who has authority to release the particular restriction?

That is the operating problem explored in Touch Stone Publishers’ COO white paper, Can the operating system carry the exceptions?, part of Agent-Ready Data: The Work Before the Agent. Its cases and records are proposals, not measured deployment results. The practical distinction is worth carrying into an agent-governance discussion: routing work, accepting responsibility and authorizing action are separate events.

The queue can change while responsibility stays put

Consider a hypothetical delivery-exception workflow. An agent may prepare an internal status note, but it cannot notify the customer or amend the delivery record. A disputed instruction sends the item to an exception queue. Supporting material is attached, and the dashboard marks the agent’s drafting step complete.

What has actually been completed? The material is available and the item has moved. Neither fact establishes that a receiving person has accepted the unresolved work, decided the issue or permitted an outgoing notice. If the originating team closes its item at that point, the workflow can lose its accountable owner while every local step appears finished.

In the paper’s proposed arrangement, the originating workflow owner retains the item until a named receiving owner accepts it. That is a proposed design choice to examine against the organization’s actual delegations, not an authority the paper can grant. The important question is whether the handoff has a receiving side that can carry the assigned obligation.

Acceptance is a narrower answer than approval

A receiving person might agree to inspect the evidence without having authority to decide the business issue. Another person may decide the issue but lack authority to restart the agent. Treating either response as a general approval asks one decision to do work it cannot support.

It helps to record the obligation being accepted. Is the person checking a source, deciding how to resolve the exception, correcting an earlier output or carrying the remaining case? A department name alone leaves those differences unanswered. So does an instruction to escalate when no receiving decision has been identified.

The distinction protects the receiving person as well as the workflow. Accepting a source review should not quietly make that person responsible for a customer commitment. Equally, a handoff that nobody accepts needs a visible owner and next decision, rather than a more reassuring status label.

Restart the permitted task, not everything around it

Return to the hypothetical delivery exception. Suppose the source question is clarified, the authorized business owner records a decision and the receiving owner accepts the remaining work. The authorized workflow owner may then have a basis to resume the internal drafting task. That does not, by itself, authorize the customer notice or a change to the delivery record.

This is where the action boundary matters. A decision to restart should identify the task being resumed, the evidence supporting that choice and the restrictions still in place. Permission should travel with that specific task. Otherwise, an apparently routine restart can acquire a broader meaning as it moves between systems or teams.

The same care applies to recovery. Preventing the next notice does not correct an inaccurate note that has already reached an internal recipient. The earlier output still needs a correction owner and follow-through. Some consequences may not be fully reversible; a successful stop is not evidence of complete recovery.

Try the handoff with the people who must carry it

A useful next step is a bounded rehearsal using the roles, evidence and authority intended for the workflow. This is a proposed method, not a validated test of safety. Ask the receiving person to identify the unresolved question, the work they can accept and the decision they cannot make.

Then ask the workflow owner to explain what remains held and what would permit resumption. Keep the original question and task version attached to the item. Record any extra help used in the rehearsal. A route that works only because a project specialist is in the room has not established that the continuing operation can carry it.

There is no universal staffing ratio or acceptable delay supplied here. Review effort, waiting time, intervention and recovery need local observations and locally justified tolerances. Missing observations should remain missing, with their significance explained. A name in an approval box establishes assignment; it does not establish capacity.

Keep the record proportionate

The strongest objection is that this can create another layer of administration. That objection deserves an answer. If an existing case system already preserves the unresolved question, accepted owner, effective hold and restart authority, use it. Additional fields earn their place only when they clarify a decision or prevent unfinished work from disappearing.

Greater autonomy is not the presumed destination. A narrower internal task, continuing supervision, redesign or a hold may be the supportable choice. The decision concerns the operating state the organization can carry, including the people still needed after the agent has finished its step.

At the next review, try one question: if the agent stops today and the original reviewer is unavailable tomorrow, can the next responsible person recover the unfinished work and explain exactly what may resume?

Go further with the COO paper

This article develops one operating implication of the COO paper. The full edition includes the constructed exception case, a more detailed comparison of operating alternatives and a proposed record connecting review, intervention, recovery and resumption. If you are deciding whether a particular workflow can carry its exceptions, explore the full COO white paper, Can the operating system carry the exceptions? The paper offers questions and working records for local examination, not certification or evidence of proven outcomes.