Antes de escribir una línea de tu harness, tienes que saber qué es realmente el motor. Quítale el marketing y un LLM hace tres cosas llanas, y solo tres. Adivina la siguiente palabra, no recuerda nada por su cuenta y solo puede mirar una cantidad limitada de texto a la vez. No es "un asistente con memoria". No es "una máquina de razonar". Mete esos tres hechos en los huesos y dejas de pelear contra el modelo: empiezas a diseñar el andamiaje correcto a su alrededor.
Cada hecho llano tiene un nombre propio que vas a encontrarte por todas partes. Adivinar la siguiente palabra es ser La salida no es fija: ejecuta el modelo dos veces con la misma entrada y puedes obtener respuestas distintas, porque cada token siguiente se muestrea al azar de una distribución de probabilidad. Por eso una sola ejecución correcta prueba poco y la fiabilidad se mide en muchas (pass^k), no en una. glosario → (la salida se muestrea de una distribución de probabilidad, así que la misma entrada puede dar respuestas distintas). No recordar nada es ser El modelo no retiene nada entre llamadas a la API; una 'conversación' solo existe porque reenvías el historial previo en cada petición. glosario → (no retiene nada entre llamadas a la API). Y la vista limitada es una El número máximo finito de tokens (prompt más salida) que el modelo puede atender en una sola llamada; más allá de ese límite, el contenido debe descartarse, resumirse o recuperarse. glosario → . Casi todo lo que vas a construir como ingeniero de agentes (sesiones, memoria, human-in-the-loop, evals, presupuestos de tokens) existe para compensar una de esas tres.
No necesitas implementar atención, gradientes ni un tokenizador para enviar un buen agente. Lo que decide si tu agente sobrevive a producción es tener un modelo causal de por qué falla el modelo ( Los errores aritméticos que surgen de cómo el modelo trocea los números en tokens: el byte-pair encoding puede agrupar los dígitos de forma inconsistente (p. ej., '1234' como '123'+'4'), de modo que el modelo nunca ve un valor posicional limpio y calcula mal. Es un artefacto de la tokenización, no un fallo de razonamiento. glosario → por BPE, recencia, sampling, refusals) para diseñar el harness que lo absorbe.
Tres propiedades, y lo que fuerza cada una
El movimiento útil es de traducción: cuando el agente se porta mal, no preguntes "¿por qué el modelo es tonto?". Pregunta "¿cuál de las tres propiedades estoy ignorando?".
¿Olvidaste un dato del turno 3? Statelessness mal gestionado. ¿Sumó mal dos números? Tokenización. ¿Pasó el eval ayer y hoy falla? Estocasticidad. Ese reflejo de traducir síntoma a causa es la habilidad que separa a un ingeniero de agentes de un usuario de chatbots.
La analogía a la que siempre vuelvo: el LLM es una CPU sin RAM ni disco. Potentísima por ciclo, pero amnésica. Tu harness es la memoria, el almacenamiento y el reloj que la convierten en una computadora usable.
El contexto es un presupuesto de atención, no un cubo
Esta es la idea de mayor impacto del curso. El contexto no es almacenamiento. Es un presupuesto de atención finito que gastas cada turno.
La atención del transformer relaciona cada par de tokens, así que el cómputo es O(n²): doblar el contexto cuadruplica, más o menos, el coste de prefill. Esa es la raíz física, no negociable, del presupuesto de tokens.
Peor aún: el recall se degrada mucho antes de llegar al límite nominal. La forma documentada es la curva en U, el "lost in the middle". El modelo recupera bien lo que está al inicio y al final del contexto, y pierde lo que queda en el medio.
El principiante mete todo el historial porque "cabe en 1M". El experto sabe que cada token irrelevante diluye la señal y cuadruplica el coste. Más contexto no es más inteligencia. La técnica correcta es el just-in-time retrieval: mantener identificadores ligeros (paths, queries) y cargar datos bajo demanda con herramientas, en vez de volcarlo todo de antemano.
La conversación es una ilusión que reconstruyes
El modelo no recuerda nada entre requests. La API es stateless. Una "conversación" es algo que tú fabricas reenviando el historial en cada llamada. Por eso la persistencia, las sesiones y el resume no son detalles de implementación: son la arquitectura central que sustituye a la memoria que el modelo no tiene.
El in-context learning sale de las induction heads, no de "entender"
Aquí está la desmitificación más útil del prompting. La capacidad de aprender de ejemplos en el prompt (few-shot, seguir un formato, copiar un patrón de tool-call) no surge de que el modelo "entienda tus instrucciones". Surge de un mecanismo concreto: las Un circuito de dos attention heads que detecta un patrón previo 'A→B' y predice B al volver a ver A: el motor mecanístico del aprendizaje in-context (few-shot). glosario → , pares de cabezas de atención que detectan "vi A→B antes; ahora veo A, así que predigo B". Este circuito aparece en un cambio de fase abrupto durante el entrenamiento, y es el motor del in-context learning.
La implicación de diseño es directa: los ejemplos canónicos funcionan porque activan un mecanismo aprendido de copia y generalización, no porque el modelo razone sobre tus reglas.
Por qué esto cambia cómo escribes el system prompt
Si el modelo generaliza por copia de patrón, dos antipatrones se vuelven obvios. Primero, una lista de 30 ejemplos casi idénticos no le enseña nada nuevo al circuito: solo quema presupuesto de atención. Segundo, un ejemplo mal formateado enseña el formato malo, porque la induction head copia exactamente lo que le mostraste. La calidad y diversidad de 3-5 ejemplos canónicos le gana a la cantidad todas las veces.
El tool-use se entrena, no se prompea
Que un modelo decida cuándo llamar una herramienta, encadene varias y sepa detenerse no es magia del prompt. Es un comportamiento que al modelo le enseñaron a base de ensayo y error: le mostraron buenos ejemplos ( Entrenar un modelo base con ejemplos curados de entrada-salida (a menudo destilados de un teacher más grande) para enseñarle formato de respuesta, tono y estructura de chain-of-thought — captura la forma, no conocimiento factual nuevo. glosario → sobre trayectorias) y lo premiaron cuando sus respuestas de verdad cuadraban (RL con recompensa al final de la trayectoria). La familia de técnicas que hace esto es la misma con la que se entrena el razonamiento: Un algoritmo de RL (DeepSeekMath, 2024) que prescinde de la red de valor/crítico muestreando un grupo de respuestas por prompt y usando la recompensa media del grupo como línea base para la ventaja de cada respuesta. glosario → con recompensas verificables ( RL en el que la recompensa es una función programática y comprobable — si pasó el test, si la matemática es correcta, si se alcanzó el estado objetivo — lo que la hace mucho más difícil de manipular que un reward model aprendido y moldea el razonamiento y el uso de herramientas. glosario → ). La referencia pública más clara de esa receta es DeepSeek-R1 (2025), que usó GRPO + RLVR para inducir cadena de pensamiento con respuesta verificable, no tool-use: R1 se publicó sin function-calling nativo. Así que lee R1 como la referencia del método de entrenamiento, no como un modelo entrenado para herramientas.
De aquí salen dos consecuencias prácticas. Primero, el modelo arrastra priors fuertes sobre cómo lucen las herramientas bien diseñadas (esquemas claros, nombres descriptivos, descripciones prescriptivas), porque es contra eso que se entrenó. Segundo, la frontera de fiabilidad del agente es la distribución de tareas sobre la que se entrenó, y por eso evalúas por trayectoria, no solo por la respuesta final.
Pregunta abierta: ¿el RL añade habilidades nuevas o solo afila las viejas?
Un debate vivo que conviene señalar: si el RL solo afila capacidades que ya están en la distribución del modelo base, o si añade algunas genuinamente nuevas. Un bando (Yue et al., "Limit of RLVR") encuentra que los modelos base igualan a los afinados con RL para pass@k es la probabilidad de que al menos uno de k intentos tenga éxito (una medida de capacidad o de mejor caso); pass^k es la probabilidad de que los k intentos independientes tengan éxito todos (fiabilidad, ≈p^k), y en producción lo que importa es pass^k. glosario → grande, lo que sugiere que el RL solo muestrea soluciones existentes con más eficiencia. Otro (ProRL) reporta que el RL prolongado descubre estrategias que el modelo base nunca alcanza. Trátalo como abierto, no como cerrado.
El BPE decide qué ve el modelo, y dónde se rompe
El modelo no ve caracteres ni números. Ve El modelo lee y escribe en fragmentos de subpalabras ('tokens') generados por byte-pair encoding en lugar de caracteres o palabras completas, por lo que la agrupación de dígitos rompe la aritmética y el conteo exacto de caracteres. glosario → . Eso causa fallos sistemáticos y predecibles. La aritmética se rompe porque los dígitos se agrupan en tokens de forma arbitraria. El conteo de caracteres se rompe por lo mismo. Y la estructura (JSON, tool-args) cuesta tokens reales de formato.
Cuando presupuestes tokens, cuenta con el tokenizador real del proveedor. El folklore de que "tiktoken subcuenta a Claude un 15-20%" está exagerado: la diferencia real es menor (~12% en prosa) y puede ir en cualquier dirección según el contenido. Usa el endpoint count_tokens del proveedor en vez de adivinar.
Sampling y "thinking": el determinismo siempre fue un mito
La salida se muestrea de una distribución. Temperatura y top-p controlan su dispersión. Dos consecuencias rompen intuiciones comunes.
La primera: la no-determinación rompe el caching ingenuo y obliga a evals pass^k. Una corrida verde no significa fiable. La segunda es más nueva, y es un cambio de modelo mental:
El thinking extendido intercambia tokens de razonamiento por calidad. Es test-time compute, la palanca de escalado en inferencia, y es un resultado real: el escalado compute-óptimo en inferencia puede ganarle a un modelo mucho más grande en ciertos problemas. La perilla fija budget_tokens está deprecada (eliminada, 400, en 4.7+) a favor de effort (de low a max; xhigh llegó en Opus 4.7) y del thinking interleaved entre tool-calls. El thinking interleaved es justo lo que permite que el agente razone sobre el resultado de una herramienta antes de decidir la siguiente, en vez de planearlo todo al inicio.
Más thinking no es gratis, y no es monótonamente mejor: hay un régimen documentado de "overthinking" donde la precisión cae con presupuestos largos. Calibra el effort por ruta.
La Bitter Lesson decide qué construir
La última pieza es un criterio de decisión. La Bitter Lesson de Rich Sutton: los métodos generales que escalan con cómputo le ganan al conocimiento de dominio hecho a mano con el tiempo. Aplicado a agentes, el andamiaje que escribes hoy para parchear una limitación del modelo es deuda técnica que la próxima generación borra. Así que apuesta por capacidades que escalan (búsqueda agéntica, contexto largo, tool-use aprendido, razonamiento) y minimiza la lógica hecha a mano que el modelo acabará absorbiendo. Ese es el criterio para decidir qué construir y qué dejarle al modelo.