Fundamentos de agentes

Persona de agente

Un agente es un sistema en el que el modelo decide qué pasos da y en qué orden para conseguir un objetivo, usando herramientas, en lugar de seguir un flujo fijo programado. La persona del agente es la definición de su papel: quién es, qué objetivo tiene, qué herramientas puede usar, qué límites tiene y cómo debe comportarse.

Una persona bien definida es concreta y estrecha: «revisas los tickets sin respuesta de más de 48 horas y propones una acción para cada uno; nunca respondes directamente al cliente». Cuanto más amplio es el alcance, más imprevisible es el comportamiento. Antes de hacer un agente, vale la pena preguntarse si no basta con un flujo fijo con una o dos llamadas al modelo: a menudo sí.

ReAct

ReAct (Reasoning + Acting) es el patrón en el que el modelo alterna razonamiento y acción: piensa qué necesita, llama a una herramienta, observa el resultado y vuelve a pensar, hasta que puede responder. Es la base de la mayoría de agentes con herramientas.

Su valor es que el plan se adapta a lo que el agente encuentra por el camino: si un pedido no existe, lo busca por el nombre del cliente; si la política no lo deja claro, lo escala. Su riesgo es el bucle: sin un máximo de pasos, un agente puede quedarse probando variantes indefinidamente mientras gasta tokens.

Planning y descomposición de tareas

El planning es la capacidad del agente de dividir un objetivo complejo en subtareas antes de ejecutarlas, o a medida que avanza. «Revisa el backlog y propón acciones» se convierte en listar los tickets pendientes, clasificarlos, revisar su historial y redactar una propuesta para cada uno.

Un plan explícito hace al agente más previsible y más fácil de depurar, porque se puede revisar antes de ejecutarlo y se puede ver en qué paso ha fallado. En las tareas largas, conviene que el plan se pueda corregir por el camino y que cada subtarea tenga un criterio claro para saber cuándo está terminada.

Memoria a corto y largo plazo

La memoria a corto plazo es lo que el agente recuerda dentro de una tarea o de una conversación: el historial y los resultados de las herramientas, que viven en la ventana de contexto. La memoria a largo plazo es lo que persiste entre sesiones: preferencias del usuario, decisiones tomadas o hechos aprendidos, guardados fuera del modelo y recuperados cuando hacen falta.

La ventana de contexto se llena deprisa en las tareas largas, y hay que resumir o descartar lo que ya no es útil. La memoria a largo plazo se debe diseñar como cualquier otro dato: qué se guarda, quién lo puede ver, cómo se corrige si es erróneo y cuándo caduca. Una memoria que guarda un error lo repetirá indefinidamente.

Reflection

La reflection (autocrítica) consiste en hacer que el agente revise su propio resultado antes de darlo por bueno: comprobar si responde a la petición, si cumple las reglas o si tiene errores, y corregirlo si hace falta. Lo puede hacer el mismo modelo en un segundo paso u otro modelo que haga de revisor.

Mejora la calidad en las tareas donde los errores son detectables (un formato incorrecto, una política incumplida, un cálculo erróneo), pero duplica o triplica el coste y la latencia. Es más eficaz cuando la revisión se hace con criterios concretos o con comprobaciones de código que cuando se pide, en general, «revísalo y mejóralo».

Guardrails y human-in-the-loop

Los guardrails son los controles que limitan lo que un agente puede hacer o decir: validaciones de entrada y de salida, límites de pasos y de gasto, listas de acciones permitidas y filtros de contenido. El human-in-the-loop es el punto en el que el agente se detiene y espera a que una persona apruebe, corrija o rechace lo que quiere hacer.

La clave es dónde se ponen. Una instrucción en el prompt («pide confirmación antes de actuar») no es un guardrail real, porque el modelo la puede ignorar. Una aprobación implementada en el código, que detiene la ejecución de la herramienta hasta que alguien la aprueba, sí lo es. Cuanto más irreversible es una acción, más cerca debe estar una persona.