Human Takeover Must Stop the AI Agent, Not Just the Chat

Consider a customer-support agent handling a damaged laptop return. It has verified the order, generated a shipping label, delegated a stock check to another agent, and queued a refund for approval. The customer asks for a human. The interface changes ownership, but the refund job remains in a worker queue and the stock-check agent continues calling internal tools.

The human sees a chat that appears paused. The system is not paused.

That gap matters because an AI agent rarely lives inside one conversation process. A production workflow may span a model call, a job queue, scheduled retries, browser sessions, function calls, and delegated agents running under separate worker identities. Changing the name beside the chat box does not stop any of them.

A safe takeover protocol needs one enforceable boundary: after takeover begins, no new side effect may cross from the agent into an external system until a human explicitly chooses what happens next. Reaching that boundary takes more than a cancel button.

A chat handoff is not a stop command

In the laptop return, the visible conversation is only the coordinator. The queued refund has already left that coordinator and entered a payment worker, while the delegated stock check has its own task identifier and credentials. A retry service may also repeat a failed warehouse call after a delay.

Those components do not infer that a human has arrived. They need a machine-readable control signal, and every component capable of causing a side effect must honor it.

The dangerous interval starts when the user requests a person and ends when the system proves that execution has stopped. During that interval, a tool call may already be in flight. A payment service might have accepted the refund request even though the agent has not received its response, leaving the coordinator with an ambiguous result: the refund may have happened, or the request may have failed before commitment.

Treat takeover as a state transition, not a user-interface event. A state machine, which restricts a workflow to defined states and transitions, might move through `RUNNING`, `FREEZING`, `HUMAN_CONTROL`, `RESUMING`, and `CLOSED`. The interface should not claim that the human has control while the run remains in `FREEZING`.

Step 1: Put a barrier in front of new work

When takeover starts, the coordinator should first mark the run `FREEZING` in a shared control store. Workers must check that state before claiming a job and again immediately before making an external call. Checking only when a task begins leaves a hole if takeover arrives during model reasoning or data preparation.

The stronger pattern uses a fencing token, a monotonically increasing run number that lets downstream services reject commands from an older execution period. Suppose the laptop-return run began with token 18. Takeover increments the token to 19. A refund request still carrying 18 is rejected even if a delayed worker wakes after the human has taken control.

This requires cooperation from the tool gateway or downstream service. If workers call a payment API directly and that API knows nothing about run state or fencing tokens, the coordinator cannot guarantee a hard freeze. It can revoke credentials, terminate workers, or block network access, but those controls may affect unrelated runs and still cannot recall a request that the payment provider already accepted.

Cancellation is therefore best effort for work in flight. Prevention must be enforced at the point where side effects leave the agent system.

Step 2: Freeze the whole execution tree

The coordinator now walks the run’s execution tree, meaning the parent task and every job it created or delegated. It stops dispatching queued work, cancels scheduled retries, asks active workers to halt at their next safe point, and sends freeze requests to child agents.

Each worker should acknowledge one of several meaningful states. A queued task can confirm that it never started. An active task may report that it stopped before its external call. A tool call can report that the downstream system accepted it.

If the worker died or its network response disappeared, the result must remain `UNKNOWN` until reconciliation establishes what happened.

Do not convert `UNKNOWN` to `FAILED`. In the laptop return, repeating an apparently failed refund could issue a second refund if the first request succeeded but its response was lost. An idempotency key, a stable identifier that makes repeated requests resolve to the same operation, reduces that risk when the downstream API supports one. It does not prove that an operation was canceled.

Delegated agents are a common escape route. If the stock-check agent was launched through another orchestration service, the parent needs both its child run ID and a cancellation interface that returns an acknowledgment. Fire-and-forget delegation cannot support reliable takeover because the parent has no authoritative way to find or stop what it created.

Step 3: Preserve evidence and show unfinished actions

Once workers have responded or the freeze deadline has expired, write an immutable checkpoint containing the conversation, model outputs, tool inputs and responses, child run IDs, current fencing token, and ownership state. A checkpoint is a stored snapshot from which the run can be inspected or resumed without reconstructing its history from memory.

Preserve secrets by reference rather than copying access tokens into the checkpoint. Tool credentials should stay in the credential service, where takeover can revoke or narrow them without exposing them in logs.

The human needs a pending-action manifest, not a raw event stream. For the laptop return, that manifest might say that the shipping label was created, the stock check stopped before querying the warehouse, and the refund request has an unknown outcome. Each entry should carry the business object involved, the requested effect, the latest verified status, and a link to the supporting tool record.

Order matters. Display committed effects first because they may need remediation, then unknown outcomes that require reconciliation, followed by work that was safely canceled. A chronological log alone forces the operator to infer which intentions became real actions, often across retries that look almost identical.

The handoff screen should also state whether the freeze is complete. If one child agent failed to acknowledge, show partial control and disable conflicting human actions where possible. Letting the operator issue a manual refund while the original refund remains unknown recreates the same race under a different owner.

Step 4: Require a recorded resume decision

Human control should be a terminal pause until the operator chooses a next state. Timeouts, page refreshes, or the end of a support shift must not restart the agent.

The operator may close the run and discard unstarted work. They may keep the agent frozen while handling the case manually. They may also resume from a revised plan, but that choice should create a new fencing token and a new execution segment rather than waking every old job.

For the laptop return, the operator first reconciles the refund against the payment system. If it was committed, the operator can close the queued refund task and continue with customer communication. If no refund exists, the operator can authorize a new request with the same idempotency key where supported. The abandoned stock check should not restart unless the revised plan still needs it.

Record who made the decision, which pending actions were retained or discarded, and the checkpoint used to resume. This is useful for incident review, but it also prevents the resumed agent from treating superseded instructions as current context.

Test the protocol at the race boundaries

A takeover test should interrupt the laptop-return workflow at several boundaries: before a worker claims the refund, after the worker claims it but before the API call, while the request is in flight, and after the payment service commits the operation but before the response returns. The expected result differs at each boundary, which is why a single happy-path cancellation test proves little.

Kill a worker during freezing. Delay a child agent’s acknowledgment. Let a retry become eligible while ownership changes. Then verify that the operator sees an accurate status and that no stale worker can cross the fencing barrier.

The protocol adds latency because takeover must wait for acknowledgments and reconcile ambiguous calls. It also adds storage for checkpoints and engineering work at every tool boundary. For a read-only research agent, that machinery may cost more than the risk justifies. For workflows that send money, modify accounts, place orders, or communicate externally, a handoff without execution control is an interface feature rather than a safety boundary.

Questions people ask

Can an

AI agent finish its current task after I take over?

Only if the takeover policy permits that specific task to cross the barrier. The safer default is to stop before the next external side effect, mark any in-flight result as uncertain, and let the human decide after reviewing the pending-action manifest.

Does canceling the main agent stop its delegated agents?

Not automatically. The coordinator needs identifiers for every child run, a way to send each one a freeze request, and acknowledgments showing where they stopped. A delegated agent launched without tracking or cancellation support can remain active after the parent disappears.

What should happen to an API call already in flight?

The system should reconcile it with the downstream service instead of assuming cancellation or failure. If the service supports idempotency keys and status lookup, the operator can establish whether the action committed; otherwise, the outcome may remain unknown and require manual checking.

Should an agent resume automatically after the human leaves?

No. Resume should be an explicit, recorded decision tied to a new execution segment and fencing token. Automatic restart can revive stale retries or instructions that the human already replaced, especially when a shift ends or a browser session expires.