Un agente empresarial es mucho más que un LLM con herramientas

«Un LLM con herramientas» es la definición de agente que vende el
marketing. Y es, además, falsa: un LLM con herramientas que no sabe quién
es, qué puede hacer, qué recuerda ni qué sabe, no es un agente. Es un
chatbot con manos. La diferencia entre ambos es un conjunto de capas que
hoy desmontamos una a una.

Introducción

Hemos construido, a lo largo de la serie, todas las piezas que un agente
necesita: conocimiento, memoria, contexto, razonamiento. Y en el Día 1
vimos un agente de procurement que fracasó porque solo tenía un LLM
conectado a documentos.

Hoy cerramos el círculo: qué es, en realidad, un agente empresarial. Y
lo hacemos con una advertencia: la definición de moda —»un LLM con
herramientas»— es incompleta a un nivel que importa. Porque un LLM con
herramientas puede hacer cosas, pero no puede operar dentro de una
organización. Y operar dentro de una organización exige un conjunto de
capas que no tienen nada que ver con el modelo.

El problema

Revisemos el agente de procurement del Día 1. Hoy, tres años después,
muchas empresas lo han «mejorado» exactamente igual: le han añadido
herramientas. Puede leer el ERP, redactar emails, crear borradores de
pedido. Y sigue fallando, pero ahora de formas más caras:

• Crea un borrador de pedido a un proveedor, pero no sabe que ese proveedor
  está en un proceso de exclusión (no tiene identidad ni políticas).
• Ejecuta una acción (envía el pedido) sin que nadie la haya aprobado (no
  tiene supervisión humana ni permisos).
• Nadie sabe por qué creó ese pedido ni qué contexto usó (no tiene
  observabilidad ni trazabilidad).
• Y cuando se equivoca, no hay forma de medirlo ni de corregirlo (no tiene
  evaluación).

El patrón: añadir herramientas a un LLM no lo convierte en un agente
empresarial. Le da manos, pero no le da identidad, memoria, contexto,
conocimiento, políticas, permisos, observabilidad ni evaluación. Y sin
esas capas, las manos hacen cosas que no deberían, sin que nadie lo sepa.

El concepto

Un agente empresarial no es un LLM con herramientas. Es un sistema con
autonomía orientada a un objetivo que opera dentro de los límites de una
organización. Y para operar dentro de esos límites necesita un conjunto de
capas. Desmontémoslas:

1. LLM (motor de razonamiento). El razonador sobre lenguaje. Lo vimos en
   el Día 14: razona sobre lenguaje y generalización, no sobre reglas ni
   aritmética.
2. Memory (memoria). Lo que recuerda: episódica, semántica, procedural
   (días 9, 12). Sin memoria, empieza de cero en cada tarea.
3. Context (contexto). Lo que trae en cada decisión, construido
   dinámicamente (días 10, 13). Sin contexto, elige del ruido.
4. Knowledge (conocimiento). El conocimiento estable del dominio: grafo +
   RAG (días 7, 8, 11). Sin conocimiento, no sabe qué es qué.
5. Ontology (ontología). El modelo del dominio y sus restricciones
   (día 4). Sin ontología, no puede verificar que respeta el dominio.
6. Retrieval (recuperación). El mecanismo para traer el conocimiento y el
   contexto en el momento (día 8, 13).
7. Tools (herramientas). Las APIs y acciones que el agente puede
   ejecutar: leer el ERP, crear un pedido, enviar un email. (Lo que el
   marketing llama «el agente».)
8. Policies (políticas). Las reglas de negocio y de riesgo que el agente
   debe respetar: umbrales, restricciones, requisitos de aprobación (día 14).
9. Identity (identidad). Quién es el agente: un identificador único, con
   un rol y un alcance declarado. Un agente sin identidad es un proceso
   anónimo que no se puede auditar.
10. Permissions (permisos). Qué puede hacer y ver el agente, con el
    principio de mínimo privilegio: solo los datos y sistemas estrictamente
    necesarios para su función.
11. Observability (observabilidad). Lo que el agente hace queda
    registrado: qué decisiones tomó, qué contexto usó, qué herramientas
    invocó. Sin observabilidad, es una caja negra.
12. Evaluation (evaluación). Cómo se mide que el agente funciona bien:
    métricas de fiabilidad, de negocio, de seguridad. Y cómo se corrige
    cuando no.

Doce capas. El LLM es una de ellas. Las otras once son lo que convierte un
«LLM con herramientas» en un agente que puede operar dentro de una
organización. Y la distinción práctica es:

• Chatbot: responde preguntas dentro de un guion. (LLM + retrieval.)
• RPA: ejecuta reglas fijas («si X, haz Y»). (Tools + policies, sin
  razonamiento.)
• Agente: entiende un objetivo, decide qué pasos dar, qué herramientas
  usar y cuándo pedir ayuda humana, operando dentro de identidad, permisos,
  políticas y observabilidad. (Las doce capas.)

El salto de chatbot a agente no es añadir un LLM: es añadir las once capas
que faltan. Y esas capas son, precisamente, la infraestructura cognitiva que
hemos estado describiendo toda la serie.

Arquitectura

En el diagrama de la serie, el agente es la capa superior, y las doce capas
son su anatomía:

              AGENTE EMPRESARIAL
   ┌─────────────────────────────────────────┐
   │ LLM · Memory · Context · Knowledge      │
   │ Ontology · Retrieval · Tools            │
   │ Policies · Identity · Permissions       │
   │ Observability · Evaluation              │
   └─────────────────────────────────────────┘
                 ↓
   COGNITIVE INFRASTRUCTURE
   (Knowledge + Memory + Context + Reasoning)
                 ↓
   KNOWLEDGE & DATA SYSTEMS
                 ↓
   ENTERPRISE SYSTEMS

El agente no es la infraestructura cognitiva: la usa. La infraestructura
cognitiva es la capa que proporciona conocimiento, memoria, contexto y
razonamiento; el agente es la capa que las orquesta para perseguir un
objetivo y actuar. Y la gobernanza (identidad, permisos, observabilidad,
evaluación) es lo que permite que esa orquestación sea segura y auditable.

Caso de uso

El agente de procurement del Día 1, ahora con las doce capas. Descomponemos
la misma decisión de entonces —validar y aprobar un pedido— pero con la
anatomía completa:

1. Problema. Validar un pedido propuesto contra el contrato marco
   vigente y las políticas de compra, y proponer la aprobación.
2. Decisión. Aprobar, rechazar o escalar el pedido.
3. Conocimiento necesario (Knowledge + Ontology). El contrato marco
   vigente; las restricciones de compra; los umbrales de aprobación; la
   identidad del proveedor.
4. Memoria (Memory). Las conversaciones previas con el proveedor; la
   última revisión del contrato; la incidencia de entrega del trimestre
   pasado.
5. Contexto (Context). Quién hace la petición (y sus permisos); la fecha
   (qué contrato está vigente); la etapa del proceso; el nivel de riesgo.
6. Recuperación (Retrieval). Traer el contrato vigente, la política de
   descuentos y la memoria del proveedor en el momento de la decisión.
7. Herramientas (Tools). Leer el pedido en el ERP; crear la solicitud de
   aprobación; escalar al comprador.
8. Políticas (Policies). «Descuento > 15 % requiere aprobación del
   director»; «el proveedor X está en proceso de exclusión».
9. Identidad (Identity). El agente es «Agente de Procurement v2», con
   rol de comprador junior y un alcance declarado.
10. Permisos (Permissions). Puede leer pedidos y contratos de su área;
    no puede aprobar descuentos > 15 %; no puede ver proveedores de otras
    áreas.
11. Observability (Observability). Cada decisión queda registrada: qué
    pedido, qué contrato, qué política aplicada, qué contexto, qué acción.
12. Evaluación (Evaluation). Métrica: % de pedidos validados sin error;
    tasa de escalamientos correctos; y revisión periódica de las decisiones
    para detectar desviaciones.

Y la decisión, con las doce capas: el agente lee el pedido (tools), trae el
contrato vigente y la política (retrieval + context), verifica que el
descuento (12 %) está dentro del umbral del comprador junior (policies +
reasoning, día 14), comprueba que el proveedor no está en exclusión
(knowledge + identity), crea la solicitud de aprobación (tools), y registra
todo (observability). Si el descuento hubiera sido del 18 %, el agente lo
habría escalado al director (policies + permissions), con la justificación
(registro).

La diferencia con el Día 1 es total: el mismo LLM, pero ahora con identidad,
permisos, políticas, memoria, contexto y observabilidad. Y ahora la decisión
se puede auditar de principio a fin.

Trade-offs

• Coste. Las doce capas son doce subsistemas. Un agente con identidad,
  permisos, observabilidad y evaluación es más caro de construir y operar
  que un «LLM con herramientas».
• Complejidad. La integración de las doce capas es un proyecto de
  arquitectura. Y la gobernanza (identidad, permisos) exige coordinar con
  seguridad y compliance, no solo con el equipo de IA.
• Latencia. Cada capa añade pasos. Un agente con verificación de
  políticas y registro es más lento que un chatbot. En dominios de riesgo,
  esa latencia es la que compra la seguridad.
• Mantenimiento. Las políticas, los permisos y las herramientas cambian.
  El agente tiene que actualizarse o empieza a operar con reglas obsoletas.
• Superfície de ataque. Un agente con permisos y herramientas es una
  superficie de ataque. El principio de mínimo privilegio (permisos) y la
  supervisión humana son las defensas principales.
• Limitación honesta: las doce capas no hacen que el agente sea
  infalible. Hacen que sus fallos sean visibles, auditables y
  acotados. Un agente con observabilidad que falla avisa; uno sin ella
  falla en silencio.

Implicación para la empresa

Para el CTO, la anatomía de doce capas es la checklist de un agente
empresarial: si le faltan identidad, permisos, observabilidad o evaluación,
no es un agente, es un chatbot con manos. Y esas capas no son opcionales:
son lo que permite desplegar el agente en producción.

Para el CISO (seguridad) y compliance, la implicación es la más importante:
un agente sin identidad ni permisos es un proceso anónimo que actúa sobre
los sistemas de la empresa. La identidad y el principio de mínimo privilegio
son lo que convierte a un agente en un actor responsable, y son lo que un
regulador (o un auditor) va a exigir.

Para la alta dirección, el mensaje es de madurez: el salto de chatbot a
agente no es una cuestión de modelo, es una cuestión de infraestructura. Y
esa infraestructura es, literalmente, la que hemos estado describiendo
durante veinte días.

Conclusión

Un agente empresarial no es un LLM con herramientas: es un sistema con doce
capas (LLM, memoria, contexto, conocimiento, ontología, recuperación,
herramientas, políticas, identidad, permisos, observabilidad, evaluación)
que le permiten operar dentro de los límites de una organización. El LLM es
el motor; las otras once capas son el chasis, el volante y el cinturón de
seguridad. Y ese conjunto es, precisamente, la infraestructura cognitiva.

Hemos descrito el agente. Pero el agente no existe solo: se apoya en una
capa que lo sostiene, y esa capa por fin merece un nombre. Mañana le damos
uno, y con él cerramos la construcción: ¿Qué es una Infraestructura
Cognitiva Empresarial?

Siguiente artículo

Mañana: ¿Qué es una Infraestructura Cognitiva Empresarial?. El artículo
pilar de la serie: la definición canónica, los componentes, qué problemas
resuelve (y cuáles no), y cómo se integra en una arquitectura empresarial
existente.

Fuentes

• Definición de trabajo de la ICE: ver serie, Día 1.
• La distinción chatbot / RPA / agente y la anatomía por capas son
  coherentes con el contenido de Cirtra, «How to Implement AI Agents in the
  Enterprise» (2026), y con la literatura de agentic AI.