Idea principal

Un hook enganchado al fin de un turno de conversación, y cuyo trabajo consiste precisamente en llamar al asistente para que resuma el intercambio, se dispara a sí mismo: la llamada que emite termina a su vez, y ese final despierta el hook. El bucle no es un accidente de implementación, es la consecuencia directa del montaje — el autómata emplea la herramienta cuyo final vigila.

El remedio no consiste en evitar la llamada, sino en hacer al autómata capaz de distinguir los disparos que él ha provocado de los que vienen del trabajo real. Claude Code pasa para ello un indicador stop_hook_active en los datos enviados al script, y el script sale de inmediato cuando lo ve, antes de cualquier procesamiento.

Esa comprobación va primero, antes de la lectura del transcript y antes de cualquier llamada al modelo. Un salvaguarda colocado después del trabajo costoso no protege de nada: el bucle ya estaría consumiendo.

Por qué es importante

Es una avería que no se descubre al diseñar, sino al pagar — en tiempo de ejecución, en llamadas facturadas, en sesiones que ya no devuelven el control. Saber que es estructural permite tratarla en el diseño.

Y el patrón reaparece dondequiera que un sistema reacciona a sus propios efectos: un disparador de base de datos que escribe en la tabla que vigila, una integración continua que empuja un commit, una regla de mensajería que responde en el hilo que observa.

Matices y límites

La distinción solo es posible si el entorno la proporciona. Sin una señal de ese tipo, hay que fabricarla — un cerrojo, un marcador, una ventana de tiempo — y esos sustitutos fallan en cuanto dos ejecuciones se solapan.

Y salir ante esa señal tiene un coste: el intercambio interno no se registra nunca.

Preguntas abiertas

• ¿Cómo detectar que una automatización reflexiva está en bucle, si su salida consiste justamente en no escribir nada?