MIS CURSOS
AIAgents, Automatizacion, IntegracionSAP, InteligenciaArtificial, LowCode, n8n, SAP
Un agente de IA que habla con tu SAP: por qué nunca conectas el agente directo al ERP
Lo primero que intenta todo el mundo al montar un agente de IA sobre SAP es lo más intuitivo: arrastrar el nodo de SAP y enchufarlo directamente al agente. Que el cerebro hable con el ERP y se acabó. Y entonces te encuentras con una sorpresa: la interfaz de n8n no te deja. El puerto de herramientas del agente no acepta ese nodo. Te frustras durante diez segundos.
Y esos diez segundos son lo mejor que te puede pasar, porque te empujan al patrón correcto antes de cometer un error de arquitectura que te perseguiría hasta producción.
El AI Agent (agente de IA) no llama a SAP. Llama a tools (herramientas), y cada tool es un sub-workflow (subflujo) independiente que envuelve una operación SAP concreta: leer un Business Partner, listar pedidos de compra abiertos, crear un documento. El agente decide qué herramienta usar y con qué parámetros; n8n ejecuta el subflujo contra SAP y le devuelve el resultado. Esa separación —cerebro que decide, subflujos que ejecutan— es la diferencia entre una demo de feria y algo que puedes poner delante de un ERP productivo.
Este artículo desgrana ese patrón fundacional: la razón técnica por la que la conexión directa no existe, las cinco ventajas que ganas al hacerlo bien, cómo escala a sistemas multi-agente y qué buenas prácticas separan al que improvisa del que entrega.
Contenido
El patrón: un cerebro que decide y subflujos que ejecutan
Conviene distinguir antes de avanzar. En n8n hay dos formas de meter IA en un workflow, y no compiten por el mismo problema:
El agente que habla con SAP es del segundo tipo. Su anatomía en n8n son tres piezas conectadas a un nodo principal:
El nodo principal lleva además un System Message (mensaje de sistema): las instrucciones permanentes del agente, su rol y sus reglas. La regla más importante de todas: prohibir inventar datos. Sin esa frase, un modelo a veces “alucina” un proveedor que no existe en lugar de llamar a la herramienta que se lo daría de verdad.
La pieza que convierte un subflujo en herramienta es el sub-nodo Call n8n Workflow Tool (toolWorkflow). Cada operación SAP atómica vive en su propio subflujo y se expone al agente a través de él:
Por qué no se conecta directo: la razón técnica y las cinco ventajas
Empecemos por lo que ves en pantalla. El puerto Tool del AI Agent solo admite un subconjunto de nodos, los que n8n marca internamente como “tool-enabled”. El nodo de SAP OData no está en esa lista; algunos nodos sí lo están y otros no, y la lista cambia entre versiones de n8n. Esto no es una carencia: es una invitación al patrón estable. El subflujo como herramienta funciona siempre, porque dentro de un subflujo puedes usar cualquier nodo de n8n, incluido el de SAP. Donde la conexión directa es frágil y depende de la versión, el subflujo como tool es universal.
Este mismo tropiezo apareció ya en la segunda sesión del taller, mucho antes de hablar de agentes: un alumno intentó conectar el nodo de SAP directamente al puerto de herramientas del AI Agent y la interfaz no se lo permitió. La solución fue exactamente esta: envolver la operación SAP en un subflujo y que el agente lo llame como tool. Que la pregunta surja sola, sin guion, es la señal de que el patrón es el natural.
Cómo recibe la consulta el subflujo
El mecanismo es sencillo y conviene verlo. Cuando el agente decide llamar a una tool, n8n le pasa al modelo un schema con tres cosas: el nombre técnico de la herramienta, su descripción funcional y los parámetros que acepta con su tipo. El modelo lee eso, decide y rellena los parámetros. Eso es tool calling (llamada a herramientas).
El subflujo recibe esa petición en su campo query y la usa para construir el filtro OData. Y aquí ocurre algo potente: la IA construye el $filter por sí misma y lo empuja a SAP. Ante “dame los pedidos del proveedor 17300001 desde el 19 de mayo”, el agente genera y envía a SAP:
Supplier eq ‘17300001’ and PurchaseOrderDate ge datetime’2026-05-19T00:00:00′
El filtrado ocurre en el servidor SAP (server-side), no en n8n. SAP devuelve solo lo que cumple la condición. Eso recorta drásticamente los datos transferidos, los tokens enviados al modelo y la carga sobre SAP. Es la diferencia entre un agente que escala y uno que se ahoga trayéndose tablas enteras para filtrar tres filas.
Multi-agente: un supervisor que delega en especialistas
Un solo agente con veinte herramientas suena bien hasta que lo pruebas: cuantas más tools tiene, peor las usa, mezcla parámetros y llama a la equivocada. La solución profesional es la jerarquía.
Un AI Agent supervisor no toca SAP. Su único trabajo es identificar el dominio de la pregunta y delegar en el especialista adecuado. Cada especialista es a su vez otro agente completo, con su propio modelo y sus propias herramientas, experto en un único dominio. Es el patrón del jefe de proyecto que recibe la petición del cliente y la deriva al consultor de MM o al de datos maestros según el tema.
Cada subflujo de la fila inferior es una operación SAP independiente, envuelta y expuesta como toolWorkflow. El supervisor ve a cada especialista como “una herramienta más”, pero detrás de esa herramienta hay un agente entero que razona por su cuenta.
El momento más didáctico del taller llegó aquí, y no estaba guionizado. Ante la pregunta “¿cuántos pedidos de compra abiertos hay?”, el supervisor delegó en el especialista de compras, este construyó un filtro OData… y falló a la primera porque erró el nombre de un campo. En lugar de morir con un error, el agente se autocorrigió: probó otro nombre de campo, reintentó, y terminó respondiendo “48 pedidos abiertos”. Ver a la IA razonar y reintentar en directo enseña más sobre agentes que cualquier diapositiva.
Conviene una nota honesta sobre los modelos. Si le preguntas a un LLM qué modelo deberías usar, tira para su casa: recomienda los suyos. Decide tú por coste y caso de uso. El patrón eficiente en multi-agente es mezclar: un modelo barato para el supervisor —que solo enruta— y un modelo preciso en los especialistas que de verdad operan con SAP.
El canal es lo de menos: el agente no sabe por dónde le hablan
La demo más llamativa del taller fue por WhatsApp, a través de Twilio. Funciona, impacta y cierra una promesa concreta: cualquiera con un móvil consulta el almacén SAP en lenguaje natural. Pero conviene entender qué es WhatsApp aquí: solo un canal.
El AI Agent recibe texto y devuelve texto. No sabe si ese texto viene de un chat web, de un correo o de WhatsApp. El mismo agente que tenías en un chat interno funciona por WhatsApp cambiando únicamente dos piezas: el disparador de entrada y la salida.
En un entorno enterprise, WhatsApp es la demo, no la recomendación. El mismo agente lo expones por Microsoft Teams, por Outlook o por un chat corporativo interno, sin tocar el cerebro ni las herramientas. La arquitectura es agnóstica de canal por diseño, y esa es precisamente su virtud: eliges el frontal que tu empresa ya usa.
Memoria: una conversación por usuario
La memoria del agente merece dos frases. En el taller se usa Window Buffer Memory con una ventana de 15 turnos: suficiente para una conversación SAP completa sin disparar el coste por tokens. Para producción multi-usuario se pasa a memoria en PostgreSQL, persistente entre reinicios.
La clave del aislamiento es el sessionId. Funciona como una cookie de sesión HTTP: cada conversación con un sessionId distinto tiene su propia memoria. En el agente por WhatsApp, el sessionId es el número de teléfono del usuario. Si cinco personas escriben a la vez, cada una mantiene su contexto independiente. Multi-usuario sin tocar nada más: lo único que cambia respecto a un chat de un solo usuario es que la clave de sesión pasa de constante a dinámica.
Buenas prácticas
Y una trampa concreta del patrón, por si te ahorra una tarde de depuración: cuando un subflujo se usa como tool, debe estar activo y debe agregar toda su salida en un único item. El toolWorkflow entrega al agente solo el primer item que recibe; si tu subflujo “listar” devuelve cincuenta filas como cincuenta items, el agente verá una sola. La solución es consolidar la salida en un array dentro de un item con un nodo Code.
Conclusión
El agente no es quien habla con SAP. El agente es quien decide. Quienes hablan con SAP son tus subflujos, acotados, versionados y bajo control. Esa frontera —cerebro que razona, subflujos que ejecutan— es lo que convierte una demo de feria en algo que puedes poner delante de un ERP productivo sin perder el sueño.
Así que la próxima vez que arrastres el nodo de SAP y la interfaz no te deje enchufarlo al agente, sonríe: n8n acaba de impedirte cometer el error de arquitectura más común y de empujarte, sin pedirte permiso, hacia el patrón correcto.
Fuentes
- AI Agent — n8n Docs
- Call n8n Sub-workflow Tool (toolWorkflow) — n8n Docs
- Window Buffer Memory — n8n Docs
- avanai SAP Connect — nodo SAP OData para n8n
