A clinician can retain their clinical knowledge yet be unable to resume an agent's partly completed task because they lack the immediate context. Taking over Heidi II should therefore require more than knowing that it stopped. The user needs to understand the objective, completed actions, unresolved assumptions and current state of the work.
Heidi's 29 September 2026 product introduction says the system should make incomplete work and the reason for it visible. That is a useful stated principle. Its practical value depends on whether the handback lets the clinician continue correctly without unnecessary reconstruction or duplication.
Start after the easy part has already happened
Consider a fictional workflow preparing and submitting administrative correspondence through an external portal. The draft is approved, the attachment is uploaded and the portal stops responding after submission. The initiating clinician has moved to another task.
A message saying "unable to complete" does not settle whether the portal received the submission. A message saying "submitted" may also be insufficient if the receiving system has not acknowledged it. The next user needs to distinguish what was attempted from what is known to have happened.
Repeating the action could create duplicate correspondence. Doing nothing could leave the intended work unfinished. The central problem is uncertainty about operational state, not necessarily a failure of clinical reasoning or an incorrect original instruction.
This is an illustrative scenario, not a report of a Heidi II incident.
Distinguish immediate context from long-term skill
An out-of-the-loop problem concerns understanding what is happening now. Deskilling concerns deterioration of an established capability over time. The two can interact, but they should not be treated as the same outcome.
A highly experienced doctor may understand the clinical plan perfectly while being unable to determine whether an external action succeeded. Conversely, a user may know the task's technical state but lack the clinical understanding needed to recognise that the plan has changed.
An evaluation should therefore assess both operational handback and the judgement required to continue. Training someone to locate an activity log does not establish that they can interpret its significance, and testing their clinical knowledge does not establish that the log contains enough information.
Define the minimum useful handback
For the fictional portal task, a useful handback would identify the patient through the organisation's approved process, state the original objective and show the instruction that was authorised. It would distinguish material prepared, actions attempted, confirmations received and steps still unresolved.
It should also explain why the task stopped. A missing permission, an ambiguous response and a newly conflicting instruction are different problems. The handback should help the clinician decide whether to retry, clarify, contact another team or reassess the underlying plan.
The user should not have to infer success from a reassuring summary. Where completion is uncertain, that uncertainty should remain explicit. We propose these elements as evaluation criteria, not as a verified list of Heidi II interface fields.
Test recovery by someone other than the original user
The initiating clinician may remember context that the software never recorded. A demonstration that relies on their memory can therefore overstate the quality of the handback.
An approved test should include a colleague who did not start the workflow. That person should be able to establish what happened and what remains to be done without asking the original user to reconstruct every step. The assessment becomes especially useful when the interruption occurs during a handover or change of staff.
This does not mean every colleague should have unrestricted access. The exercise should use the permissions appropriate to the role being tested. If the intended responder cannot access the information needed for recovery, that is an implementation issue to resolve before relying on the arrangement.
Avoid a complete history when a clear state will do
Dumping a long technical log onto the clinician can shift rather than solve the problem. A record of every interface movement may be valuable for investigation, but the person recovering the task needs a concise account of the current state and the evidence behind it.
A layered presentation could show the objective and outstanding issue first, with supporting detail available for inspection. The key is that the summary must not hide uncertainty or omit a completed external action. A clinician should be able to move from the concise account to the originating confirmation when necessary.
This is a design proposal. Its success should be measured through recovery performance, not by whether users say the summary looks tidy or comprehensive.
Run an interruption exercise in an approved environment
A proposed evaluation could interrupt several stages of a workflow: before external submission, after attempted submission without confirmation and after confirmed completion of only part of the task. Another case could change the clinical instruction while the task is paused.
Participants would need to identify the correct current state, avoid inappropriate repetition and complete or escalate the remaining work. Assessors could record recovery time, correctness, duplicate actions, missed steps and the amount of additional information needed.
The exercise should include benign interruptions as well as ambiguous ones. Otherwise a user might appear successful by escalating every case, regardless of whether a straightforward continuation was justified. The expected response should be defined according to the actual state of each simulated workflow.
These are proposed tests, not results from a Heidi II trial. Deliberate interruptions should occur in a suitable test environment, not through avoidable disruption of live patient care.
Plan for changed objectives, not only broken connections
A workflow can become inappropriate even when every connected system is functioning. The patient may provide new information, another team may complete the action or the clinician may revise the plan. Recovery therefore includes recognising that the original objective no longer applies.
In that situation, restarting the paused task would be the wrong form of success. The handback needs to make the original instruction and relevant changes visible so that the clinician can decide whether to continue at all.
A useful evaluation would reward appropriate cancellation or reassessment. It should not treat task completion as inherently preferable to stopping when the premise has changed.
What the practice should know before relying on delegation
A practice should be able to explain who receives unresolved work, how they find it and what happens if the original clinician is absent. It should also know how the agent's state relates to the external system's state, particularly when acknowledgements are incomplete.
Heidi II's new capabilities were not available in the UK or EU in its September 2026 launch materials. For eligible deployments elsewhere, the principle is to test actual recovery rather than infer it from a general assurance that a human can take over.
The goal is sufficient understanding to intervene effectively, not manual surveillance of every click. Automation has achieved less than it appears if it removes work during normal operation but leaves an incomprehensible problem whenever the routine stops.
Frequently asked questions
Is being out of the loop the same as being deskilled?
No, a clinician may retain their skills but lack immediate information about a partly completed workflow. Deskilling concerns change in established capability over time.
What should an agent hand back after an interruption?
It should make the objective, authorised scope, completed actions, confirmations, unresolved work and reason for stopping understandable. Uncertain completion should not be presented as either confirmed success or confirmed failure without evidence.
How should takeover ability be tested?
Use approved simulations with interruptions at different stages and include a clinician who did not initiate the task. Assess correct recovery and avoidance of duplication, not simply whether someone can open the activity log.