M1 — Hooks, harness y determinismo

Idea núcleo: usar un agente de coding a diario y poder explicar cómo funciona por dentro son dos habilidades distintas. La segunda es la que separa a quien “usa la herramienta” de quien puede defender decisiones de arquitectura sobre agentes en una entrevista o un diseño de sistema.

Concepto 1 — El harness: qué convierte un modelo en un agente

Entender (compacto):

• Un LLM solo predice texto. Un harness es la capa de orquestación que lo rodea: el loop de ejecución (modelo → herramientas → resultado → modelo otra vez), la gestión de contexto/compactación, los permisos, y el estado de sesión.
• El loop, en 5 pasos: (1) el harness arma prompt + system instructions + definiciones de tools + historial, (2) el modelo produce texto y/o tool calls, (3) el harness ejecuta cada tool call, (4) el resultado vuelve al modelo como mensaje nuevo, (5) se repite hasta que el modelo responde sin más tool calls.
• Sin harness, un modelo solo puede decir “probablemente el bug está en X”. Con harness, puede correr el test, leer el archivo, editarlo, y volver a correr el test para verificar — la diferencia entre un chatbot y un agente que resuelve tareas de punta a punta.
• Tres capas relacionadas, útil distinguirlas: un SDK de agentes empaqueta el harness (loop + tools + hooks + permisos) como librería que vos hosteás; un tool runner sobre una API base te da el loop pero sin tools propias, las definís vos; un agente gestionado es el mismo harness pero hosteado por el proveedor, no por vos.

Nota atómica: Front: ¿qué hace que un modelo sea “agente” y no solo un chatbot? Back: el harness — la capa que ejecuta sus tool calls, le devuelve resultados, y repite el loop hasta que la tarea está resuelta y verificada, no solo predicha.

Feynman: “El modelo es el cerebro que decide qué hacer. El harness es el cuerpo que realmente hace las cosas — mueve las manos, mira el resultado, y le cuenta al cerebro qué pasó para que decida el siguiente paso.”

Aplicar: tomá cualquier tarea que le pidas hoy a un agente de coding (“arreglá este test que falla”) y escribí, paso a paso, qué hace el harness en cada vuelta del loop — qué tool corre, qué resultado recibe, cuándo decide que terminó. Hacerlo explícito una vez es lo que después te permite defenderlo en voz.

Concepto 2 — Hooks: interceptar el loop sin tocar el harness

Entender (compacto):

• Un hook intercepta un evento del ciclo de vida del agente (antes/después de ejecutar una herramienta, al iniciar sesión, al terminar) y corre lógica propia — un script, un request HTTP, una consulta a otro modelo — sin modificar el código del harness.
• Los eventos que más importan en la práctica: antes de una tool (puede bloquear su ejecución — el caso clásico es impedir un comando destructivo), después de una tool (auditoría, logging, o correr un formateador automático tras una edición), y al enviar un prompt (inyectar contexto o reglas adicionales antes de que el modelo lo procese).
• Se configuran declarativamente: qué evento, qué herramienta dispara el hook (matcher), y qué acción corre — un comando de shell, un request HTTP, una tool de otro protocolo, o incluso una consulta a un modelo para que decida.
• El patrón de uso real: un hook de “antes de ejecutar” que revisa si el comando matchea un patrón peligroso y responde con una decisión de bloqueo — la herramienta nunca llega a correr. O uno de “después de editar” que corre un linter automático sin que el agente tenga que acordarse de pedirlo.

Nota atómica: Front: ¿en qué momento del loop un hook puede bloquear una acción, no solo observarla? Back: en el evento “antes de ejecutar la herramienta” — ahí el hook puede negar la ejecución antes de que ocurra; en “después” solo puede reaccionar a algo que ya pasó.

Feynman: “Un hook es un guardia parado en una puerta específica del proceso, no una cámara que graba todo. Le podés poner un guardia a la puerta de ‘antes de correr un comando’ que dice ‘este no’ y la acción nunca sucede — eso es distinto a poner una cámara que solo te avisa después de que ya pasó.”

Aplicar: diseñá (en papel, no hace falta implementarlo) un hook que impida a un agente correr un comando destructivo específico de tu stack — qué evento usarías, qué condición chequearía, y qué responde para bloquearlo.

Límites: un hook mal diseñado agrega latencia a cada acción del agente (cada tool call pasa por él) — no todo necesita interceptarse, solo lo que de verdad importa auditar o bloquear.

Concepto 3 — Determinismo: qué se puede garantizar y qué no

Entender (compacto):

• Determinístico = mismo input, mismo output, siempre. Los modelos de lenguaje son probabilísticos por diseño — un subagente no es determinístico por defecto, aunque el prompt sea idéntico entre corridas.
• Output estructurado ≠ determinismo. Forzar que la salida sea JSON contra un schema (en vez de texto libre) da reproducibilidad de formato — podés parsear y validar con confianza — pero no garantiza que el contenido sea idéntico entre corridas.
• Por qué importa en un pipeline de agentes: si un subagente en un flujo con varias etapas devuelve resultados en formato distinto cada vez, el siguiente agente de la cadena no puede consumirlo de forma confiable, y el debugging se vuelve casi imposible (no podés reproducir un fallo si no sabés si la causa fue el input o la aleatoriedad del modelo).
• El mecanismo práctico más usado hoy: declarar el schema esperado en el prompt del subagente mismo, y que la capa que orquesta valide la respuesta contra ese schema — con reintento automático si no matchea. Es una garantía de shape, no de contenido exacto.

Nota atómica: Front: ¿“output estructurado” garantiza determinismo? Back: No — garantiza que el formato sea parseable y validable (mismo shape), pero el contenido puede variar entre corridas porque el modelo sigue siendo probabilístico por debajo.

Feynman: “Pedirle a alguien que siempre responda en una tarjeta con las mismas casillas (nombre, fecha, decisión) no significa que va a escribir lo mismo en cada casilla cada vez — solo que vas a poder leer la tarjeta de la misma forma sin importar qué escribió.”

Aplicar: si tenés (o vas a construir) un pipeline con más de un agente en cadena, definí el schema exacto que el segundo agente necesita del primero, y decidí qué pasa si la validación falla — ¿reintenta con el mismo prompt? ¿escala a un humano? Esa decisión es la que un entrevistador senior espera escuchar, no “el modelo siempre responde bien”.

Límites: no hay determinismo “bytes-idénticos” garantizado por ningún mecanismo hoy — lo que se logra con schema + validación + reintento es reproducibilidad de formato, suficiente para que un pipeline funcione, no una garantía matemática como la de una función pura.

Checklist de dominio M1

Marcás cuando podés explicar (Feynman) + aplicar:

• Harness — qué es, el loop de 5 pasos, diferencia SDK/tool-runner/agente gestionado
• Hooks — qué eventos importan, cuándo pueden bloquear vs solo observar
• Determinismo — por qué un subagente no es determinístico, qué sí se puede garantizar (shape, no contenido)

Salida verificable del módulo: poder explicar, sin apoyo y en voz, cómo el harness ejecuta una tarea de punta a punta, diseñar un hook de bloqueo para un caso concreto, y justificar por qué “output estructurado” no es lo mismo que “determinístico”.