The Takeover Decision: Steer, Take Over, or Restart

The published guidance on when to interrupt a coding agent fits in one paragraph. Devin's Coding Agents 101 advises that when "this thing is going in circles," you "should be okay discontinuing that conversation or manually taking over." Our research sweep found that this is essentially the entire vendor literature on the decision: every platform documents how to take over (the rest of this section walks the four-transfer standard those features meet), but only Devin documents when. Yet an operator running parallel agents makes this call dozens of times a day, and makes it three ways. Send a correction and let the agent continue (steer). Enter the agent's machine and finish the work yourself (take over). Kill the session and re-prompt from scratch (restart).

The decision is a triage of what is still worth saving. A running task holds three assets: the plan, the accumulated context, and the code produced so far. Each move preserves a different subset, and each has a distinct cost.

Steer first, because it spends the least

Steering is a message, not a context switch. GitHub's mission control describes the mechanism: you "add steering input right there. The agent adjusts without starting over" (GitHub changelog, Oct 2025). It preserves everything the task has accumulated and costs you one observation and one sentence. Steer when the diagnosis is "right plan, wrong turn": a misread requirement, a wrong file, a test the agent should have run. If you can name the correction in a sentence, the agent can usually apply it.

The failure mode is steering past the point of salvage. A context full of failed attempts biases every subsequent attempt; correcting it turn by turn is the sunk-cost trap. Devin's "going in circles" test is the published heuristic: a loop means the context is no longer helping.

Take over when the last 10% needs hands

Aman Sanger of Cursor states the case plainly: "if it's only 90% of the way there, you want to go in and then take control and do the rest of it" (via agentic-patterns.com). The same source names the risk: "a clunky handoff process can negate the benefits of automation." Take over when describing the fix would take longer than making it, which is typical for finishing touches, judgment-heavy edge cases, and anything you would not trust a written instruction to convey.

The value is measured, once. AgentBay (Alibaba, Dec 2025) built a sandbox where a human can "at any moment, seamlessly take over full manual control" of the agent's session, and reports a relative success-rate improvement of more than 48% for agent-plus-human over agent-only on complex tasks. That is the only empirical quantification of takeover's value we found in the corpus.

Two caveats. First, taking over is only cheap if the transfer is complete: branch, environment, conversation, and process state together, the bar the four-transfer standard sets, and one no shipping product fully meets. Second, the moment you type into the agent's environment, authorship changes, and the audit record must show where the AI's work ended and yours began.

Restart when the context is the problem

Restart looks like the most expensive move because it discards everything. Often it is the cheapest, because a poisoned context taxes every future turn while a fresh prompt starts clean. Restart is rational exactly when the cost of reconstruction is lower than the cost of correction, and the environment model sets that price: with one reproducible environment per task booted from a versioned image, reconstruction costs seconds, not an afternoon. Teams on hand-rolled setups under-restart for the same reason teams with slow CI under-test.

The fourth move: a direction for the task that is not running

Steer, take over, and restart all assume a live session: a process to watch, a machine to enter, something to kill. A step-based workflow engine produces a case none of that covers: a task that is not running at all. It parked at a human approval gate, or a step failed and the engine halted, and the turn that produced the problem already terminated.

The correction for dormant work is asynchronous: post a direction to the task, and the engine re-runs the step.

• Standing instruction. Persisted on the task and re-injected into every future automated attempt. Use it for constraints that must survive retries: "do not touch the billing tables," "target the v2 endpoint."
• One-shot note. Applied to the next attempt only, then consumed. Use it for facts about this failure: "the red test is a flaky fixture, rerun it."

The primitive is persist-and-replay, not live-session transfer. The engine pins the branch, the environment definition, and the step history to the task rather than to any session, so the next attempt boots fresh carrying the standing direction, the triggering event, and a narrative of prior attempts and why each failed. None of the four transfers apply, because they exist to hand a human a running machine.

The attribution problem disappears with the session. Live takeover corrupts the audit record unless the control transfer is a logged event, and no shipping product writes that event today. A direction is that record by construction: a timestamped, attributed entry stating who intervened, with what instruction, applied to which attempt.

Whatever you choose, say so

A 2026 study from KAIST (arXiv

.02050) found that agents cannot tell whether a human's direct action is feedback or an independent contribution; concurrent human action appeared in 31.8% of turns in its visible-execution study, and stock agents misread it. A silent takeover leaves the agent, on resume, guessing what your edits meant. The fix is protocol, not model quality: the takeover and the return are both explicit events, which is the subject of the next page on mixed-initiative work.

This framework is ours, not measured practice

Outside Devin's single paragraph and scattered practitioner talks, no published source ties the steer/take-over/restart decision to task state, sunk context, or reconstruction cost. Birgitta Böckeler's exploring-gen-ai series documents the constant need to "intervene, correct and steer," but stops short of a decision rule. The triage above is this handbook's prescription, not measured industry practice. Hold it loosely and instrument your own numbers: how often each move is chosen, and how often a steer should have been a restart.