1. Introducción: el agente que actúa

Descripción

Al terminar esta lección vas a poder explicar la diferencia entre un agente que solo informa y uno que ejecuta, identificar qué cambia —en términos de riesgo y de resultado real— cuando le conectas al agente una tool que escribe en vez de una que solo lee, y vas a tener el mapa completo de las ocho lecciones que forman este módulo.

Esto importa porque es exactamente donde se separa un experimento interesante de un sistema que una empresa pone en producción. Un agente que responde preguntas bien redactadas sobre el estado de un pedido ahorra algunas consultas al equipo de soporte. Un agente que además puede crear el reemplazo, actualizar el registro en la base de datos y disparar el correo de confirmación —sin que nadie de tu equipo toque un teclado— es el que justifica el proyecto completo. La diferencia entre ambos no está en el modelo ni en el prompt: está en qué tools tiene conectadas.

Conexión con el módulo: en la lección 5 del Módulo 1 ya conectaste una tool a tu agente —get_order_status, un HTTP Request Tool en modo lectura— y viste cómo su description le decía al modelo cuándo usarla. Esta lección retoma esa misma tool, pero para mostrar algo que en ese momento no era el punto: leer un dato y actuar sobre un sistema son dos cosas categóricamente distintas, aunque ambas se conecten al mismo puerto ai_tool del nodo AI Agent. También cierra un hilo que quedó abierto en la introducción del Módulo 3: ahí viste que la memoria guarda lo que se dijo, no el estado real del sistema, y que la frontera entre "lo que se recuerda" y "lo que se verifica" se afina cuando memoria y tools trabajan juntas. Esta lección es donde ese "juntas" empieza. Una nota de límite: este módulo no cubre cómo un agente lee tus propios documentos o busca en una base de conocimiento (embeddings, PDFs, facturas) —eso pertenece a otra guía. Aquí el agente actúa sobre sistemas con tools y memoria, no recupera información de documentos propios.

Ver el problema no es lo mismo que resolverlo

Piensa en dos personas que atienden el mismo mostrador de soporte técnico. Ambas tienen, frente a ellas, la misma pantalla con el historial completo del cliente: sus compras, sus tickets abiertos, el estado exacto de cada pedido. Le preguntas a cualquiera de las dos "¿dónde está mi pedido?" y las dos te van a responder bien, con el mismo dato, en el mismo tono amable. Pero solo una de las dos tiene, además, el botón para procesar un reembolso, generar una etiqueta de devolución o disparar un correo de disculpa con un cupón. La otra, aunque vea exactamente el mismo problema en la misma pantalla, solo puede decir: "lo siento mucho, voy a escalar tu caso a alguien que sí pueda resolverlo" —y ahí termina su turno, aunque entendió el problema a la perfección.

Esa diferencia —ver un problema frente a poder resolverlo— es la misma que separa lo que construiste en los Módulos 1 a 3 de lo que vas a construir en este módulo. Hasta ahora tu agente entendía el mensaje (el modelo), sabía qué tono usar (el prompt), recordaba de qué se había hablado antes (la memoria), y podía consultar un dato externo antes de responder (get_order_status, una tool que solo lee). Pero seguía siendo, en el fondo, un narrador muy bien informado: todo lo que podía hacer era describir el estado del mundo, nunca cambiarlo. Este módulo le da al agente el botón —tools que no solo leen, sino que actúan: enviar un correo real, escribir una fila nueva en una hoja de cálculo, crear un registro en una base de datos, o disparar un sub-workflow completo que ejecuta una secuencia de pasos contra un sistema en producción.

n8n traza esta misma línea, aunque con otro vocabulario, cuando distingue un agente de una chain: una chain sigue una secuencia fija de llamadas que tú definiste de antemano, mientras que un agente usa el modelo de lenguaje para decidir qué acción tomar en cada momento. La palabra que importa ahí es acción, no respuesta. Y la documentación de n8n describe las tools, en ese mismo sentido, como los complementos que le dan al agente acceso a contexto o recursos adicionales —una definición deliberadamente amplia, porque no distingue entre un complemento que te deja mirar y uno que te deja actuar. Esa distinción es tuya que trazar, y es el hilo que atraviesa todo este módulo.

Antes de seguir, una precisión importante: cómo decide exactamente el modelo cuál tool llamar cuando tiene varias conectadas, y con qué datos arma esa llamada, no es el tema de esta lección —es el tema completo de la que sigue. Aquí lo que importa es más simple y más urgente: entender que la capacidad de tu agente no depende de qué tan inteligente es el modelo, sino enteramente de qué tools decidiste conectarle.

Ejemplo trabajado: la misma pregunta, dos agentes con distinta capacidad

Vuelve al agente de soporte de TuTienda que ya conoces, con su System Message de siempre y su memoria conectada. Vamos a correr el mismo mensaje de un cliente contra dos configuraciones que solo difieren en una cosa: qué tool tiene conectada al puerto ai_tool.

# CONFIGURACIÓN A — solo una tool de lectura (la del Módulo 1)
tool.name          = "get_order_status"
tool.method         = GET
tool.description    = "Usa esto para consultar el estado y la fecha de
                       entrega de un pedido dado su número."
tool.url            = "https://api.tutienda.com/orders/{order_id}/status"

Mensaje del cliente: "Mi pedido #4521 llegó dañado. Necesito que me envíen uno nuevo, por favor."

Qué esperar — Configuración A. El agente tiene una sola herramienta disponible, y es de solo lectura. La usa, confirma que el pedido 4521 en efecto fue entregado, y con eso agota lo que puede hacer. No existe ninguna tool que le permita crear un reemplazo ni marcar el pedido como dañado, así que la única respuesta honesta que puede dar es algo como: "Lamento mucho el inconveniente. Ya confirmé que tu pedido fue entregado — voy a escalar tu caso a alguien de nuestro equipo que pueda gestionar el reemplazo." Nada cambió del lado de TuTienda: ningún registro nuevo, ningún correo disparado. El agente entendió el problema perfectamente y aun así no pudo resolverlo — le faltaba el botón, no el criterio.

# CONFIGURACIÓN B — se agrega una segunda tool, esta vez de acción
tool.name          = "create_replacement_order"
tool.method         = POST
tool.description    = "Usa esto cuando el cliente reporte un pedido dañado,
                       incompleto o perdido y ya tengas el número de pedido
                       confirmado. Crea una orden de reemplazo sin costo y
                       dispara el correo de confirmación al cliente. No la
                       uses para pedidos que simplemente se están demorando
                       dentro del plazo normal — para eso alcanza con
                       informar el estado con get_order_status."
tool.url            = "https://api.tutienda.com/orders/{order_id}/replacement"

Mismo mensaje del cliente, agente con ambas tools conectadas.

Qué esperar — Configuración B. El agente ahora tiene dos herramientas y elige entre ellas —el mecanismo exacto de esa elección es lo que vas a ver en la próxima lección; aquí lo que importa es el resultado observable. Llama a create_replacement_order con order_id = 4521, recibe una confirmación, y responde: "Ya generé el reemplazo de tu pedido #4521, sin costo. Vas a recibir un correo de confirmación en los próximos minutos con el nuevo número de seguimiento." Esta vez sí ocurrió algo del lado de TuTienda: una fila nueva en la tabla de reemplazos, y un correo real que el sistema de TuTienda disparó al cliente. Si un minuto después vuelves a consultar el pedido 4521 con get_order_status, el estado cambió —hay un reemplazo en camino— porque el agente no describió el mundo: lo modificó.

Nota lo único que cambió entre ambas configuraciones: el modelo es el mismo, el System Message es el mismo, la memoria es la misma. La única diferencia es qué tool tenías conectada al puerto ai_tool. Esa es la lección completa de este módulo en una frase: la capacidad de un agente —qué problemas puede resolver, no solo explicar— está determinada enteramente por el catálogo de tools que le das, y por lo bien que cada una comunica cuándo usarse.

El mapa de este módulo

El resto de este módulo son siete piezas concretas sobre cómo dar tools a un agente con criterio, no a ciegas:

Lección	Qué resuelve
2	El mecanismo de tool calling: cómo decide el modelo cuál herramienta invocar, con qué datos arma la llamada, y qué hace con el resultado antes de responder
3	El catálogo de tools nativas de n8n para buscar, crear y enviar, sin salir del propio n8n
4	Cómo conectar tools contra sistemas reales de tu empresa: Gmail, Google Sheets, una base de datos y cualquier API vía HTTP
5	Contratos de herramientas y límites de confianza: cómo decidir qué tanta autonomía le das a una tool que actúa, y cómo diseñar barreras antes de que algo salga mal
6	Cómo encapsular lógica reutilizable en un sub-workflow completo y exponerlo al agente como una sola tool
7	MCP en n8n: cómo consumir tools de un servidor MCP externo, y cómo exponer las tools de tu propia instancia de n8n a otros agentes vía el servidor MCP de instancia
8	Mini-proyecto: un agente que ejecuta tres acciones distintas sobre sistemas reales, de punta a punta

Nota el orden: primero el mecanismo genérico de cómo un agente elige y usa una tool (lección 2) —porque necesitas entender eso antes de que el catálogo de la lección 3 tenga sentido—, después el catálogo mismo dividido en dos capas: lo nativo de n8n (lección 3) y lo que requiere credenciales de un sistema externo (lección 4). Con ese catálogo ya en la mano, la lección 5 resuelve la pregunta que este módulo plantea desde ya: si una tool puede actuar, ¿cuánta libertad le das? Las lecciones 6 y 7 son dos formas más avanzadas de empaquetar tools —lógica propia en un sub-workflow, o lógica ajena vía un protocolo estándar— antes de ensamblar todo en el mini-proyecto de la lección 8.

Sobre MCP en particular: la lección 7 lo cubre en su justa proporción para esta guía —el concepto de conectar un agente de n8n a herramientas externas a través de un protocolo estándar, y el nodo que expone tu propia instancia como servidor—, no un curso completo sobre el protocolo. Y sobre lo que este módulo deliberadamente no toca: nada de lo que viene te va a enseñar a que el agente lea tus propios documentos, PDFs o facturas, ni a construir una base de conocimiento con embeddings. Eso es un problema distinto —recuperación de información propia, no acción sobre sistemas— y pertenece a otra guía completa.

Errores comunes

El agente que dice haber actuado sin haber actuado (conceptual). Qué pasa: le pides al agente que cancele una suscripción, y responde con seguridad —"Listo, cancelé tu suscripción, no se te va a cobrar el próximo mes"— pero en el sistema real la suscripción sigue activa. Por qué pasa: un modelo de lenguaje genera, por defecto, el texto más plausible dado el contexto —y una confirmación de éxito es exactamente el tipo de texto plausible que produciría si de verdad hubiera actuado. Si no hay ninguna tool de cancelación conectada, o si la tool existe pero la llamada falló silenciosamente, nada en el modelo le impide igual redactar la respuesta como si la acción hubiera ocurrido. Cómo detectarlo: nunca confíes en el texto de respuesta como prueba de que algo pasó — revisa el log de ejecución de n8n, paso a paso; si no hay un nodo de tool call registrado para esa acción específica, no ocurrió, sin importar qué tan convincente suene la respuesta. Cómo corregirlo: verifica primero que exista una tool real conectada para cada acción que esperas que el agente pueda ejecutar, y en producción, diseña el System Message para que el agente solo confirme un resultado después de recibir la respuesta de la tool —nunca antes, y nunca por inferencia.

Tratar toda tool con el mismo nivel de riesgo (conceptual). Qué pasa: conectas get_order_status (lectura) y create_replacement_order (acción) con la misma despreocupación, sin pensar que una falla distinto que la otra. Si get_order_status falla o responde mal, el peor caso es que el agente diga un dato incorrecto —molesto, pero reversible con un mensaje de corrección. Si create_replacement_order se llama con el order_id equivocado, o se llama dos veces por error, ya generaste un reemplazo real, gastaste dinero real, y quizás confundiste a un cliente que no reportó ningún daño. Por qué pasa: en el canvas de n8n, ambas tools se ven idénticas —el mismo tipo de nodo, la misma línea punteada hacia ai_tool— así que nada en la interfaz te recuerda que una es reversible y la otra no. Cómo detectarlo: para cada tool que conectas, pregúntate qué pasa si el agente la llama con datos incorrectos o en el momento equivocado; si la respuesta involucra dinero, un registro borrado, o un mensaje enviado a la persona equivocada, es una tool de alto riesgo. Cómo corregirlo: esta lección no resuelve el problema a fondo —ese es exactamente el trabajo de la lección 5, contratos de herramientas y límites de confianza—, pero el primer paso es simplemente nombrar el riesgo de cada tool antes de conectarla, no después de un incidente.

Confundir tener credenciales conectadas con tener una tool conectada. Qué pasa: configuraste una credencial de Gmail en n8n para que el agente pueda, en teoría, enviar correos —pero el agente nunca lo hace, ni siquiera cuando la situación claramente lo pide. Por qué pasa: la credencial autentica a n8n contra el servicio externo (le permite operar como tu cuenta de Gmail), pero eso es independiente de si esa capacidad está expuesta al agente. Solo lo que está conectado al puerto ai_tool del nodo AI Agent forma parte del conjunto de acciones que el modelo puede elegir invocar; una credencial configurada en un nodo que no está conectado ahí simplemente no existe para el agente. Cómo detectarlo: si el agente nunca intenta usar una acción que "debería poder hacer", revisa primero si el nodo de esa tool está físicamente conectado —con la línea punteada correspondiente— al puerto ai_tool, y no solo presente en algún lugar del canvas. Cómo corregirlo: verifica visualmente cada conexión antes de asumir que un problema es de criterio del modelo; muchas veces es, más simple, un cable que falta.

Ejercicios

Ejercicio 1 — Clasifica el riesgo. Tienes estas cuatro tools candidatas para un agente de soporte: get_customer_email (busca el correo de un cliente por su ID), list_open_tickets (lista los tickets abiertos de un cliente), delete_customer_account (borra la cuenta de un cliente por completo), charge_credit_card (cobra un monto a la tarjeta guardada del cliente). Clasifica cada una como "lectura" o "acción", y marca cuáles requerirían, ya intuitivamente, más cuidado antes de conectarlas a un agente.

Ver solución

Lectura: get_customer_email y list_open_tickets — ambas consultan datos sin modificar nada; el peor caso de un mal uso es un dato incorrecto en la respuesta. Acción: delete_customer_account y charge_credit_card — ambas cambian el estado real de un sistema, y las dos son, además, difíciles o imposibles de revertir: una cuenta borrada no vuelve sola, y un cobro incorrecto exige un reembolso manual. Estas dos últimas son las que requieren más cuidado, precisamente porque el costo de un error no es "una respuesta rara", sino una consecuencia real fuera de la conversación.

Por qué funciona: el criterio no es qué tan "importante" suena el nombre de la tool, sino si su ejecución cambia el estado de un sistema externo y qué tan reversible es ese cambio — la misma pregunta que vas a aplicar de forma sistemática en la lección 5.

Ejercicio 2 — ¿Actuó o solo habló? Un cliente le pide a tu agente que cancele su suscripción. El agente responde: "Listo, cancelé tu suscripción — no se te va a cobrar el mes que viene." Revisas el log de ejecución de ese workflow en n8n y ves únicamente dos nodos ejecutados: el Chat Trigger y el nodo AI Agent. Ningún nodo de tool aparece en el log. ¿Ocurrió realmente la cancelación? ¿Cómo lo confirmarías con certeza?

Ver solución

No hay evidencia de que la cancelación haya ocurrido. Si el agente hubiera llamado una tool, esa llamada aparecería como un paso más en el log de ejecución —n8n registra cada tool call como parte de la traza del workflow. Que el log solo muestre el Chat Trigger y el Agent sugiere que, o bien no existe ninguna tool de cancelación conectada al puerto ai_tool, o existe pero el agente nunca la invocó, y de cualquier forma el texto de la respuesta es una confirmación fabricada, no un reporte de algo que sucedió. Para confirmarlo con certeza: primero revisa el canvas y verifica si hay una tool de cancelación conectada; después, verifica directamente en el sistema real (el panel de suscripciones, no lo que dijo el chat) si el estado del cliente cambió.

Por qué funciona: el log de ejecución es la única fuente de verdad sobre qué acciones ocurrieron de verdad — el texto de respuesta del modelo es, en el mejor caso, un resumen de eso, y en el peor, una alucinación con la misma forma que un resumen honesto.

Ejercicio 3 — El mapa sin mirarlo. Sin volver a ver la tabla de la sección anterior, escribe de memoria qué problema resuelve cada una de las siete lecciones que faltan en este módulo (2 a 8), en una frase cada una.

Ver solución

(2) Cómo decide el modelo cuál tool invocar, con qué datos, y qué hace con el resultado. (3) El catálogo de tools nativas de n8n para buscar, crear y enviar. (4) Cómo conectar tools contra sistemas reales: Gmail, Sheets, una base de datos, cualquier API vía HTTP. (5) Cómo decidir cuánta autonomía darle a una tool que actúa, y cómo poner barreras. (6) Cómo empaquetar lógica propia en un sub-workflow y exponerlo como una sola tool. (7) Cómo consumir tools externas vía MCP, y cómo exponer las propias con el servidor MCP de instancia. (8) El mini-proyecto: un agente que ejecuta tres acciones reales de punta a punta.

Por qué funciona: si pudiste reconstruir el orden sin mirar, ya tienes internalizada la progresión de este módulo — de "¿cómo elige una tool?" a "¿qué catálogo tengo disponible?" a "¿cuánto confío en cada una?" a "¿cómo empaqueto lógica más compleja?".

Resumen y siguiente paso

En esta lección viste que la diferencia entre un agente que solo informa y uno que resuelve no está en el modelo ni en el prompt, sino enteramente en qué tools tiene conectadas —y, en particular, en si esas tools solo leen o si además actúan sobre un sistema real. El ejemplo del pedido #4521 mostró la misma configuración de modelo, prompt y memoria produciendo dos resultados completamente distintos según una sola variable: la presencia de una tool de acción. También viste el mapa completo de las siete lecciones que siguen, y dos límites explícitos de este módulo: MCP se cubre en su justa proporción en la lección 7, y nada de leer documentos propios (PDFs, facturas, bases de conocimiento) es parte de esta guía.

Antes de avanzar a la lección 2 deberías poder: explicar en una frase la diferencia entre una tool de lectura y una de acción, citando el ejemplo del reemplazo de pedido; distinguir, dado un log de ejecución, si una acción que el agente dijo haber hecho realmente ocurrió; y nombrar, sin ver la tabla, al menos cuatro de las siete lecciones que siguen y qué resuelve cada una.

Lo que no viste todavía —a propósito— es cómo, exactamente, decide el modelo cuál de varias tools conectadas invocar, con qué datos arma esa llamada, y qué hace con el resultado antes de generar su respuesta. Ese mecanismo, tool calling, es el tema completo de la próxima lección.

Recursos

• How tools work — n8n Docs — el catálogo oficial de tipos de tool en n8n, incluyendo HTTP Request Tool, Custom Code Tool y Call n8n Workflow Tool, que vas a profundizar en las lecciones 3, 4 y 6.
• What agents do — n8n Docs — la distinción oficial entre un agente (decide qué acción tomar) y una chain (sigue una secuencia fija), la base conceptual de esta lección.
• AI Agent node — n8n Docs — referencia del nodo que ya usaste en los Módulos 1 a 3; confirma que ai_tool requiere al menos una conexión.
• Call n8n Workflow Tool node — n8n Docs — el nodo que te permite exponer un sub-workflow completo como una sola tool, el tema de la lección 6.
• MCP Client Tool node — n8n Docs — el nodo que conecta tu agente a un servidor MCP externo, el tema de la lección 7.
• Building Effective AI Agents — Anthropic — cómo las tools son el mecanismo que le permite a un modelo dejar de generar solo texto y empezar a interactuar con servicios y APIs reales.