Capital de TokensDurante años, gran parte de la conversación alrededor de los modelos de lenguaje giró en torno a una habilidad concreta: escribir mejores prompts.
Había técnicas para especificar el rol del modelo, dividir problemas, pedir razonamiento estructurado, introducir ejemplos, definir formatos de salida y añadir contexto.
Todo eso sigue siendo útil.
Pero la frontera de la ingeniería con IA se está moviendo.
Un post reciente de @kyr0stack en X lo resume con una secuencia extremadamente compacta:
Prompts → Agents → Loops → GraphsEl post atribuye a Sam Altman una frase aún más contundente sobre dejar de pensar solamente en prompts y empezar a pensar en loops y grafos.
Aquí conviene separar dos cosas.
No hemos encontrado una fuente primaria de OpenAI que permita verificar literalmente esa cita tal como circula en X. Por eso no deberíamos tratarla como una declaración confirmada de Altman.
Pero la idea técnica detrás del post sí describe bastante bien una transición que ya puede observarse en la documentación y herramientas modernas para construir agentes.
La pregunta ya no es solamente:
¿qué prompt produce la mejor respuesta?
Cada vez más, la pregunta es:
¿qué arquitectura hace que el modelo pueda ejecutar una tarea, comprobar su trabajo, corregirse y decidir qué debe ocurrir después?
Ese cambio es mucho más importante que cualquier frase viral.
Nivel 1: el prompt
El patrón más simple es el que todos conocemos:
Usuario
↓
Prompt
↓
Modelo
↓
RespuestaEl modelo recibe instrucciones y devuelve texto, código, JSON o cualquier otro resultado.
Para muchas tareas esto sigue siendo suficiente.
Resumir un documento.
Traducir un párrafo.
Explicar un concepto.
Escribir una función.
El problema aparece cuando la tarea requiere interactuar con el mundo.
Por ejemplo:
- consultar una base de datos;
- revisar un repositorio;
- ejecutar tests;
- buscar información;
- enviar un correo;
- modificar un archivo;
- comprobar si el resultado fue correcto.
En ese punto el prompt por sí solo deja de ser la unidad adecuada.
Nivel 2: el agente
Un agente añade algo fundamental:
herramientas y capacidad de decidir cuándo utilizarlas.
La arquitectura empieza a parecerse a esto:
Objetivo
↓
Modelo
↓
Decisión
├── buscar información
├── ejecutar código
├── leer archivos
├── llamar una API
└── responderOpenAI describe sus agentes como sistemas capaces de completar tareas de manera independiente utilizando un modelo para seguir instrucciones y tomar decisiones, junto con herramientas para obtener contexto o realizar acciones bajo guardrails definidos.
La diferencia parece pequeña, pero cambia completamente el producto.
Un chatbot responde.
Un agente actúa.
Y cuando el modelo puede actuar aparece inmediatamente un nuevo problema: una sola ejecución rara vez es suficiente.
Nivel 3: el loop
Supongamos que un agente modifica código.
¿Qué ocurre si el código no compila?
En una arquitectura ingenua, la ejecución termina y el usuario recibe el error.
En una arquitectura con loop:
Generar cambio
↓
Ejecutar tests
↓
¿Pasaron?
┌─┴─────────┐
sí no
↓ ↓
terminar analizar error
↓
corregir
↓
ejecutar tests otra vezEso es un repair loop.
El sistema no considera la primera generación como el producto final.
La considera una hipótesis que debe sobrevivir una verificación.
Este patrón aparece cada vez más en workflows modernos de desarrollo con agentes: generar, ejecutar, observar, evaluar, corregir y repetir.
La inteligencia efectiva deja de depender únicamente de cuánto “razona” el modelo en una llamada.
También depende del feedback que recibe entre llamadas.
Un modelo moderadamente bueno dentro de un loop bien diseñado puede superar a un modelo más potente utilizado como una función de una sola ejecución.
Los evaluadores cambian el juego
Un loop necesita saber cuándo continuar y cuándo detenerse.
Eso introduce otra pieza crítica:
el evaluator.
El evaluator puede ser:
- una suite de tests;
- una validación de esquema;
- un compilador;
- reglas deterministas;
- un segundo modelo;
- un conjunto de métricas;
- una revisión humana;
- o una combinación de todas ellas.
Por ejemplo:
Generador
↓
Resultado
↓
Evaluator
↓
score = 0.61
↓
feedback
↓
Generador
↓
Resultado mejoradoEsta arquitectura cambia la forma de pensar sobre prompts.
Ya no necesitamos meter absolutamente todos los criterios dentro de una gigantesca instrucción inicial.
Parte de esos criterios pueden convertirse en tests externos al modelo.
Eso suele ser mucho más robusto.
El prompt explica lo que queremos.
El evaluator comprueba si realmente lo conseguimos.
Nivel 4: el graph
Los loops son muy útiles, pero los sistemas reales rara vez consisten en una única tarea que se repite.
Normalmente existen múltiples etapas.
Imaginemos un sistema que convierte una noticia en un video:
Artículo
↓
Extracción
↓
Fact-check
↓
Guion
↓
Evaluación editorial
↓
Audio
↓
Storyboard
↓
Imágenes
↓
Video
↓
Control de calidad
↓
PublicaciónEsto ya no es solamente un loop.
Es un grafo de ejecución.
Cada nodo puede tener:
- herramientas diferentes;
- modelos diferentes;
- permisos diferentes;
- criterios de éxito diferentes;
- costos diferentes;
- rutas alternativas.
Y las conexiones entre nodos pueden depender del resultado anterior.
Por ejemplo:
┌→ buscar más fuentes ─┐
│ │
noticia → guion → evaluator ───────────┘
│
├→ corregir guion
│
└→ aprobar → audio → videoEl sistema puede ramificarse.
Puede regresar a un nodo anterior.
Puede ejecutar partes en paralelo.
Puede abortar si un riesgo supera cierto umbral.
Puede pedir aprobación humana antes de una acción irreversible.
Puede utilizar un modelo barato para una etapa y reservar un modelo más potente para otra.
Aquí aparece la verdadera importancia del graph engineering.
El modelo deja de ser toda la aplicación
Cuando un sistema pasa de prompt a agente, loop y grafo, una parte creciente de su comportamiento vive fuera del modelo.
La arquitectura puede controlar:
- qué contexto recibe;
- qué herramientas puede usar;
- qué acciones requieren permiso;
- cuántos intentos tiene;
- qué evaluator determina el éxito;
- cuándo escalar a otro modelo;
- qué información se conserva;
- qué eventos se registran;
- qué nodo debe ejecutarse después.
Eso significa que dos productos pueden utilizar exactamente el mismo modelo y tener resultados radicalmente distintos.
Uno puede ser:
prompt → modelo → respuestaEl otro:
contexto
↓
planner
↓
tools
↓
ejecución
↓
traces
↓
eval
↓
repair loop
↓
approval gate
↓
acción finalMismo modelo.
Sistema completamente diferente.
El harness empieza a convertirse en la ventaja competitiva
Esta idea conecta con un concepto que aparece cada vez más en ingeniería con IA: el harness.
El harness es toda la infraestructura alrededor del modelo que hace posible convertir una capacidad probabilística en un sistema operativo relativamente confiable.
Incluye cosas como:
- prompts;
- herramientas;
- memoria;
- recuperación de contexto;
- permisos;
- sandboxes;
- evaluadores;
- observabilidad;
- retries;
- loops;
- routing;
- límites de costo;
- estados;
- grafos de ejecución.
Durante la primera etapa de los LLMs era razonable obsesionarse con encontrar el prompt perfecto.
Ahora la ventaja puede estar en algo distinto:
construir la mejor máquina alrededor del modelo.
Los traces son la memoria del sistema
Hay otra consecuencia importante.
Cada ejecución de un agente produce una traza.
La traza puede registrar:
- qué herramienta eligió;
- qué datos recuperó;
- cuánto tardó;
- cuántos tokens consumió;
- qué errores encontró;
- cuántos reintentos necesitó;
- qué evaluator falló;
- qué corrección terminó funcionando.
Cuando esas traces se analizan sistemáticamente, dejan de ser simples logs.
Se convierten en datos para mejorar el propio sistema.
Entonces aparece otro loop:
Agent
↓
Execution
↓
Trace
↓
Eval
↓
Detectar patrón de fallo
↓
Mejorar prompt / tool / skill / graph
↓
Nueva ejecuciónEso es especialmente interesante porque el aprendizaje ya no requiere necesariamente entrenar de nuevo el modelo base.
Podemos mejorar la arquitectura que utiliza el modelo.
No todo debe convertirse en un agente
También existe un riesgo de sobrecorrección.
Que los agentes, loops y graphs sean útiles no significa que cada función de software deba convertirse en una pequeña sociedad de modelos autónomos.
Una regla determinista sigue siendo mejor cuando el problema puede resolverse de forma determinista.
Si una expresión regular funciona, no hace falta un agente.
Si un esquema JSON puede validar la salida, no hace falta otro LLM.
Si una operación puede calcularse exactamente, no debemos convertirla en razonamiento probabilístico.
Los mejores sistemas agentic probablemente mezclen ambos mundos:
software determinista
+
modelos probabilísticos
+
evaluadores
+
orquestaciónEl objetivo no es maximizar la cantidad de IA.
Es colocarla únicamente donde aporta capacidad.
La nueva habilidad: diseñar la ejecución
La evolución propuesta por el post viral puede leerse entonces de una forma más útil:
Prompt
¿Qué quiero que haga el modelo?
Agent
¿Qué herramientas necesita para hacerlo?
Loop
¿Cómo comprobará si lo hizo bien y cómo corregirá los fallos?
Graph
¿Cómo se conecta esa capacidad con el resto del sistema?
Son cuatro niveles distintos de abstracción.
Y saltarse uno suele producir problemas que después atribuimos al modelo.
Un agente sin evaluator puede cometer errores silenciosos.
Un loop sin límites puede gastar recursos indefinidamente.
Un grafo sin observabilidad puede convertirse en una caja negra.
Una herramienta sin permisos adecuados puede crear riesgos mucho mayores que una simple respuesta incorrecta.
Por eso la ingeniería de agentes empieza a parecerse menos a “hablar bien con una IA” y más a ingeniería de sistemas distribuida.
De prompt engineering a execution engineering
Quizá el término más útil para describir esta transición sea execution engineering.
No porque los prompts dejen de importar.
Importan.
Pero pasan a ser una pieza dentro de una arquitectura mayor.
La ventaja ya no consiste solamente en saber qué decirle al modelo.
Consiste en diseñar:
- qué ocurre antes;
- qué ocurre después;
- qué observa;
- quién evalúa;
- cuándo repite;
- cuándo cambia de estrategia;
- cuándo necesita aprobación;
- cuándo debe detenerse.
Ese es el cambio verdaderamente importante detrás de la secuencia:
Prompts → Agents → Loops → GraphsLa próxima generación de aplicaciones de IA probablemente no se diferencie únicamente por el modelo que utiliza.
Se diferenciará por cómo organiza el trabajo alrededor de ese modelo.
Y en ese mundo, el prompt deja de ser la aplicación.
La arquitectura se convierte en el producto.
Fuentes
- Post de @kyr0stack en X, consultado el 4 de octubre de 2026. La atribución literal a Sam Altman no fue confirmada aquí mediante una fuente primaria.
- OpenAI Cookbook — Agents
- OpenAI Cookbook — Codex