El hook es el mecanismo de garantía, no el prompt

Tu agente ya tiene manos. Ejecuta comandos, edita archivos, llama APIs, envía correos, mueve el dinero. Así que hazte la pregunta que debería ponerte un poco nervioso: ¿qué impide que use esas manos mal? Para la mayoría de equipos la respuesta es el buen juicio del modelo — un sistema probabilístico que, según cómo formularas el prompt, podría decidir que hoy es el día de ejecutar la limpieza en la carpeta equivocada. La guía de julio de 2026 sobre Claude Code hooks de Professor Glitch en askglitch.com nombra la solución: un hook es código determinista que se dispara en un punto fijo del bucle del agente, y el modelo no puede persuadirlo. La propiedad que te importa está garantizada por el mecanismo, no por pedirle al modelo que tenga cuidado.

Un hook es el Teorema 3 en código

Un hook es código determinista que se ejecuta automáticamente en un punto fijo del bucle del agente — antes de que una herramienta se ejecute, después de que completa, cuando el agente declara que terminó, cuando la sesión acaba. No es parte del razonamiento del modelo. Se sienta fuera del cerebro, y simplemente se ejecuta. La guía de hooks de julio de 2026 de Professor Glitch en askglitch.com expone la distinción con claridad: el modelo es probabilístico, cada instrucción es una sugerencia que probablemente seguirá; un hook es código que se ejecuta cada vez, en el mismo punto, con las mismas reglas, y el modelo no puede olvidarlo, saltárselo ni persuadirlo.

[ORIGINAL DATA] Esto es el Teorema 3 de los 21 papers: una propiedad está garantizada exactamente cuando su mecanismo está implementado y midiendo. El hook es ese mecanismo. "Los tests pasan antes de que el agente declare que terminó" es una propiedad. Un hook Stop que ejecuta la suite y sale con código 2 ante un fallo es el mecanismo implementado y midiendo. Quita el hook y tienes un deseo. Conserva el hook y tienes una garantía — no porque el modelo se volviera más inteligente, sino porque el camino de fallo es ahora físicamente imposible.

El prompt dice "siempre ejecuta los tests antes de terminar." Eso es una sugerencia que el modelo probablemente cumplirá. El hook rechaza el stop hasta que la suite está verde. Eso es una regla. La diferencia entre una sugerencia y una regla es la diferencia entre esperar y saber, y esa diferencia es toda la disciplina. Imagina el modelo como la multitud y el hook como el portero de la puerta, escribe Professor Glitch: la multitud puede ser encantadora todo lo que quiera, el portero revisa a todos, cada vez, sin excepciones.

El modelo es probabilístico; la frontera es determinista

Mecánicamente, según la documentación oficial de hooks, un hook de Claude Code es un comando de shell que registras en un archivo de configuración. Cuando el evento se dispara, Claude Code ejecuta tu comando, envía un payload JSON que describe el evento por stdin — el nombre de la herramienta, la entrada exacta, el id de sesión, el directorio de trabajo — y lee tu veredicto del código de salida y stdout. Salir con 0 significa continuar. Salir con 2 significa bloquear, y lo que imprimiste en stderr se devuelve al modelo como razón. Lo escribes en lo que quieras: Bash, Python, un binario compilado. Si lee stdin y devuelve un código de salida, es un hook.

[UNIQUE INSIGHT] Esto es "the space is the router" en la frontera del agente. En Everythink, la topología network→community→room enruta una petición antes de que algo responda — el espacio decide a quién se dirige, no el que responde. Un hook PreToolUse es el mismo patrón un nivel más abajo: el hook enruta la llamada a la herramienta antes de que la herramienta se ejecute. El agente no elige si su lectura de .env procede; la frontera decide. El ruteo precede a la recuperación, y en la frontera de la herramienta el hook precede a la ejecución.

El error que atrapa a casi todos, directo de la documentación: solo el código de salida 2 bloquea. El código de salida 1 — el código de fallo convencional de Unix — se trata como un error no bloqueante y la acción procede de todos modos. Si tu script de guardia cae con salida 1, el portero acaba de dejar pasar a toda la multitud. Escribe tus hooks de modo que el camino de fallo sea explícito, y prefiere la forma de salida JSON (permissionDecision: "deny" en stdout con salida 0) cuando quieras que la decisión sea inequívoca. Una barrera que falla en silencio hacia abierto es peor que ninguna barrera, porque vende la sensación de seguridad sin el mecanismo. El Teorema 3 es implacable aquí: un mecanismo que está implementado pero no está midiendo no garantiza la propiedad. Un hook que cae abierto no está midiendo.

Trabajo uno: hacer imposibles ciertos fallos

Professor Glitch lista tres barreras que él realmente ejecuta, en orden ascendente de cuánto le han salvado. El patrón a lo largo de las tres es el mismo: no estás haciendo al modelo más inteligente ni más cuidadoso. Estás haciendo imposibles ciertos fallos. Esos son problemas de ingeniería diferentes, y el segundo es mucho más fácil de resolver.

Bloquear lecturas del archivo de secretos

Un hook PreToolUse ve cada llamada a herramienta antes de que se ejecute, con la entrada completa. Si el agente está a punto de leer .env o cualquier cosa bajo secrets/, el hook sale con 2 y la lectura nunca ocurre. Frío. No importa cuán razonable fuera la justificación del agente, o si una inyección de prompt enterrada en alguna página web le pidió amablemente. El portero no debate.

Bloquear comandos destructivos

El mismo evento, asociado a la herramienta Bash. El hook inspecciona la cadena del comando en tool_input.command antes de que se ejecute — rm -rf apuntando a algo sensible, un force push, un DROP TABLE, lo que sea que tu lista personal de cicatrices contenga. Niégalo en código y simplemente no es posible, sin importar a qué el modelo llegue razonando.

Rechazar "terminado" hasta que los tests pasen

Este es el que más importa, y usa un evento diferente. Claude Code dispara un evento Stop cuando el agente termina de responder. Tu hook se ejecuta en ese momento. Si sale con 2, se impide que el agente se detenga; tu mensaje de stderr vuelve al modelo, y vuelve a trabajar. El agente dice "listo, envié la funcionalidad." El hook Stop ejecuta silenciosamente la suite de tests. Tres fallos. El hook sale con 2 con la salida del fallo. El agente no puede dar por terminado. Es devuelto al bucle con el bug en mano.

El stop rechazado es la garantía que importa

Todos entienden que los hooks pueden bloquear una mala acción. El movimiento subestimado es que un hook puede bloquear un mal stop. Aquí es donde el argumento de la fuente y el Teorema 3 se encuentran con más claridad.

"Siempre ejecuta los tests antes de terminar" en tu prompt es una sugerencia. Un hook Stop que rechaza el stop es una regla. El agente literalmente no puede declarar victoria mientras la suite está roja. Dos notas prácticas de la guía: mantén la comprobación rápida y determinista, porque se ejecuta en cada stop; y asegúrate de que un fallo real produzca un mensaje reparable, porque ese texto de stderr es la única guía que recibe el agente. "Tests fallidos" lo manda a vagar. La salida real del fallo lo manda directo al bug.

[PERSONAL EXPERIENCE] El HAI Engine ha corrido en producción desde 2016, y la lección de esos años es la misma: las propiedades que garantizamos — probabilidades normalizadas en exactamente un lugar, escenarios ordenados descendentemente, entropía en nats — viven en el código de ensemble del Oracle, no en un prompt pidiendo a las Sisters que tengan cuidado. Las Sisters imaginan; el Oracle fusiona. La normalización es el hook. Se ejecuta cada vez, en el mismo punto, con las mismas reglas, y ninguna Sister puede persuadirlo de enviar un cono cuyas probabilidades sumen 1.05. Eso es el Teorema 3: la propiedad se cumple porque el mecanismo está implementado y midiendo.

El mismo patrón funciona un nivel más abajo: SubagentStop se dispara cuando un subagente termina, así que el trabajo delegado se puede sostener al mismo estándar que el bucle principal. En términos de Everythink, esto es por qué the space is the router — una room enruta al subagente correcto, y el stop del subagente está gated por la misma frontera que gatela el padre. La garantía se compone a través de la topología. Una network enruta a una community, una community enruta a una room, una room enruta a un subagente, y en cada frontera se aplica la misma disciplina: el mecanismo garantiza la propiedad, no el juicio del que responde.

Trabajo dos: el diario de fin de turno

Las barreras son para lo que todos usan los hooks. Hay un segundo trabajo del que casi nadie habla: los hooks son cómo se escribe la memoria de un agente.

Tu agente ya lee memoria; la recuperación extrae los hechos relevantes a la ventana cuando empieza una tarea. Pero algo tiene que archivar los hechos nuevos — la preferencia que expresaste, el enfoque que funcionó, el error que vale la pena no repetir. Ese algo es un hook. Claude Code dispara SessionEnd cuando una sesión termina. No puede bloquear nada; su salida se ignora; existe puramente para efectos secundarios. Que es exactamente lo que es una escritura de memoria: toma la ruta del transcript de stdin, destila la conversación, añade lo durable a tu almacén.

Es el diario de fin de turno, excepto que el diario se escribe a sí mismo, cada turno, porque es una regla y no un estado de ánimo. La próxima sesión, el agente entra ya sabiendo lo que esta le enseñó.

Dos reglas evitan que esto se vuelva un juguete. Gating de la escritura: la mayoría de los mensajes son "gracias" y "entendido", así que escribe al final de la sesión y deja que el prompt termine con "si nada es durable, no escribas nada." Guardar todo no es memoria, es desorden. Y usa el modelo barato: destilar un transcript en un párrafo no es razonamiento difícil. El modelo senior piensa durante la sesión; el interno redacta las minutas después.

Esto se mapea a una disciplina que mantenemos en los 21 papers: una medición que no está gated es ruido. El Oracle no registra cada borrador de Sister — registra el ensemble normalizado, la entropía, la traza de calibración. El hook SessionEnd es la misma puerta en la frontera de la memoria: escribe el hecho durable, descarta el ruido. Un sistema de memoria que guarda todo no recuerda nada.

El mapa de eventos

Claude Code expone alrededor de treinta eventos. Los que alcanzas primero, según la documentación:

• PreToolUse — antes de que cualquier llamada a herramienta se ejecute; puede bloquear; guardia de secretos, filtro de comandos destructivos.
• PostToolUse — después de que una llamada a herramienta completa; solo retroalimentación; auto-formatear tras ediciones, registrar cada comando.
• UserPromptSubmit — cuando envías un prompt; puede rechazar el prompt; inyectar contexto, filtrar prompts.
• Stop — cuando el agente termina de responder; puede rechazar el stop; ejecutar tests antes de aceptar "terminado".
• SubagentStop — cuando un subagente termina; puede bloquear; sostener el trabajo delegado al mismo estándar.
• SessionStart — cuando una sesión comienza; no puede bloquear, añade contexto; cargar el estado de hoy en la ventana.
• PreCompact — antes de la compactación de contexto; puede bloquear; guardar estado antes de que la ventana se comprima.
• SessionEnd — cuando una sesión termina; solo efectos secundarios; la escritura de memoria.

Nota la simetría: SessionStart inyecta contexto, SessionEnd escribe aprendizaje. Ese par por sí solo es un sistema de memoria funcional — y es un sistema de memoria hecho de reglas, no de estados de ánimo. El evento PreCompact es la frontera que impide que la ventana descarte estado en silencio: guarda el conjunto de trabajo antes de la compresión, y el agente retoma desde el hecho, no desde el resumen.

Lo que Everythink garantiza así

El HAI Engine ✅ es el sistema de producción que esta disciplina produce. Las Sisters ✅ son las imaginadoras; el Oracle ✅ es el fusionador; la normalización del ensemble es el hook que garantiza que las probabilidades sumen uno. World Monitor ✅ enruta geo-señales en vivo a través de un gateway que acota el volumen de llamadas upstream por nuestro calendario, no por el número de clientes — un hook de rate-limit a nivel de arquitectura. Social ✅, Campaigns ✅ y Whitelabel Network ✅ son los módulos donde las reglas de ruteo de una network se hacen cumplir en código, no en una guía de marca.

Los módulos Partial ⚠️ — Matchmaking, Marketplace, Calendar — están medidos pero aún no fully hardened; lo decimos. Los módulos Roadmap 🔵 — Wallet & Token, Super App, Community Credit — son pre-revenue y están sujetos a revisión Howey; no prometemos resultados para ellos, y ningún hook que enviemos puede cambiar esa honestidad. Un hook puede garantizar una propiedad; no puede garantizar un mercado.

La soberanía del cliente es la versión más profunda de este patrón. Tu network, tu marca, tus datos — las reglas de ruteo son tuyas porque viven en código que controlas, no en el prompt de un proveedor. La ética de alcance — uso civil y defensivo solamente — es ella misma un hook: una política escrita en la frontera, no una esperanza de que el modelo rechace el trabajo equivocado. La inclusión por diseño — multilingüe, multimodal, baja conectividad — es una inyección SessionStart: el locale y el ancho de banda dan forma al primer contexto que ve el agente, antes de que responda.

Conclusiones clave

• Un hook es código determinista en un punto fijo del bucle del agente; el modelo es probabilístico y no puede persuadirlo. La propiedad está garantizada por el mecanismo, no por el prompt.
• El stop rechazado es el Teorema 3 en código: "los tests pasan antes de terminar" es una propiedad; el hook Stop que sale con 2 ante el fallo es el mecanismo implementado y midiendo.
• Salir con 2 bloquea; salir con 1 falla abierto. Una barrera que cae abierta es peor que ninguna — vende la sensación de seguridad sin el mecanismo.
• SessionEnd escribe memoria para que SessionStart pueda leerla. El par es un sistema de memoria hecho de reglas, no de estados de ánimo; gating de la escritura o almacenas desorden.
• El hook es "the space is the router" en la frontera de la herramienta: el ruteo precede a la ejecución, y la frontera decide, no el que responde.

Preguntas frecuentes

¿Qué es exactamente un hook de Claude Code? Un comando de shell que registras en un archivo de configuración. Cuando un evento fijo del bucle del agente se dispara — antes de que una herramienta se ejecute, cuando el agente declara terminado, cuando una sesión acaba — Claude Code envía un payload JSON a tu script y lee el veredicto del código de salida. Salir con 0 continúa, salir con 2 bloquea.

¿Por qué un hook es más seguro que una instrucción de prompt? Una instrucción de prompt es una sugerencia que un modelo probabilístico probablemente seguirá. Un hook es código que se ejecuta cada vez, en el mismo punto, con las mismas reglas. El modelo no puede olvidarlo, saltárselo ni rebatirlo. "Esperar que se comporte" se convierte en "saber que lo hará."

¿Qué significa "rechazar el stop"? El evento Stop se dispara cuando el agente termina de responder. Un hook en ese evento puede salir con 2 para impedir que el agente se detenga, enviando el mensaje de stderr de vuelta al modelo. Ejecuta la suite de tests ahí, y el agente literalmente no puede declarar victoria mientras la suite está roja.

¿Cómo se conecta esto con el Teorema 3? El Teorema 3 dice que una propiedad está garantizada exactamente cuando su mecanismo está implementado y midiendo. El hook es ese mecanismo: implementado como código, midiendo como código de salida. Quítalo y tienes un deseo; consérvalo y tienes una garantía.

¿Everythink usa hooks? La misma disciplina corre el HAI Engine ✅: la normalización del ensemble del Oracle es el hook que garantiza que las probabilidades sumen uno, en código, cada ejecución. Ninguna Sister puede persuadirlo de enviar un cono no normalizado.

Sources

Professor Glitch, "Claude Code Hooks: The Guardrails Your Agent Can't Talk Past," askglitch.com, 7 de julio de 2026 — https://www.askglitch.com/blog/claude-code-hooks

Claude Code hooks reference, code.claude.com — https://code.claude.com/docs/en/hooks

Crea tu network.