Arquitectura de la autonomía: de la ingeniería de prompts a los agentes orientados a objetivos

Todos los equipos que implementan una herramienta basada en LLM se topan con el mismo obstáculo. La demo funciona. La primera carga de trabajo real, no. El problema no es el modelo, sino la arquitectura.

Veamos un ejemplo concreto. Una empresa desarrolla un agente de IA para sustituir su servicio de soporte técnico externo. La demo funciona: se pega la pregunta del cliente y se obtiene una respuesta de la base de conocimientos. A continuación, el equipo canaliza los tickets de un día completo: 200 solicitudes de soporte que van desde el seguimiento de pedidos hasta disputas de reembolsos y resolución de problemas técnicos. El agente debe comprobar los historiales de pedidos, aplicar las políticas de devolución, contrastar las condiciones de la garantía y redactar resoluciones personalizadas. Intenta gestionarlo todo en una sola pasada; al llegar al ticket 50 empieza a mezclar a los clientes, aplica la política de devolución incorrecta a una disputa de reembolso y envía una resolución errónea pero con total seguridad.

Las primeras aplicaciones de LLM funcionaban como funciones: se introducía un prompt y se obtenía una respuesta. Si la tarea se ajustaba a una sola pasada y a una sola ventana de contexto (la cantidad de texto que un modelo puede retener en memoria a la vez), funcionaba. Sin embargo, el razonamiento en varios pasos, los reintentos o la coordinación entre distintos tipos de tareas rompen el modelo de pasada única.

La solución no es un prompt mejor. Los agentes orientados a objetivos operan en bucles en lugar de pasadas únicas: dividen el objetivo en tareas, ejecutan un paso, comprueban el resultado, ajustan el plan y repiten el proceso hasta terminar.

Cómo procesa un objetivo un agente orientado a objetivos: división en tareas, ejecución del paso A, comprobación del resultado, actualización del plan y bucle de retorno hasta completarlo.

De cadenas a bucles

El agente de soporte falló porque se diseñó como una cadena: una línea recta desde la entrada hasta la salida, sin capacidad de recordar, adaptarse o reintentar.

Una cadena es un conducto sin estado. Procesa una vez y continúa. No sabe lo que hizo hace dos pasos, no puede cambiar de rumbo cuando algo falla y trata cada solicitud como si viera el mundo por primera vez.

Un agente orientado a objetivos es un sistema con estado. Realiza un seguimiento de lo que ha hecho, de lo que queda por hacer y de lo que ha cambiado por el camino. Cuando un paso falla, se adapta. Cuando surge nueva información, revisa el plan.

La diferencia se manifiesta en tres áreas:

Cómo se toman las decisiones. Las cadenas siguen pasos predefinidos independientemente de lo que ocurra. Los agentes orientados a objetivos evalúan el resultado de cada paso y deciden qué hacer a continuación.

Cómo se almacena la información. Las cadenas retienen todo en el prompt: una vez que la ventana de contexto se llena, la información se pierde. Los agentes orientados a objetivos escriben los resultados en un almacenamiento externo y recuperan solo lo que necesitan.

Cómo se distribuye el trabajo. Las cadenas ejecutan todo de forma secuencial a través de un único modelo. Los agentes orientados a objetivos delegan tareas especializadas en subprocesos separados que se ejecutan de manera independiente.

La idea de ingeniería central es la del bucle de razonamiento iterativo. En lugar de asumir que el modelo puede analizar todo el problema en una sola pasada, se diseña para la iteración:

1. Planificar lo que debe suceder.
2. Ejecutar un paso.
3. Observar el resultado: ¿ha funcionado? ¿Se ha obtenido algún resultado inesperado?
4. Actualizar el plan en función de lo aprendido.
5. Repetir hasta cumplir el objetivo.

Sin este bucle, el agente intenta resolver 200 tickets en una sola pasada y empieza a mezclar a los clientes al llegar al ticket 50. Con él, cada resolución se fundamenta en el resultado de la anterior.

Planificar → Ejecutar → Observar → Actualizar: el bucle iterativo que permite a los agentes autocorregirse en lugar de comprometerse con una sola pasada.

Las cuatro capas en las que convergen los agentes en producción

Cuando los equipos de ingeniería rediseñan sus agentes de pasada única para convertirlos en sistemas que funcionen a escala, las arquitecturas resultantes tienden a parecerse. En todos los frameworks y sectores, se repiten cuatro capas.

La planificación crea la lista de tareas. La delegación asigna subagentes. La persistencia almacena artefactos fuera del contexto. La síntesis fusiona los resultados.

1. Planificación: separar la intención de la acción

El agente no intenta resolver los 200 tickets a la vez. Comienza creando una lista de tareas: clasificar los tickets por tipo, buscar las cuentas de los clientes, comprobar el historial de pedidos, aplicar las políticas correspondientes, redactar las resoluciones y marcar los casos que requieren escalado.

Esto es la planificación: separar lo que debe suceder del acto de hacerlo. La lista de tareas no es fija. Cuando el agente descubre que varios tickets pertenecen al mismo cliente y tratan sobre el mismo problema, los consolida. Cuando encuentra un tipo de ticket que no ha visto antes, añade un nuevo paso para gestionarlo.

Los agentes rudimentarios intentan resolver problemas complejos en una sola pasada. En tareas difíciles, esto provoca desviaciones: el modelo pierde el hilo de los requisitos o se compromete prematuramente con un enfoque que más tarde resulta erróneo. La planificación evita esto al hacer que las intenciones del agente sean explícitas y revisables.

El planificador genera una lista de tareas pendientes, pero esta es mutable: si el paso 3 falla o revela nueva información, los pasos 4 a 6 se reescriben automáticamente.

2. Delegación: asignar trabajo especializado a agentes especializados

Pedirle a un único modelo que busque datos de cuentas, interprete políticas de devolución y redacte respuestas para los clientes de forma simultánea sobrecarga un solo contexto con roles incompatibles. La calidad de los tres procesos se deteriora.

Los agentes orientados a objetivos solucionan esto mediante la delegación. Un orquestador (el agente principal) mantiene el objetivo general y asigna tareas delimitadas a subagentes especializados. Uno gestiona la búsqueda de cuentas y el historial de pedidos. Otro interpreta las políticas y determina la elegibilidad. Un tercero redacta las resoluciones dirigidas al cliente.

Cada subagente opera en su propio contexto aislado, centrado exclusivamente en su tarea específica. Solo el resultado final se devuelve al orquestador. Esto mantiene el proceso principal limpio y cada subtarea enfocada.

Cabe señalar que existe una contrapartida: cuando los subagentes trabajan en paralelo sin compartir contexto, pueden tomar decisiones contradictorias. Para tareas que requieren una coordinación estrecha, ejecutar los pasos de forma secuencial con un contexto comprimido suele funcionar mejor que paralelizar con información incompleta.

El orquestador mantiene el objetivo. La investigación, el código y la verificación se ejecutan en contextos de subagentes independientes, devolviendo únicamente resultados depurados.

3. Persistencia: memoria más allá de la ventana de contexto

El agente necesita recordar qué resolvió en el ticket 1 cuando está procesando el ticket 200. Sin embargo, ningún modelo puede retener simultáneamente en su ventana de contexto los datos de clientes, historiales de pedidos y consultas de políticas de 200 tickets.

La persistencia resuelve esto al dotar al agente de una memoria externa. A medida que el agente procesa cada ticket, escribe los resultados en un archivo o base de datos: detalles del cliente, consultas de pedidos, decisiones de políticas y borradores de resoluciones. Cuando necesita resultados anteriores, lee únicamente los fragmentos relevantes en lugar de mantener todo cargado.

Esto desvincula la complejidad del trabajo de las limitaciones de la memoria del modelo. La tarea puede crecer (200 tickets, 2.000 tickets) sin que la ventana de contexto se convierta en el cuello de botella. En el ejemplo de soporte, el agente procesó 200 tickets con la misma precisión que demostró con uno, porque cada resultado se almacenó externamente en lugar de comprimirse en un prompt cada vez más saturado.

Los agentes escriben notas, borradores y resultados intermedios en archivos; luego leen solo lo necesario, manteniendo el contexto ligero mientras las tareas crecen.

4. Síntesis: fusionar resultados en un único entregable

Una vez que el agente ha planificado, delegado y persistido los resultados de los 200 tickets, necesita generar un resultado final coherente; no 200 respuestas independientes, sino una cola resuelta con una aplicación de políticas consistente, escalados marcados y un resumen de la jornada.

Esto es la síntesis: fusionar subresultados paralelos en un único entregable. Funciona en dos fases:

Map. Cada subagente completa su tarea delimitada de forma independiente (buscar cuentas, aplicar políticas, redactar resoluciones). Estas se ejecutan en paralelo o de forma aislada, generando resultados individuales.

Reduce. El orquestador lee los resultados almacenados de todos los subagentes, resuelve las inconsistencias entre ellos, identifica patrones en los tickets y ensambla la cola final con un informe resumido.

Este patrón map-reduce es común en el procesamiento de datos y se aplica directamente a los flujos de trabajo de los agentes. La calidad del resultado final depende de que las cuatro capas colaboren: la planificación garantiza que no se pase nada por alto, la delegación asegura que cada parte sea gestionada por el especialista de TI adecuado, la persistencia garantiza que nada se olvide y la síntesis asegura que las partes formen un todo coherente.

Tres subagentes se ejecutan en paralelo, y un orquestador concilia sus resultados en un único entregable coherente.

Dónde se aplica esto

El agente de soporte es solo un ejemplo. La misma arquitectura se aplica a cualquier tarea en la que se conozca el objetivo pero no los pasos exactos.

Investigación y análisis. Un agente lee decenas de fuentes, toma notas, identifica contradicciones entre ellas y genera un informe estructurado con citas. Sin planificación ni persistencia, pierde el hilo de las fuentes al llegar al quinto documento.

Cambios de código en grandes repositorios. Un agente implementa una función que afecta a 15 archivos, ejecuta pruebas, detecta fallos, los corrige e itera hasta que la compilación es correcta. Sin delegación, intenta retener toda la base de código en un solo contexto.

Respuesta ante incidentes. Un agente investiga un problema en producción consultando registros, comprobando métricas, probando posibles soluciones y documentando lo que ha funcionado. Sin planificación dinámica, sigue un manual de instrucciones fijo incluso cuando las evidencias apuntan a otra parte.

Análisis de uso intensivo de datos. Un agente carga conjuntos de datos de gran tamaño en el almacenamiento externo, calcula resúmenes y refina progresivamente las consultas sin saturar el contexto. Sin persistencia, alcanza los límites de memoria con la primera tabla grande.

Cada uno de estos casos fracasa bajo una arquitectura de pasada única por las mismas razones estructurales que el agente de soporte.

Cuándo no utilizar este enfoque

No todo requiere un agente orientado a objetivos. La elección depende de la previsibilidad del trabajo.

Utilice flujos de trabajo fijos cuando se conozcan los pasos. Si el proceso es siempre el mismo (extraer estos tres campos, validar con este esquema, escribir en esta base de datos), codifíquelo. Los flujos de trabajo fijos son más rápidos, económicos y previsibles. También son más fáciles de auditar para el cumplimiento normativo.

Utilice agentes orientados a objetivos cuando no se conozcan los pasos. Cuando los resultados de las herramientas sean imprevisibles, cuando los requisitos evolucionen a mitad de la tarea o cuando los fallos requieran investigación en lugar de reintentos, permita que el agente decida el siguiente paso dinámicamente.

Combine ambos. Un agente orientado a objetivos puede invocar un flujo de trabajo fijo como una de sus herramientas: "ejecutar el pipeline de incorporación estándar para este cliente". Un flujo de trabajo fijo puede derivar la tarea a un agente en puntos de decisión específicos: "si la validación falla, investigar la causa raíz y recomendar una solución".

En la práctica, la mayoría de los sistemas en producción terminan utilizando ambos: pasos deterministas donde el proceso es estable y bucles de agentes donde no lo es.

Qué puede seguir fallando

Incluso los agentes con una arquitectura sólida presentan modos de fallo que no existen en sistemas más sencillos.

Desviación del objetivo. El agente se optimiza para una aproximación del objetivo real. El agente de soporte podría priorizar la velocidad de resolución sobre la precisión si sus criterios de éxito no son explícitos. Mitigación: establecer puntos de control donde los humanos revisen los resultados intermedios antes de que el agente continúe.

Acciones no seguras. Un agente con acceso de escritura a sistemas de producción puede causar daños. El agente de soporte podría enviar automáticamente resoluciones a los clientes sin revisión humana. Mitigación: definir límites de permisos, entornos de ejecución aislados (sandboxing) y filtros de aprobación para acciones de alto impacto.

Riesgos de memoria. Si el agente persiste información sensible en el almacenamiento externo, las políticas de retención y acceso deben diseñarse desde el principio. Lo que el agente recuerda, y durante cuánto tiempo, es fundamental.

Puntos ciegos de evaluación. Los sistemas de pasada única son fáciles de probar: entrada, resultado esperado, aprobado o suspenso. Los bucles de agentes que ejecutan decenas de pasos a través de múltiples subagentes son más difíciles de evaluar. Trate la observabilidad (registrar cada decisión, acción y resultado) como un requisito esencial desde el primer día, no como una solución tardía.

La arquitectura es el producto

El agente de soporte que falló con 200 tickets no necesitaba un modelo mejor. Necesitaba planificación para dividir el trabajo en pasos, delegación para gestionar diferentes tipos de resolución, persistencia para mantener la memoria entre tickets y síntesis para generar un resultado coherente.

Los agentes orientados a objetivos aplican conceptos estándar de ingeniería de software (gestión de estados, flujo de control, modularidad, observabilidad) a los LLM. Una vez que se adoptan los bucles de planificación, la memoria respaldada por herramientas y la delegación, el sistema deja de ser un simple prompt y comienza a comportarse como un programa capaz de perseguir objetivos.