Del responder a actuar
Durante los últimos años, la mayoría de nosotros hemos relacionado los modelos de lenguaje del mismo modo en que nos relacionamos con un colega muy leído. Le haces una pregunta, obtienes una respuesta y lo que ocurre después depende de ti. Esa forma de trabajar se está sustituyendo silenciosamente. Los problemas interesantes ya no consisten en lograr que un modelo diga lo correcto. Consisten en lograr que un sistema haga lo correcto, a través de muchos pasos, con herramientas reales, en entornos caóticos donde el primer plan rara vez sobrevive al contacto con la realidad.
Esto es de lo que trata la ingeniería agente. Es la disciplina de diseñar, construir y operar sistemas en los que un modelo no solo produce texto, sino que realiza acciones, observa los resultados y decide qué hacer después hasta que se alcanza un objetivo. El modelo sigue estando en el centro, pero ahora es un componente más dentro de una máquina más grande, y la mayor parte de la dificultad real vive en todo lo que hay alrededor.
El cambio importa porque las habilidades son distintas. Escribir prompts premia una redacción ingeniosa. La ingeniería agente premia aquello que siempre ha hecho que el software sea fiable: interfaces claras, buena observabilidad, un manejo sensato de los fallos y un bucle estrecho entre lo que entregas y lo que aprendes. El único ingrediente genuinamente nuevo es el componente impredecible que está en medio de todo.
Qué es realmente un agente
La palabra agente se estira para abarcar casi cualquier cosa, así que vale la pena ser preciso. Un agente es un sistema que persigue un objetivo eligiendo repetidamente acciones en función de lo que observa, en lugar de seguir un guion fijo. La característica definitoria es el bucle, no la inteligencia. Un termostato sigue una regla. Un agente decide.
Ayuda a tratar la autonomía como un espectro y no como un sí o no. En un extremo está una sola llamada a un modelo que clasifica un correo electrónico. Un poco más allá, un flujo de trabajo encadena varias llamadas en un orden fijo, lo cual es útil pero aún es guionado. Aún más adelante, el modelo elige qué herramienta llamar y cuándo, y sigue avanzando hasta que juzga que el trabajo está hecho. En el extremo lejano, el sistema establece sus propios subobjetivos, gestiona su propia memoria y funciona durante horas. La mayoría de los sistemas de producción hoy en día se sitúan en algún punto del medio, y normalmente ese es el lugar correcto, porque la autonomía total rara vez es lo que realmente necesita un problema.
Decidir dónde se sitúa tu sistema en este espectro es una de las cosas más esclarecedoras que puedes hacer al principio. Te dice hasta qué punto puedes apoyarte en el criterio del modelo, cuánta estructura necesitas imponer y dónde se concentrará el riesgo.
El bucle del agente
Quita los nombres del framework y el marketing, y casi todo agente ejecuta el mismo bucle. Reúne contexto sobre su situación, razona sobre qué hacer, realiza una acción y observa qué ocurrió. Luego vuelve a hacerlo, usando lo que acaba de aprender, hasta que se alcanza el objetivo o se rinde.
Cada pasada por este bucle es un punto de decisión, y los puntos de decisión son donde las cosas salen bien o mal. Un buen bucle de agente no es el que tiene el prompt más ingenioso. Es el que logra que cada etapa tenga justo la información necesaria para tomar una buena decisión y nada más. Dale al modelo todo el historial de todo lo que ha ocurrido y pierde el hilo. Dale demasiado poco y actúa a ciegas. Gran parte del trabajo consiste en decidir qué es lo que el modelo puede ver en cada turno.
El bucle también explica por qué construir agentes se siente tan distinto del software ordinario. En código normal puedes razonar sobre cada ruta. Aquí el modelo puede elegir una ruta que nunca imaginaste, recuperarse de un error de una manera que no habías planeado o desviarse hacia una dirección que parece razonable durante tres pasos y luego se desmorona. No estás escribiendo la ruta. Estás moldeando el espacio de rutas posibles e intentando que las buenas sean fáciles de encontrar.
La anatomía de un agente
Ayuda a imaginar un agente como un pequeño conjunto de piezas que hacen cada una un trabajo. Está el modelo, que aporta razonamiento y lenguaje. Están las herramientas, que permiten que el sistema actúe sobre el mundo y lea de él lo que sucede. Hay memoria y contexto, que llevan la información relevante a cada decisión. Y está la orquestación alrededor de todo, que ejecuta el bucle, impone límites y decide cuándo detenerse.
Lo que destaca, una vez que has construido unos cuantos, es cuán poco del trabajo duro está relacionado con el modelo en sí. El modelo es, en gran parte, una elección fija. Elijes uno, lo prompts, sigues. El esfuerzo de ingeniería se concentra en las piezas que lo rodean. Las buenas herramientas, el buen manejo del contexto y una buena orquestación son lo que separa una demo que funciona una vez de un sistema que puedes dejar en ejecución. Los equipos que se enfrascan en la redacción de prompts y descuidan estas partes tienden a construir cosas que se ven impresionantes el martes y que están rotas para el viernes.
Las herramientas y el contexto son la superficie real
Si el bucle es el esqueleto, las herramientas y el contexto son donde sucede la ingeniería de verdad.
Una herramienta son las manos del modelo. Es la forma en que el agente lee una base de datos, envía un mensaje, ejecuta una consulta o mueve un archivo. La calidad de tus herramientas pone un techo estricto a lo que el agente puede hacer, y el diseño de herramientas resulta ser un oficio en sí mismo. Una buena herramienta hace una cosa clara, lleva un nombre y una descripción que le dicen al modelo exactamente cuándo recurrir a ella, comprueba sus entradas y devuelve resultados fáciles de usar. Una herramienta vaga con una descripción ambigua es peor que ninguna herramienta, porque el modelo la usará con seguridad y de forma incorrecta. El cuidado que pondrías en diseñar una interfaz para un colega capaz pero nuevo es, aproximadamente, el cuidado que merece una herramienta, porque es, aproximadamente, la situación.
El contexto es la otra mitad. Un modelo solo sabe lo que se pone delante de él, así que en cada turno estás respondiendo a una pregunta silenciosa: ¿qué necesita ver el modelo ahora mismo para elegir bien? De ahí proviene la frase ingeniería de contexto, y se ha convertido en uno de los problemas centrales del campo. El enfoque ingenuo consiste en seguir metiendo más en la ventana, más historial, más documentos, más instrucciones. No escala. La atención se diluye, los costos suben y el modelo empieza a fallar justo en aquello que importaba. El enfoque mejor trata el contexto como un presupuesto que se gasta con propósito. Recuperas lo relevante, resumes lo antiguo, eliminas lo que ya está terminado y mantienes el conjunto de trabajo pequeño y nítido. Hacer esto bien suele ser la diferencia entre un agente que se mantiene coherente a lo largo de una tarea larga y uno que poco a poco pierde el hilo.
Por qué los agentes son difíciles
Aquí está el hecho incómodo que cada equipo termina descubriendo. Una sola llamada al modelo es bastante fiable. Encadena veinte y pequeñas tasas de error se acumulan hasta que los sistemas fallan más de lo que aciertan.
La aritmética es implacable. Si cada paso en una tarea de diez pasos es correcto el 95% del tiempo, la tarea completa solo tiene éxito aproximadamente el 60% del tiempo, y eso asume que los errores son independientes, lo cual a menudo no lo son. Una mala observación al principio puede envenenar cada decisión que sigue. Esta acumulación es la razón más importante por la que los agentes que deslumbran en una demo tienen dificultades en producción. La demo es un único camino feliz. Producción son diez mil caminos y la cola larga está llena de entradas que nadie pensó en considerar.
Los modos de fallo desarrollan su propia personalidad una vez que has visto suficientes. Los agentes se quedan atascados en bucles, llamando a la misma herramienta una y otra vez y esperando una respuesta distinta. Alucinan una herramienta o un resultado que nunca estuvo ahí. Anuncian éxito cuando no se logró nada. Llevan a cabo silenciosamente la tarea equivocada con total confianza. Ninguno de estos es un bug que puedas perseguir con un stack trace. Son comportamientos contra los que tienes que diseñar, detectar cuando ocurren y recuperarte con elegancia. Aceptarlo pronto, en lugar de esperar que un mejor modelo haga que todo desaparezca, es lo que separa a los equipos que entregan agentes de los equipos que solo los demuestran.
Evals y observabilidad
Si los agentes fallan de formas sutiles, acumulativas y difíciles de predecir, entonces lo más importante que puedes construir no es el agente. Es la capacidad de ver lo que está haciendo y medir si tus cambios lo mejoran.
La observabilidad es lo primero. No puedes depurar lo que no puedes ver, y el razonamiento de un agente es invisible por defecto. Cada ejecución debería dejar una traza: lo que el agente vio, lo que decidió, qué herramientas llamó, qué devolvió y dónde terminó. La primera vez que un agente de producción hace algo desconcertante, esa traza marca la diferencia entre un diagnóstico de cinco minutos y uno de cinco horas. Trátalo como algo fundamental y no como algo que puedas añadir más tarde.
Las evals vienen después, y son el motor real del progreso. Una eval es una prueba repetible de si tu sistema hace lo que debería en los casos que te importan. Sin ellas, vas a ciegas, porque la trampa con los agentes es que cada cambio se siente como una mejora en el momento. Ajustas un prompt, el ejemplo con el que te estás fijando mejora y no tienes idea de qué rompiste en el resto. Un buen conjunto de evals, construido a partir de fallos reales que has visto, convierte esa conjetura en medición. Los equipos que mejoran más rápido no son los que tienen los prompts más ingeniosos. Son los que tienen el bucle más estrecho entre observar comportamiento real, calificarlo, encontrar los modos de fallo, corregirlos y comprobar que la corrección se mantuvo.
