Flujos agénticos: cuando la IA orquesta su propio camino

En los capítulos anteriores construimos las piezas por separado: RAG (Capítulo 5, el modelo consulta documentos), MCP (Capítulo 5c, la aplicación conecta herramientas y sistemas externos) y memoria. Pero tener las piezas no es suficiente — un sistema útil necesita orquestarlas de forma inteligente. Eso es un flujo agéntico: un sistema dinámico de múltiples pasos donde el LLM decide qué información necesita, en qué orden obtenerla, qué herramientas usar y cómo responder para resolver un objetivo de principio a fin.

¿Qué es un agente? (y qué no es)

Para este compendio, un agente de IA es un sistema que tiene un objetivo, puede percibir su entorno (prompts, herramientas, memoria), puede actuar sobre ese entorno, toma decisiones autónomas sobre qué pasos seguir y se adapta dentro de los límites que le impone el sistema.

Lo que NO es un agente, bajo esta definición operativa:

• Un pipeline determinista (“Paso 1: política. Paso 2: saldo. Paso 3: calendario.”) — si el orden siempre es el mismo y no hay decisión real, es un flujo fijo, no un agente. Esto es exactamente lo que distinguimos en el Capítulo 6b: los patrones secuencial, paralelo y de bucle pueden estar orquestados por código, no por el LLM. Pueden usar modelos en sus pasos sin convertirse por eso en agentes autónomos.
• Una sola llamada al LLM, por sofisticada que sea la respuesta.
• Un sistema sin capacidad de interactuar con su entorno — si solo contesta una vez y no puede consultar ni modificar nada, funciona como chatbot, no como el tipo de agente que estudiamos aquí.

Estas fronteras no son universales: la industria usa la palabra agente con definiciones más amplias y más estrechas. Lo importante es declarar qué decisiones toma el modelo y cuáles siguen codificadas.

Analogía: un agente es como un asistente personal humano. Le dices “quiero irme de vacaciones la próxima semana”, y decide qué consultar, en qué orden, propone alternativas si hay un problema y confirma contigo antes de actuar. Un pipeline determinista, en cambio, es como una máquina expendedora: insertas moneda, eliges producto, recibes producto — sin decisión ni adaptación.

El escenario: nuestro agente de RR.HH.

Un empleado escribe: “Oye, quiero tomarme unos días la próxima semana para ir a la playa — ¿qué necesito hacer?”

Un sistema RAG tradicional buscaría la política y devolvería un fragmento genérico — no resolvería la pregunta, porque no sabe el saldo personal ni la disponibilidad del equipo. Un sistema con RAG + MCP pero sin agente ejecutaría una secuencia fija: política → saldo → calendario → responder. Funcionaría para este caso, pero podría fallar si el empleado dice “en realidad, mejor dos semanas seguidas, pero no sé si puedo” y esa rama no fue programada. Un agente decide el flujo en tiempo real: reconoce qué información falta, decide el orden, propone alternativas dentro de sus permisos si hace falta y confirma antes de actuar.

La “ingeniería difusa”: de código determinista a decisiones probabilísticas

En software tradicional, el flujo se expresa con reglas deterministas: hay que anticipar estados relevantes y codificar su respuesta. El problema es que el mundo real puede producir una enorme cantidad de combinaciones. ¿Qué pasa si el empleado tiene saldo pero el equipo está lleno? ¿Si pide una fecha festiva? ¿Si pide tres semanas y la política permite dos como máximo? Una red creciente de if/else puede volverse frágil, costosa y difícil de mantener.

En el enfoque agéntico (difuso), el LLM razona en lenguaje natural sobre qué necesita hacer. No se codifica cada rama; se codifican herramientas acotadas, políticas, permisos e instrucciones, y el modelo propone un camino.

Analogía: un GPS con una ruta estática solo conoce el trayecto calculado. Un navegante conoce objetivos y restricciones, puede reaccionar al tráfico y sugerir alternativas.

La contrapartida es que el comportamiento agéntico es probabilístico — la misma pregunta puede generar decisiones ligeramente distintas entre ejecuciones por el muestreo y por cambios de contexto. Es un problema para sistemas que necesitan consistencia absoluta, pero una ventaja al manejar casos borde. Por eso las restricciones críticas no deben depender únicamente de que el modelo “recuerde” obedecerlas: también se aplican en código y en los servidores de herramientas.

Caso de estudio (Workera): Workera combina evaluaciones deterministas para respuestas fijas con evaluaciones que requieren juicio, como juegos de rol conversacionales. Su mecanismo Score Appeal permite solicitar revisión humana cuando una persona cuestiona la evaluación. Es un ejemplo de humano en el bucle: la IA escala el primer análisis, pero una decisión discutida puede ser revisada y corregida por especialistas.

Los cuatro pilares de un agente

1. Prompts (la identidad y las reglas)

Eres un asistente de RR.HH. especializado en solicitudes de tiempo libre.

Tus reglas:
1. Verifica la política general (RAG) antes de dar información.
2. Consulta el saldo personal del empleado mediante una herramienta autorizada.
3. Verifica la disponibilidad del equipo para las fechas solicitadas.
4. Si hay conflicto, ofrece alternativas permitidas.
5. NUNCA envíes una solicitud sin confirmación explícita del empleado.
6. Si no tienes información suficiente, pide aclaraciones; no adivines.

El prompt puede incluir ejemplos de buen comportamiento (few-shot, Capítulo 2), criterios explícitos de decisión y pasos de verificación. No basta por sí solo para imponer seguridad: las restricciones de autorización y efectos reales también deben existir fuera del prompt.

2. Memoria (el conocimiento acumulado)

• Memoria de trabajo: el contexto de la conversación actual — historial de mensajes, resultados de herramientas ya invocadas y estado del flujo. Se suministra al modelo en cada paso. Es rápida y simple, pero está limitada por la ventana de contexto y aumenta el consumo de tokens.
• Memoria semántica: hechos generales relativamente estables — por ejemplo, la política de vacaciones. Puede implementarse mediante RAG (base vectorial + embeddings) y actualizarse al reindexar los documentos.
• Memoria episódica: eventos específicos de interacciones pasadas — por ejemplo, “en una conversación anterior el empleado prefirió viajar en la primera semana del mes” o “se inició una solicitud con este identificador”. Puede almacenarse en una base vectorial o en un registro estructurado, según el tipo de consulta.

La memoria episódica no debe sustituir la fuente de verdad operativa. Que una interacción pasada diga “solicitud pendiente” no garantiza que siga pendiente: el agente debe volver a consultar el sistema de RR.HH. antes de tomar una decisión actual.

Aclaración importante, otra vez: MCP no es memoria. Consultar el saldo en tiempo real no es “recordar” — es obtener un dato que cambia y que una memoria vectorizada podría tener desactualizado. MCP encaja en el siguiente pilar, herramientas y sistemas externos.

3. Herramientas (en este caso, vía MCP)

consultar_saldo_vacaciones, consultar_calendario_equipo, solicitar_vacaciones — cada una es una operación con parámetros tipados, descripción clara y permisos aplicados por el servidor (Capítulo 5c). El host descubre qué hay disponible y el agente propone cuáles usar y en qué orden.

MCP es una forma estandarizada de conectar esas herramientas, no un requisito conceptual para que exista un agente.

4. Grados de autonomía

Grado	Descripción	Ejemplo en nuestro caso	Ventaja	Desventaja
Bajo	Pasos rígidos, codificados por el desarrollador	Política → saldo → calendario → responder, siempre en ese orden	Predecible, fácil de depurar	No maneja casos borde no programados
Medio	El agente decide el orden, bajo reglas de seguridad	Decide si verificar primero calendario o saldo; puede saltar consultas innecesarias	Flexible, maneja más variantes	Comportamiento menos predecible
Alto	El agente decide el flujo completo dentro de permisos definidos	Si el equipo está lleno, consulta semanas alternativas sin que se le pida	Máxima flexibilidad	Mayor riesgo, costo y dificultad de evaluación

Punto de partida recomendado: empieza con autonomía baja o media. Sube a alta solo cuando evals robustos (Capítulo 3) confirmen el comportamiento y existan límites aplicados fuera del modelo. El caso de Tay del Capítulo 1 muestra el riesgo de un sistema adaptativo expuesto sin barreras suficientes, aunque su mecanismo no era idéntico al de un agente moderno.

El flujo completo, paso a paso

Paso 1 — Memoria de trabajo: el agente recibe el mensaje y determina que faltan política, saldo y disponibilidad de equipo.

Paso 2 — Descubrimiento de herramientas: consulta qué hay disponible o usa una lista cacheada cuya vigencia controla el host.

Paso 3 — Ejecución, según el grado de autonomía:

Con autonomía baja (código determinista):

politica = consultar_politica_general("vacaciones")
saldo = consultar_saldo_vacaciones(empleado_id)
disponibilidad = consultar_calendario_equipo(fecha_inicio, fecha_fin)
respuesta = generar_respuesta(politica, saldo, disponibilidad)

Con autonomía media o alta, el LLM puede construir un plan: “Primero verifico el saldo. Si no tiene días disponibles, no necesito consultar el calendario. Si alcanza, verifico la disponibilidad.” Después ejecuta consultar_saldo_vacaciones → 12 días disponibles → consultar_calendario_equipo → alta disponibilidad. Si el calendario estuviera lleno y sus permisos lo permiten, podría consultar semanas alternativas.

Paso 4 — Síntesis: el agente integra política, saldo, calendario e historial relevante, y responde: “Tienes 12 días disponibles. La próxima semana el equipo tiene buena disponibilidad. ¿Tramito la solicitud?” Los 12 días provienen de la consulta en vivo, no de memoria episódica.

Paso 5 — Confirmación y acción: el usuario confirma. El agente ejecuta solicitar_vacaciones vía MCP — nunca antes de la confirmación explícita.

Paso 6 — Actualización de memoria episódica:

{
  "empleado_id": "emp_12345",
  "evento": "solicitud_vacaciones",
  "solicitud_id": "VAC-2026-8473",
  "fecha_inicio": "2026-09-01",
  "fecha_fin": "2026-09-07",
  "estado_observado": "pendiente"
}

La próxima vez, este recuerdo puede ayudar a decidir qué consultar, pero el estado vigente debe verificarse en el sistema de RR.HH. usando solicitud_id.

El flujo agéntico como un bucle — la misma idea que ReAct, con más granularidad

Un agente no es necesariamente una ejecución secuencial única — puede recorrer un bucle hasta alcanzar el objetivo, pedir ayuda o llegar a un límite:

1. Percibir → recibir entrada del usuario o del entorno
2. Razonar  → decidir qué información falta y qué hacer
3. Actuar   → llamar a herramientas o consultar memoria
4. Evaluar  → comprobar si se alcanzó el objetivo o falta algo
5. Iterar   → volver al ciclo con la nueva información

Esto no es un concepto nuevo y separado — es, en esencia, el mismo patrón ReAct (Reason → Act → Observe) que cubrimos en el Capítulo 6b con la investigación del cheque de nómina. Ahí aparece en tres movimientos; aquí lo descomponemos en cinco, separando explícitamente “percibir” de “razonar”, y “evaluar” de “iterar”. La idea central es idéntica: razonar, actuar, observar el resultado y repetir hasta terminar.

Cada iteración añade información a la memoria de trabajo. Para evitar bucles ilimitados, el sistema debe definir un máximo de iteraciones, presupuestos de costo y tiempo, y una condición de salida o escalamiento humano.

Por qué esto no es solo “RAG + MCP juntos”

Aspecto	Pipeline (RAG + MCP)	Agente (flujo agéntico)
Orden de ejecución	Fijo, codificado	Decidido por el LLM dentro de límites
Manejo de casos borde	Limitado a lo programado	Puede proponer rutas no enumeradas explícitamente
Memoria	Puede tener memoria de trabajo	Puede consultar y actualizar memoria de distintos tipos
Adaptabilidad	Requiere modificar el flujo	Puede variar el plan en tiempo de ejecución

Analogía: un pipeline es una receta de cocina. Un agente es un chef con experiencia — conoce ingredientes y herramientas, e improvisa si falta algo. Técnicamente ya teníamos RAG y MCP en capítulos anteriores; lo que convierte esto en un flujo agéntico no es tener las piezas, sino cómo se decide su orquestación.

Los patrones de organización — vista previa

Existen patrones específicos para organizar varios agentes o pasos — secuencial, paralelo, coordinador, jerárquico, swarm y más. Los cubrimos a fondo en el Capítulo 6b, con ejemplos propios completos: recibos de gastos como flujo secuencial, encuesta de clima como paralelo y enrutamiento de mensajes mediante coordinador, entre otros. No repetimos aquí su tabla ni su explicación.

Nuestro caso de vacaciones usa principalmente autonomía media dentro de un solo agente. No necesita todavía la complejidad de múltiples agentes coordinados.

Los desafíos de los flujos agénticos, y cómo mitigarlos

Comportamiento impredecible (especialmente con autonomía alta): empezar con autonomía baja o media, usar evals (Capítulo 3), mantener trazas de decisiones y aplicar guardrails tanto en el host como en las herramientas.

Acumulación de contexto: cada iteración añade tokens; con muchas iteraciones la ventana puede saturarse. Mitigación: resumir historial con cuidado, recuperar solo información pertinente y limitar el número máximo de iteraciones.

Costo y latencia: cada iteración puede implicar una llamada al LLM y varias llamadas a herramientas. Mitigación: modelos pequeños para decisiones simples, paralelismo cuando no existan dependencias, caché de datos estables y presupuestos por ejecución.

Seguridad: un agente puede ser manipulado para proponer acciones no deseadas — el riesgo de inyección indirecta que ilustra Finnbot en Parte III. Mitigación: autorización y validación estrictas en cada herramienta, confirmación humana para acciones de impacto, mínimo privilegio y auditoría completa.

Resumen del capítulo

Un flujo agéntico es un sistema de múltiples pasos donde el LLM participa en la decisión del camino para alcanzar un objetivo:

• Qué es un agente (y qué no): bajo nuestra definición, percibe, actúa y decide entre pasos — no es solo un pipeline fijo ni una llamada aislada.
• Ingeniería difusa: decisiones probabilísticas que manejan variantes, acompañadas de límites deterministas.
• Cuatro pilares: prompts, memoria, herramientas y grados de autonomía.
• El bucle agéntico es el mismo principio central de ReAct del Capítulo 6b, descrito aquí con más granularidad.
• Los patrones secuencial, paralelo, coordinador y otros se cubren en profundidad en el Capítulo 6b, sin duplicarlos aquí.
• Impredecibilidad, contexto, costo y seguridad requieren mitigaciones concretas y medibles.

En el siguiente capítulo (6b) profundizaremos en los patrones de arquitectura agéntica; después veremos sistemas multi-agente, para los casos donde un solo agente no basta.