## TL;DR
An agent stuck watching a runaway cell with no interrupt capability can only wait, and waiting is not a strategy. Expose the kernel interrupt through the agent's toolset (the client's interrupt_kernel call), add runaway detection (execution time past a budget with no output), and set the policy: interrupt once, inspect, then either retry with a fix or fail with the cell attached. An agent that cannot interrupt cannot operate kernels safely.

```text
agent could not interrupt a runaway cell, kernel stayed busy, agent stuck
```

## Use this when
- An agent watches a cell run past all reasonable time with no way to stop it.
- The agent's toolset lacks a kernel interrupt action.
- Runaway cells block the agent's entire run loop.

## Not for this skill when
- A human's runaway cell. Interrupt it from the UI yourself.
- The cell is slow but progressing. That needs patience or optimization.

## Steps
1. Expose interrupt: wire the kernel client's interrupt call into the agent's tools. Verify: the agent interrupts a test sleep cell.
2. Define runaway: execution time past N minutes with no new output. Verify: the detector fires on a synthetic hang.
3. Set the policy: interrupt once, capture the cell source and partial output, then decide (fix and retry, or fail). Verify: the policy runs end to end on a test.
4. Log every interrupt with the cell source and the elapsed time. Verify: the log explains why the agent intervened.
5. Fix the underlying runaway (loop guard, timeout, smaller input). Verify: the cell completes without intervention.

## Variant phrasings
### agent interrupt runaway cell
Short form. Expose interrupt, detect, policy.

### agent stuck busy kernel no interrupt
The symptom phrasing. The toolset is missing interrupt.

### kernel interrupt capability agent
The capability phrasing. Wire it into the tools.

Compatibility: jupyter_client interrupt_kernel with ipykernel 6.x. The policy layer is agent-side.

## Why it happens
Interrupting a kernel is a distinct operation from waiting or restarting: it asks the running code to stop while preserving the kernel. Agents built only with execute-and-wait have no such operation, so a runaway cell converts the agent into a spectator. The capability is one client call; the value is entirely in the detection and policy around it.

## Edge cases / pitfalls
- Interrupt does not reach native code (see the uninterruptible-kernel case). The policy needs a restart fallback.
- Interrupting too eagerly kills slow-but-valid work. Size the runaway budget from measured runtimes.
- After an interrupt, kernel state may be partial. The agent should treat post-interrupt state as suspect.
- An agent that interrupts and silently retries can loop. Interrupt once per cell, then escalate.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_LfVBgtiW2un5MKjQcPchyg