La arquitectura de 3 capas para agentes de IA en producción

En uno de los agentes que operamos para un cliente del sector contable, la capa que ejecutaba las acciones vivía originalmente en código Python. Funcionaba. El problema no era técnico: el equipo contable del cliente no podía leer ni auditar esa lógica sin depender de un desarrollador cada vez que necesitaba confirmar qué hacía el agente exactamente. La migramos deliberadamente a flujos visuales de n8n —no por rendimiento, sino porque auditabilidad también es un requisito de producción, no solo velocidad o precisión.

Ese caso ilustra el problema de fondo: es tentador conectar un modelo de lenguaje directamente a un proceso empresarial —que el LLM lea el mensaje del cliente, decida qué hacer y ejecute la acción, todo en un mismo paso—. Funciona bien en una demo. En producción, un LLM es probabilístico por diseño —la misma entrada puede producir salidas ligeramente distintas— y un proceso de negocio necesita ser consistente y auditable. Descontar inventario, generar una factura o modificar un registro contable no pueden depender de que el modelo "interprete bien" en cada ejecución, ni pueden quedar ocultos dentro de una caja negra de código que solo un desarrollador entiende.

La respuesta no es dejar de usar IA. Es no dejar que la IA sea la única que decide, ejecuta y guarda el registro de las partes donde un error —o una decisión que nadie más puede revisar— sale caro.

Es el patrón que usamos como referencia en los agentes de IA que operamos para empresas medianas colombianas, con variaciones según cada caso.

Directiva. Reglas de negocio en lenguaje natural —documentos Markdown—, no en código. Qué puede y no puede hacer el agente, cómo debe responder, qué información necesita antes de avanzar. Es la fuente de verdad del comportamiento, y el equipo de negocio puede leerla y proponer cambios sin tocar una línea de código.

Orquestación. La capa que decide en tiempo real: qué herramienta usar, qué información consultar, cuándo escalar a un humano. Puede ser un LLM con tool-calling, un flujo visual de n8n, o un servicio propio que enruta según reglas. Es donde vive la "inteligencia" del agente, pero sus decisiones siempre pasan por herramientas controladas, nunca por acceso directo y sin filtro a las bases de datos o APIs críticas.

Ejecución. Código determinista que hace el trabajo real: llamadas a APIs, escritura en base de datos, generación de documentos. Nada de esto es "creativo" —es la misma lógica que correría sin IA de por medio, con sus propias validaciones, reintentos y manejo de errores—.

El principio detrás de las tres capas es empujar la complejidad hacia donde se puede controlar. Dejamos que el LLM interprete lenguaje natural, que es lo que hace bien. No dejamos que decida directamente el resultado de una transacción, que es donde un error compuesto sale caro.

En la práctica, esta arquitectura no se ve igual en cada agente que operamos. En algunos, la orquestación vive dentro de un flujo visual de n8n con el LLM corriendo en un nodo. En otros, es un loop de function-calling en Python, sin n8n de por medio. En uno en particular, la capa de ejecución se migró deliberadamente de código Python a flujos visuales de n8n —no por rendimiento, sino porque el equipo de negocio necesitaba poder auditar y entender la lógica sin depender de un desarrollador.

Esa es la parte importante: el patrón de tres capas no es una tecnología específica, es una forma de pensar el problema. Lo que importa es que exista una separación clara entre "qué debe pasar" (directiva), "qué se decide hacer ahora" (orquestación) y "qué se ejecuta de verdad, sin ambigüedad" (ejecución) — para que cuando algo falle, sepas exactamente en cuál de las tres capas mirar.