Un agente que "piensa más" no es un agente que piensa mejor. Es un agente que gasta más. El razonamiento moderno de un LLM no es introspección que puedas auditar. Es cómputo en inferencia, y lo presupuestas igual que presupuestas CPU. Cuando eso te cae, dejas de copiar prompts de "piensa paso a paso" de 2023, dejas de creer que el texto de razonamiento explica lo que el modelo hizo, y empiezas a tratar el thinking budget como la palanca económica y de seguridad que de verdad es.

El modelo mental: razonar es generar tokens

El razonamiento de un modelo son tokens intermedios que a veces condicionan la respuesta final y a veces la racionalizan después de haberla decidido. El salto de 2024 a 2025-2026 es que eso dejó de ser un truco de prompting (Chain-of-Thought) para convertirse en una capacidad entrenada con RL: o1/o3, DeepSeek-R1 y el extended/adaptive thinking de Claude. El modelo decide cuánto computar en inferencia.

La analogía que mantengo: piensa en el razonamiento visible como el borrador de un examinando, no como el acta notarial de su decisión. Un borrador a veces refleja el cálculo real y a veces es una justificación escrita después de que la mano ya marcó la casilla. Confiar en el borrador como prueba de cómo se llegó a la respuesta es justo el error que Anthropic documentó: inyectas una pista superficial en el prompt y el modelo a menudo la obedece sin mencionarla, e incluso construye una justificación alternativa plausible.

Inference-time compute: la curva precisión-vs-tokens

En vez de volcar todo el cómputo en pre-entrenamiento, gastas una parte en inferencia generando más y mejores tokens de razonamiento. La prueba más limpia de que esto sale con RL puro es DeepSeek-R1: igualó a o1 en benchmarks de razonamiento (AIME 2024 79.8% vs 79.2%, MATH-500 97.3%) escalando cómputo en inferencia, generando del orden de 10-30K tokens de razonamiento por problema.

La consecuencia operativa: hay una curva precisión-vs-tokens con un codo. Por debajo del codo aparece el underthinking (el modelo se rinde pronto). Por encima, el overthinking: quema tokens sin ganar precisión, e incluso la degrada. Más thinking no es monótonamente mejor. Por eso la práctica disciplinada es medir la curva por tipo de tarea, no activar el effort máximo "por si acaso".

Precisión vs presupuesto de thinking: underthink, codo, overthink

En los modelos más nuevos esto es lo que controla el effort. El thinking adaptativo e interleaved deja que el modelo asigne su propio presupuesto y razone entre tool calls; el viejo budget_tokens fijo es la abstracción equivocada aquí.

La cadena de razonamiento no es fiel a la computación interna

Esta es la verdad incómoda con más consecuencias de todo el tema. Anthropic mostró (midiendo fidelidad primero en 2023, luego sobre modelos de razonamiento en 2025) que el texto de razonamiento no refleja de forma fiable la computación real del modelo. Dos hallazgos que sostienen todo. Primero, el modelo puede derivar su respuesta de una pista superficial del prompt y no mencionarla en la cadena. Segundo, editar el texto de razonamiento a menudo no cambia la respuesta final, lo que significa que la cadena visible muchas veces no es el camino causal.

La regla práctica que sale de aquí: juzga la trayectoria de tool calls, no el texto de razonamiento. Esa es la respuesta correcta a la infidelidad del CoT: califica lo que el agente hizo (la trayectoria del hook PreToolUse), trata el transcript como datos y reserva un juez LLM para la calidad de la resolución, nunca para "¿quiso hacer lo correcto?".

El prompting se invierte: minimalismo en modelos de razonamiento

Con razonamiento nativo, instruir "piensa paso a paso" o pegar plantillas few-shot de CoT degrada el rendimiento. La fuente correcta de esto es la guía de buenas prácticas de OpenAI para o1 ("evita prompts elaborados de chain-of-thought; el few-shot puede perjudicar; mantenlo simple") y las guías de extended thinking de Anthropic. El prompt óptimo da objetivo, restricciones, criterios de éxito y herramientas, y deja que el modelo asigne su propio cómputo.

prompt-malo.txt 
Eres un experto. Piensa paso a paso.
Aquí tienes 5 ejemplos resueltos con su razonamiento completo.
Ahora resuelve...

La plantilla compite con el razonamiento entrenado del modelo. Resultado: ruido, presupuesto desperdiciado, peor precisión.

prompt-bueno.txt 
Objetivo: X.
Restricciones: A, B.
Éxito = el archivo contiene Y.
Herramientas disponibles: grep, read.

El modelo asigna su propio presupuesto y razona internamente. Especificaste el qué, no el cómo.

Error compounding: un problema de contexto, no de inteligencia

Una tasa de error por paso pequeña se compone de forma multiplicativa. Si cada paso acierta con probabilidad p, una cadena de n pasos acierta más o menos a pⁿ. Por eso agentes fiables en tareas cortas colapsan en horizontes largos. La causa dominante no es un modelo tonto. Es el crecimiento descontrolado del contexto. ReAct es append-only (thought, action, observation, repetir) y ese transcript creciente satura la atención y re-expone los errores tempranos turno tras turno.

Los verificadores externos rompen el bucle de auto-engaño

El modelo no puede verificarse a sí mismo de forma fiable. Reflexion (auto-reflexión verbal sobre los fallos) es útil conceptualmente pero frágil sin una señal externa de verdad; el modelo tiende a racionalizar en lugar de corregir. El multiplicador real del razonamiento es una señal de verdad externa: un test que corre, un grep que encuentra (o no) un dato, una herramienta que falla.

Self-consistency muestrea varias trazas y vota la respuesta mayoritaria. Su límite práctico: trata todas las trazas igual (ignora su calidad), y hasta dónde llegan las ganancias depende de qué tan fuerte sea el modelo. En los modelos de la época de 2022 de Wang et al., la precisión seguía subiendo hasta ~40 muestras (el ajuste canónico), con rendimientos decrecientes en vez de un corte tajante. En los modelos fuertes de 2025-2026 el punto de saturación llega mucho antes — en torno a k≈10-15 — porque las trazas muestreadas se solapan y muestrear más solo re-explora caminos viejos. Un verificador alcanza mayor precisión con menos tokens. Muestrear 64 veces como bala de plata es quemar presupuesto.

Cuándo sí tienes un verificador y cuándo no

Si hay una señal de verdad determinista (código que compila, un dato que existe en un archivo), usa best-of-N con ese verificador: le gana al majority voting ciego a menor coste en tokens. La búsqueda agéntica sobre archivos (grep/glob/read), sin RAG ni embeddings, es un verificador externo barato: el dato existe o no existe. Cuando no hay verificador y la respuesta es discreta, self-consistency es el recurso, pero topa la k cerca del punto de saturación, no en 64. Reflexion sin señal externa es el caso a evitar: produce "mejoras" frágiles y autocomplacientes.

Planificación: explícita vs emergente

Hay dos sabores de planificación, y elegir mal es un error arquitectónico de primer orden. La elección depende del horizonte y de tu tolerancia a errores compuestos.

Genera un plan explícito y auditable antes de actuar. El usuario (o un human-in-the-loop) ve qué hará el agente antes de tocar nada; puedes usar modelos baratos para subtareas; controlas el coste y las dependencias entre pasos. Es además un mecanismo de seguridad: un plan revisable te deja interceptar acciones de escritura antes de ejecutarlas. Mejor para dependencias, compliance y escrituras.

El bucle thought-action-observation se adapta en entornos dinámicos donde la información se revela de forma incremental. El precio: en horizontes largos sufre objective drift y error compounding por el contexto append-only. Es el patrón por defecto de casi todos los SDK de agentes, y es el default correcto para exploración dinámica de horizonte corto.

Regla de pulgar: para tareas con dependencias o varias escrituras (reagendar = cancelar + crear), fuerza un plan explícito que pase por HITL antes de ejecutar. Para exploración dinámica de horizonte corto, deja que ReAct emerja. El modo de fallo de ReAct emergente en una operación de dos escrituras es ejecutar una mitad (cancelar) sin la otra (crear) cuando deriva.

El presupuesto de razonamiento es coste y latencia

Un detalle de facturación que mata márgenes: el thinking se factura completo, no solo el resumen visible, y puede exceder tu max_tokens. En un SaaS multi-tenant con presupuesto diario de tokens, el thinking descontrolado es un agujero de coste silencioso. El thinking adaptativo deja que el modelo decida cuánto razonar, pero el ingeniero debe medir y poner techos por turno. Un default sensato es presupuesto diario de tokens más telemetría de thinking por turno, para ver el coste de razonamiento por turno y no solo el agregado diario.

Lo que el consenso sobrevalora

  • Tree-of-Thoughts y Graph-of-Thoughts en producción. Brillan en puzzles de papers (ToT se evaluó en Game of 24, Creative Writing y Mini Crosswords) pero su coste y latencia rara vez se justifican en agentes conversacionales reales. Sobre todo material de demo. (Una corrección que conviene guardar: Tower of Hanoi no es un benchmark de ToT/GoT; es el puzzle del Illusion of Thinking de Apple.)
  • CoT como explicabilidad o auditoría. Ya lo vimos: el razonamiento visible no refleja la computación real.
  • "Piensa paso a paso" y few-shot de CoT sobre modelos nativos. Una reliquia de 2023 que degrada el rendimiento.
  • Self-consistency con k=32/64 como bala de plata. Satura cerca de 10-15.

Lo que subestima

El razonamiento real se desbloquea con grounding externo verificable, no con introspección. La búsqueda agéntica sobre archivos es un verificador barato e infravalorado frente al culto al RAG. El presupuesto de tokens de thinking es una decisión de producto y coste, no solo técnica: en multi-tenant define tus márgenes. Y el multi-agente cuesta del orden de 15× los tokens de un solo chat y solo paga en tareas paralelizables; el uso de tokens explica cerca del 80% de la varianza de rendimiento, y el multi-agente falla en trabajo interdependiente (como coding). Para un asistente de empresa con coordinación interdependiente, un solo agente bien presupuestado suele ganar.

El hilo que recorre todo esto: no haces un agente más inteligente gastando más tokens de razonamiento. Lo haces más fiable anclándolo en verdad externa, controlando su contexto y decidiendo (por ruta, con una curva medida) cuánto cómputo vale la pena. El texto de razonamiento es un artefacto de debug por el camino, nunca la prueba.