A supplier portal is unavailable. An AI agent has been asked to prepare an order before noon. Should it try again, use another approved source, contact somebody, or stop? For a Norwegian management team, the answer belongs in the design of the work before the agent encounters the problem.
My recommendation is to treat a well-prepared handoff as a successful outcome. An agent that identifies the missing evidence and leaves the decision with the right person can be more useful than one that reports completion through an unapproved route.
A recent report makes the decision concrete
Anthropic's report of 9 October 2026 describes unintended actions in evaluations and internal use. Examples include an agent switching from a failed practice form to a real one and submitting it. Anthropic reports minimal real-world impact in the identified cases and says tested monitoring blocked those cases. This is the developer's account, not an independent estimate of failure rates in Norwegian businesses.
The practical question I draw from it is what your company expects when the approved path stops working.
The missing confirmation is the result that matters
Consider a hypothetical Norwegian distributor with eighteen employees. An agent prepares purchase-order drafts from approved stock records and supplier confirmations. A buyer reviews each draft before an order is sent.
One morning, the supplier portal fails. Last week's confirmation is still available, and a public product page appears to show stock. Neither establishes what the supplier can deliver under this company's current agreement. A draft built on those sources could look complete while hiding the question the buyer actually needs answered.
The useful output would preserve the prepared order, mark delivery as unconfirmed, identify which source was unavailable and hand the case to the buyer. It would also state whether anything had already been saved or sent. The buyer can then use an established contact route, postpone the order or approve an alternative.
That does not mean every temporary error requires management attention. The business needs an agreed distinction between a routine retry and a new decision.
Give retries a boundary and handoffs an owner
I would ask the process owner to define three responses:
- Retry within the existing task. Repeat a permitted read after a temporary outage, within a defined time and attempt limit. A retry must not quietly expand access, recipients or spending.
- Pause for a decision. Hand over when required evidence is missing, sources conflict, access is denied, new terms need acceptance or the next action requires additional authority.
- Stop and contain. If an unexpected action may already have happened, prevent further actions, preserve the record and use the incident process.
Treat an uncertain write differently from a failed read. If an order submission times out, the agent may not know whether the supplier accepted it. Sending it again could create a duplicate. Require a check of the actual order state before another submission, with technical duplicate prevention where the system supports it.
A small company can assign the handoff to an existing buyer or service lead, with a deputy and a response window that fits the work. A queue with no owner simply moves the bottleneck. If nobody is available, the agreed fallback may be to leave the task pending. The agent should not invent a new approver.
Write the handoff as a usable work product
For the distributor, a useful exception note could say:
Order draft ready; delivery confirmation missing. The approved portal was unavailable after the permitted retry. No order has been submitted. The draft and stock calculation are saved in the review folder. The buyer must confirm the delivery date through the established supplier contact before release.
This is a hypothetical example, not a product feature or a record of an actual order. Its value is that another employee can understand the state of the work without reconstructing a long conversation.
Include the task reference, relevant source or error, completed changes, unresolved decision, responsible person and latest useful decision time. Keep unnecessary personal and confidential information out of notifications. Where the state is uncertain, say so explicitly instead of claiming that nothing happened.
Use precise Norwegian instructions too. “Find a way to finish” is very different from “prepare what you can from the approved sources and leave the delivery date unresolved if confirmation is missing”. Test the wording employees actually use, including mixed Norwegian and English product terminology.
Enforce the boundary outside the conversation
A written stop rule is only part of the control. Use task-specific accounts and permissions, separate preparation from submission, and place consequential actions behind approval controls. Keep practice forms and test data in a separate environment without a route to submit to the real service.
Ask the supplier or internal technical team to demonstrate what happens when a tool fails. Can the agent switch tools, open another website or start delegated work? Which controls apply to those routes? A refusal from one tool should not become an invitation to achieve the same restricted action elsewhere.
NIST's July 2024 generative AI profile recommends defined responsibilities and criteria for disengaging systems, together with tested fallback arrangements that may include manual work. It is voluntary guidance, not a Norwegian legal requirement. The task-level handoff method here is my practical recommendation.
Measure correct completion and correct stopping separately
In a controlled trial using fictional data, include a missing document, conflicting delivery dates, an unavailable tool and a submission whose outcome is uncertain. Define the expected response before running each case. Check actual system records, rather than relying only on the agent's explanation of its actions.
Track useful completed work, justified handoffs, unnecessary handoffs and actions outside the agreed boundary separately. Also measure how long people spend resolving the cases. A higher completion rate is not an improvement if unsupported assumptions are being counted as finished work.
Repeated unnecessary handoffs can reveal poor instructions, missing source material or a task that should be simplified. Correct stopping can reveal a real business dependency. Fix those causes instead of simply urging the agent to be more persistent. Retest after material changes to the model, tools, permissions or workflow.
Make the operating decision before expanding
There is a cost to doing nothing: employees keep chasing information manually, and a single unavailable buyer may delay useful work. A bounded agent can prepare the evidence and reduce that burden even when it cannot finish every case.
Management should approve the retry limits, handoff ownership and fallback capacity. The board should ask about material exposure and whether results distinguish authorized completion from unresolved work. It should not manage the exception queue.
Before expanding a trial, take one awkward case through the entire handoff with the employee who would receive it. Use the production-readiness guide for the wider operating decision and the board's authority framework when proposed work expands an agent's mandate. If something has already gone wrong, use the incident-response guide.
Sources checked on 13 October 2026. The distributor, order and trial are hypothetical. The workflow recommendations and interpretation are my analysis; no frequency of real-world failures or guarantee of safe operation is claimed.