¿Agente o flujo de trabajo? Separar el razonamiento de la ejecución en la IA empresarial

La IA agente es la expresión del momento. Dale a un LLM algunas herramientas, añade memoria, conéctalo a sistemas empresariales, déjalo decidir qué hacer a continuación, y el resultado se denomina agente de IA. Sin embargo, hay un problema: los sistemas empresariales no pueden funcionar únicamente con decisiones probabilísticas. Cuando una IA accede a registros de proveedores, procesos financieros, datos de ERP, aprobaciones u otras operaciones críticas, algunas decisiones pueden ser flexibles mientras que otras no.

Un proyecto de gestión de proveedores desarrollado con RAG, LangGraph, MCP, aprobación humana y Amazon Bedrock condujo a una idea guía: el agente debe decidir qué es necesario hacer, y la aplicación debe controlar cómo se lleva a cabo. Todo lo demás en el diseño deriva de esta división.

Por qué el agente no debería hacerlo todo

Imagínese una solicitud de incorporación de un proveedor: crear a este proveedor, validar sus datos, verificar la política de adquisiciones y enviarla a SAP. En teoría, un agente completamente autónomo podría interpretar la solicitud, buscar documentos internos, validar los datos, decidir si se necesita aprobación, conectarse a SAP, crear el registro e intentarlo de nuevo en caso de fallo.

Técnicamente es posible, pero arquitectónicamente poco atractivo. Un LLM es probabilístico; la misma entrada puede seguir rutas de razonamiento ligeramente diferentes, y los modelos, las instrucciones y el contexto pueden variar. Esa flexibilidad es excelente para interpretar lo que quiere decir una persona, pero resulta inadecuada para ejecutar transacciones comerciales críticas. Un modelo no debería decidir si una transacción en la base de datos se confirma, inventar su propia estrategia de intentos repetidos, juzgar si se puede omitir la autorización o poseer credenciales de SAP. Por lo tanto, el razonamiento y la ejecución quedan separados.

Flujos de trabajo versus agentes

A menudo se intercambian estos dos términos, pero la diferencia es importante. Un flujo de trabajo de IA sigue un camino en su mayor parte predefinido:

Request
   ↓
Validate
   ↓
Retrieve Policies
   ↓
Evaluate
   ↓
Approval
   ↓
Create Supplier
   ↓
Publish Integration Event

La aplicación conoce cada estado y cada transición. Un agente de IA tiene más libertad para elegir qué sucederá a continuación:

User Request
      ↓
     LLM
      ↓
Reason about intent
      ↓
Choose next capability
   ↙    ↓     ↘
Search Validate Request Approval

Esa libertad tiene valor, pero se vuelve arriesgada cuando el agente accede a la infraestructura transaccional. El diseño preferido combina ambos modelos.

Razonamiento agente en la capa superior, ejecución determinista en la inferior

A un nivel alto, la arquitectura se ve así:

USER
                      │
                      ▼
                 FastAPI API
                      │
                      ▼
                 LangGraph
                Agent Workflow
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
        RAG        Reasoning     Tools
          │
          ▼
   Amazon OpenSearch
          │
          ▼
     AWS Bedrock
                      │
                      ▼
                MCP Boundary
                      │
                      ▼
               Application API
                      │
                      ▼
              Domain / Use Cases
                      │
              ┌───────┴───────┐
              ▼               ▼
          PostgreSQL         AWS SQS
                                │
                                ▼
                               SAP

Hay un límite que destaca. El LLM se encuentra por encima de la capa de aplicación. Puede interpretar solicitudes, razonar, recuperar conocimiento, recomendar acciones y solicitar herramientas. No controla la transacción.

Dónde ganan su lugar los agentes

El razonamiento probabilístico es útil en algunos casos específicos.

Comprensión de la intención

Las personas no realizan llamadas a API perfectamente estructuradas. Un usuario podría decir que necesita integrar ACME para una operación en Brasil y quiere saber si todo cumple con los requisitos. Esa oración mezcla intención, contexto y ambigüedades, y un LLM es muy bueno para transformarla en algo que la aplicación pueda procesar:

{
  "intent": "supplier_onboarding",
  "supplier": "ACME",
  "country": "BR",
  "requires_policy_validation": true
}

A partir de ahí, asume el control el software determinista.

Obtención del conocimiento empresarial con RAG

El proceso de incorporación depende de la política interna: documentos requeridos, normas fiscales, requisitos específicos por país, restricciones en las adquisiciones y umbrales de aprobación. En lugar de incluir esos documentos en los prompts o codificar manualmente cada regla, el sistema puede recuperarlos:

Question
   ↓
Embedding
   ↓
Amazon OpenSearch
   ↓
Relevant Policy Chunks
   ↓
LLM Context
   ↓
Reasoning

Aquí se aplica un segundo límite. La recuperación de información proporciona contexto y no debe interferir en las decisiones empresariales. Es útil encontrar una política que establezca que los proveedores por encima de un umbral necesitan aprobación. La aplicación de dicha aprobación debe seguir siendo parte de la lógica habitual de la aplicación.

Dónde los flujos de trabajo son más eficaces

Una vez que se comprende la solicitud, supongamos que es necesario crear un proveedor. El proceso puede incluir pasos como estos:

Validate Supplier
      ↓
Check Duplicate
      ↓
Check Authorization
      ↓
Persist Supplier
      ↓
Publish Integration Event
      ↓
Wait for SAP Result

Un LLM no debería improvisar esto. El flujo de trabajo debe definir las garantías de ejecución: validación, autorización, idempotencia, prevención de duplicados, reintentos, registros de auditoría, límites de transacciones y manejo de errores. Esas son cuestiones propias de la ingeniería de software, y la ingeniería de prompts no tiene nada que ver con ellas.

Por qué LangGraph

Para la orquestación, se eligió LangGraph porque ofrece transiciones de estado explícitas, en lugar de un bucle abierto donde un agente sigue decidiendo qué herramienta llamar a continuación. Conceptualmente, el grafo se ve así:

START
  │
  ▼
Understand Intent
  │
  ▼
Retrieve Policies
  │
  ▼
Evaluate Request
  │
  ├───────────────┐
  │               │
  ▼               ▼
Approval Needed?  No Approval
  │               │
  ▼               │
Human Approval    │
  │               │
  └───────┬───────┘
          ▼
     Request Action
          │
          ▼
         END

Dentro de los nodos seleccionados, el modelo mantiene su libertad para razonar, mientras que el grafo limita hasta qué punto sus conclusiones pueden influir en el sistema. El resultado es una autonomía delimitada: libertad dentro de líneas arquitectónicas claramente definidas.

El concepto de “humano en el proceso” tiene más de un significado

Con frecuencia, las conversaciones sobre IA empresarial se reducen a “simplemente incluir a un humano en el proceso”. Sin embargo, las personas pueden intervenir por diferentes razones, y al menos dos tipos de aprobación merecen ser diferenciados.

Aprobación empresarial

El propio proceso empresarial exige una aprobación, independientemente de que participe o no la IA:

Supplier
   ↓
Compliance Check
   ↓
Manager Approval
   ↓
Creation

Aprobación de la herramienta de IA

Surge una segunda aprobación porque el agente desea realizar una acción sensible:

Agent
  ↓
"Create supplier"
  ↓
Tool requires confirmation
  ↓
Human approves
  ↓
Application executes

Estas dos cuestiones son diferentes. Una pertenece al ámbito de la arquitectura y la otra a la gobernanza de la IA. Mezclarlas genera confusión arquitectónica.

Por qué es importante MCP

Un agente que trabaja con sistemas empresariales necesita herramientas, pero exponer la infraestructura directamente al LLM añade riesgos innecesarios. La mejor opción es utilizar una herramienta MCP:

Agent
  ↓
MCP Tool
  ↓
Application API
  ↓
Use Case
  ↓
Domain
  ↓
Infrastructure

y evita conectar al agente con una base de datos:

Agent
  ↓
PostgreSQL

o directamente a SAP:

Agent
  ↓
SAP

Con la primera forma, la aplicación sigue controlando la autenticación, autorización, validación, reglas de negocio, auditoría, transacciones e idempotencia. MCP se convierte en un límite entre el razonamiento de la IA y las capacidades empresariales. El agente expresa la intención y la aplicación se encarga de su ejecución.

SAP no debe depender de que el LLM esté activo

Los sistemas externos fallan. SAP puede estar inactivo, la red puede interrumpirse, un servicio posterior puede agotar su tiempo de espera, y el proveedor del LLM también puede quedar fuera de línea. Ejecutar todo de forma síncrona dentro de un bucle de agente dificulta la resiliencia. Esa es la razón del uso de mensajería asíncrona con AWS SQS. En lugar de esto:

Agent
  ↓
SAP
  ↓
Wait...
  ↓
Timeout

El flujo se convierte en:

Agent
  ↓
Application
  ↓
Persist State
  ↓
AWS SQS
  ↓
Integration Worker
  ↓
SAP

La transacción empresarial ya no espera a que SAP responda de inmediato. Un operario se encarga de los intentos repetidos, la estrategia de retraso, las colas de mensajes no entregados, la capacidad de observabilidad y el procesamiento idempotente, y esas garantías provienen de software determinista y no de un modelo.

Una arquitectura híbrida

Una vez establecidos estos límites, denominar al sistema simplemente como un agente de IA ya no es adecuado. Se trata de una arquitectura híbrida:

┌─────────────────────────────┐
│     PROBABILISTIC LAYER     │
│                             │
│ LLM                         │
│ RAG                         │
│ Intent Understanding        │
│ Reasoning                   │
│ Tool Selection              │
└──────────────┬──────────────┘
               │
        Controlled Boundary
               │
┌──────────────▼──────────────┐
│     DETERMINISTIC LAYER     │
│                             │
│ Application Use Cases       │
│ Domain Rules                │
│ Authorization               │
│ Validation                  │
│ Transactions                │
│ Idempotency                 │
│ Messaging                   │
│ Integrations                │
└─────────────────────────────┘

Esa distinción es esencial para la IA agente empresarial.

La arquitectura de software sigue siendo importante

Un error común con la IA generativa es asumir que la arquitectura tradicional ya no tiene relevancia. Al contrario, sigue siendo crucial. Un sistema que puede razonar de forma dinámica y elegir acciones necesita límites más estrictos sobre lo que esas acciones pueden hacer. El DDD, CQRS, la arquitectura hexagonal, la autenticación, la autorización, las comunicaciones entre sistemas, la observabilidad, la resiliencia y la idempotencia siguen siendo aplicables. La IA no elimina ninguno de ellos; simplemente añade un componente probabilístico más que debe funcionar de forma segura junto a ellos.

¿Agente o flujo de trabajo?

La respuesta es ambos. Utilice agentes cuando la incertidumbre y el razonamiento aporten valor, y utilice flujos de trabajo deterministas cuando la previsibilidad y las garantías sean importantes. Un modelo mental útil:

AI AGENT
                 │
                 │ decides WHAT
                 ▼
        ┌─────────────────┐
        │ Controlled Tool │
        │    Boundary     │
        └────────┬────────┘
                 │
                 │ requests
                 ▼
          APPLICATION
                 │
                 │ decides HOW
                 ▼
             DOMAIN
                 │
                 ▼
        INFRASTRUCTURE

El LLM no debería convertirse en la arquitectura; debería formar parte de ella.

Dónde la autonomía rinde frutos

La pregunta relevante no es cuánta autonomía se puede otorgar a un modelo, sino dónde la autonomía genera valor. La autonomía es útil para interpretar solicitudes vagas, buscar entre una gran cantidad de documentos internos, razonar sobre el contexto y proponer la siguiente acción. No sirve para anular reglas empresariales, gestionar transacciones ni manejar credenciales de bases de datos de producción.

El objetivo es una autonomía controlada, lo que en los sistemas empresariales implica combinar el razonamiento basado en inteligencia artificial probabilística con la ingeniería determinista. La siguiente pregunta surge de forma natural: cuando un agente debe acceder a SAP o a una base de datos, ¿cómo debería ser ese límite exactamente?