Interrumpir y redirigir a un agente de IA: steering sin perder el trabajo
Interrumpir y redirigir (steering) cambia el rumbo de un agente de IA mientras trabaja. Qué hacen Claude Code, Codex y Cursor y cómo diseñar la recuperación.
¿Por qué hace falta poder interrumpir?
Un agente puede ir en una dirección equivocada desde el segundo paso y seguir durante minutos. Si la persona no puede frenarlo, su única opción es esperar y deshacer después, o cancelar todo y empezar otra vez. Ambas cosas cuestan más que una corrección a tiempo.
Interrumpir también es una señal de confianza. Saber que se puede frenar en cualquier momento hace que la persona delegue tareas más grandes, porque el costo de un error queda acotado.
¿Cuándo frenar y cuándo esperar?
No toda corrección exige una interrupción. Conviene distinguir tres situaciones:
- La corrección puede esperar. El agente va bien, pero detectas un detalle para el siguiente paso. Encólala: llega cuando el paso actual termina.
- La dirección es equivocada, pero el daño es reversible. Interrumpe, conserva lo hecho y redirige. Aquí el deshacer sirve como red.
- El siguiente paso es irreversible. Interrumpe antes de que ocurra, por ejemplo antes de enviar, cobrar o borrar. En un buen diseño esto es casi automático: el sistema pausa antes de ese paso y pide aprobación, como parte del control humano.
Para no confundirlo con otro tema: aquí la persona interrumpe al agente. Cuando es el agente quien interrumpe a la persona, el tema es notificaciones de agentes.
¿Cómo lo resuelven las herramientas hoy?
Según la documentación oficial consultada el 30 de octubre de 2026, las tres herramientas separan “dar una instrucción nueva” de “frenar”, pero con teclas distintas:
| Herramienta | Mensaje mientras trabaja | Frenar | Volver atrás |
|---|---|---|---|
| Claude Code | Enter lo encola; llega a Claude al terminar las llamadas a herramientas en curso, dentro del mismo turno. Ctrl+Enter lo envía ya | Esc detiene la respuesta o la llamada a herramienta y conserva el trabajo hecho; Ctrl+C interrumpe la operación | /rewind o Esc dos veces: restaura código, conversación o ambos |
| Codex (CLI) | Enter inyecta instrucciones en el turno actual; Tab encola para el siguiente turno | La página de comandos no nombra una tecla para detener el turno | Esc dos veces con el campo vacío edita el mensaje anterior y bifurca el chat. Recomienda checkpoints de Git para revertir |
| Cursor | Enter encola hasta que termine la tarea; Cmd+Enter envía al instante, para redirigir | En su CLI, un segundo Enter interrumpe el turno | Checkpoints: restaurar revierte archivos, no mensajes |
Dos matices. En Claude Code, /btw permite hacer una pregunta lateral mientras el agente trabaja sin interrumpir el turno principal; responde solo con lo que ya está en el contexto. Y Cursor describe, además, un seguimiento que dirige al agente sin interrumpirlo: en cursor.com/agents, el botón “Send now” (o Enter dos veces) entrega el mensaje en la siguiente llamada a herramienta, y Tab lo encola para después. En su CLI, Enter dirige la ejecución activa en un punto seguro.
¿Cómo debe verse la interrupción?
Una interrupción bien diseñada responde tres preguntas de inmediato:
- ¿Qué se detuvo? El paso o la herramienta en curso, con su nombre en palabras claras.
- ¿Qué se conservó? Los cambios ya terminados, con su lista.
- ¿Qué pasa ahora? La respuesta o el cambio en curso se descarta, o la instrucción nueva pasa al siguiente turno.
Si la interfaz no muestra qué se conservó, la persona no sabe si puede confiar en el estado. Una lista de tres archivos ya editados da tranquilidad; una pantalla que dice “interrumpido” a secas genera dudas sobre todo lo demás.
También conviene distinguir entre encolar y reemplazar. Encolar agrega una instrucción para después; reemplazar descarta lo que el agente iba a hacer. Las herramientas anteriores lo resuelven con teclas diferentes (Enter y Tab en Codex, Enter y Cmd+Enter en Cursor), y el diseño debe nombrar las dos acciones por separado, porque no tienen el mismo efecto.
¿Cómo se redirige sin perder lo hecho?
Redirigir es dar una instrucción nueva que parte del estado actual, no del inicio. Para que funcione:
- Usa el contexto real. La instrucción debe referirse a lo que el agente ya hizo: “Mantén los cambios en
estilos.css, pero no toquestema.ts”. - No pidas empezar de cero si no hace falta. Un “vuelve a empezar” borra trabajo útil. Pregunta primero qué parte sirve.
- Conserva el hilo. La conversación debe mostrar la corrección junto al paso que la motivó, para que quien revise entienda por qué cambió el rumbo.
Si una redirección no basta, hay que volver atrás. En Claude Code, el rewind restaura el código, la conversación o ambos, y también permite resumir la conversación desde un punto. Sus límites importan: solo sigue los cambios hechos con las herramientas de edición de archivos. Un archivo que solo cambiaron comandos de terminal no se registra, y las ediciones de los subagentes normalmente tampoco se restauran. Para eso está Git; el detalle de cada caso está en deshacer lo que hizo un agente.
Y para reducir la necesidad de interrumpir, existe el modo plan: el agente investiga y propone un plan sin editar tu código, y las ediciones quedan bloqueadas hasta que lo apruebas. En Claude Code se activa con Shift+Tab o con /plan.
Ejemplo
Ejemplo ilustrativo (diseño hipotético, no una herramienta concreta): un agente recibe la tarea de actualizar los textos de un formulario de registro. A mitad del trabajo, empieza a cambiar también los mensajes de error, que el equipo legal aún no ha aprobado.
La diseñadora ve el cambio en la vista de progreso y pulsa el botón de detener. La interfaz muestra: “Detenido en ‘mensajes de error’. Conservados: 4 textos de etiquetas. Pendiente: nada”. Ella escribe: “Deja los mensajes de error como están, solo cambia las etiquetas”. El agente retoma desde ese punto. Si además hubiera llegado a un paso de envío, la pausa previa habría evitado el paso irreversible.
¿Cuándo NO conviene interrumpir?
- Cuando el agente está en un paso que no puede detenerse a medias, como una migración de base de datos, y no hay plan de reversión. Interrumpir ahí puede dejar algo roto.
- Cuando la persona interrumpe por impaciencia, sin una corrección concreta. El agente pierde el hilo y nadie gana nada.
- Cuando la interrupción no deja claro qué se conserva. Es mejor pedir una confirmación corta que detener sin decir nada.
Un hábito más: guarda cada interrupción con el paso exacto en que ocurrió, la instrucción que la siguió y si el agente la aplicó. Si la gente interrumpe una y otra vez por el mismo tipo de error, el problema está en el plan del agente, y conviene corregirlo con modo plan o con mejores instrucciones, en lugar de frenarlo todo el tiempo.
Errores comunes
- Interrumpir sin decir qué quedó conservado.
- Usar la misma acción para encolar y para descartar.
- Pedir empezar de cero cuando solo una parte está mal.
- Permitir interrumpir un paso irreversible sin aviso previo.
- Confiar solo en el deshacer de la herramienta y no tener Git como respaldo.
- No mostrar la corrección junto al paso que la motivó.