1. Introducción: el cerebro del agente

Descripción

Al terminar esta lección vas a poder explicar, con un ejemplo concreto, por qué el modelo y el prompt son las dos únicas piezas del agente que de verdad decides tú —a diferencia de las tools y la memoria, que en buena parte son conexiones mecánicas—, ubicar las siete decisiones puntuales que vas a tomar a lo largo de este módulo, y diagnosticar, dado un síntoma de comportamiento, si el problema vive en el modelo o en el prompt.

Esto importa porque en un proyecto real esos dos síntomas llegan por canales distintos y exigen arreglos distintos. Un cliente que dice "el bot no suena a nuestra marca, y contesta preguntas que no le tocan" te está señalando un problema de prompt: identidad, tono, límites. Un cliente que dice "el bot es lento, se equivoca al usar el CRM, o cuesta más de lo que pensábamos por conversación" te está señalando un problema de modelo: capacidad de razonamiento, confiabilidad llamando tools, costo por token. Si confundes cuál es cuál, puedes pasar una tarde entera reescribiendo un System Message que no tenía nada mal, o subiendo a un modelo más caro que no iba a arreglar un tono que nunca definiste.

Conexión con el módulo: en la lección 5 del Módulo 1 ya viste las cuatro piezas que se conectan al nodo AI Agent —modelo, prompt, tools, memoria— y aprendiste a diagnosticar cuál falla dado un síntoma. Esta lección no repite ese mapa: lo retoma para explicar por qué dos de esas cuatro piezas —modelo y prompt— se ganaron un módulo entero, mientras que tools y memoria tienen el suyo propio más adelante (Módulos 3 y 4). No vas a ver todavía qué familia de modelo usar en julio de 2026 ni cuáles evitar por retiradas —eso es exactamente el trabajo de la lección 2, justo después de esta.

El agente tiene cuatro piezas, pero solo dos las escribes tú

Retoma el empleado nuevo de soporte que imaginaste en la lección 5 del módulo anterior. Ya le diste acceso a sistemas reales (tools) y ya le diste memoria de la conversación. Pero antes de que atienda su primer cliente, todavía te quedan dos decisiones sobre esa misma persona, y son de naturaleza distinta a las dos anteriores.

La primera es qué tan buen criterio tiene para razonar: qué tan bien entiende una petición ambigua, qué tan confiable es siguiendo un procedimiento de varios pasos sin perderse, cuánta información puede sostener en la cabeza a la vez. Eso no lo decides escribiéndole instrucciones —es una característica de la persona misma. En un agente de n8n, esa característica es el modelo que conectas a la entrada ai_languageModel.

La segunda es qué manual de conducta le entregas: cuál es su puesto exacto, qué puede y qué no puede hacer, en qué tono debe hablar, qué formato debe tener su respuesta. Dos personas con el mismo criterio pueden comportarse de forma completamente distinta según el manual que reciban. En un agente de n8n, ese manual es el prompt —el System Message que fija el marco fijo, más el mensaje del usuario que trae la tarea de cada turno, tal como los viste en la lección 5 del Módulo 1.

La diferencia con las otras dos piezas es esta: las tools y la memoria son, sobre todo, conexiones —eliges qué sistemas expone el agente y qué tan larga es su ventana de historial, y una vez conectadas hacen su trabajo sin que tengas que redactar nada de fondo. El modelo y el prompt, en cambio, son decisiones de criterio: cuál modelo entre varias familias, y qué texto exacto escribes en el System Message. Ahí está el trabajo real de este módulo, y por eso modelo y prompt —no tools, no memoria— se llevan un módulo completo antes de que sigas construyendo el agente del proyecto final.

Ejemplo trabajado: el mismo pedido, tres cerebros distintos

Vuelve al agente de soporte de TuTienda que montaste en la lección 5 del Módulo 1, con su tool get_order_status. Esta vez, el mismo cliente escribe algo un poco más difícil:

Input: "Hola, quiero saber el estado de mi pedido #4521, y ya que estamos, ¿qué opinas de la competencia, tienen mejores precios que ustedes?"

Vamos a correr ese mismo mensaje contra tres configuraciones del mismo nodo AI Agent, cambiando solo el modelo o solo el prompt cada vez, para ver qué rompe cada pieza por separado.

# CONFIGURACIÓN A — modelo con razonamiento avanzado, sin System Message
model                = "model-with-advanced-reasoning"
prompt.systemMessage  = ""    # campo vacío: nadie definió rol, tono ni límites
prompt.text           = "{{ $json.chatInput }}"

Qué esperar — Configuración A. El modelo es capaz, así que reconoce sin problema que necesita el estado del pedido, llama a get_order_status con order_id = 4521, y responde con el dato correcto. Pero también responde la segunda parte del mensaje: sin ningún límite que le diga que no debe opinar sobre la competencia, da una comparación de precios inventada ("nuestros competidores suelen tener precios similares, aunque..."), y firma con un tono de asistente genérico que no suena a TuTienda. El razonamiento estuvo bien. El problema es que nadie le dijo cuál era su trabajo ni dónde terminaba.

# CONFIGURACIÓN B — modelo con razonamiento básico, System Message completo
model                = "model-with-basic-reasoning"
prompt.systemMessage  = "Eres el asistente de soporte de TuTienda. Responde en
                         español, en tono cercano y directo. Solo hablas de
                         pedidos y del catálogo propio de TuTienda — nunca
                         opines sobre la competencia ni compares precios con
                         otras tiendas; si te lo piden, di que no puedes
                         opinar sobre eso."
prompt.text           = "{{ $json.chatInput }}"

Qué esperar — Configuración B. Aquí pasa lo contrario. El System Message funciona exactamente como debía: el agente responde en el tono correcto y, ante la pregunta sobre la competencia, contesta algo como "no puedo opinar sobre eso, pero con gusto te ayudo con tu pedido" — el límite se respetó. Pero al resolver la primera parte, el modelo —con menor capacidad de razonamiento— confunde el número de pedido dentro del texto (interpreta "4521" como parte de otro dato) y llama a la tool con un order_id incorrecto, o directamente compone una respuesta sin haber usado el resultado real de la tool. El cliente recibe un estado de pedido que no es el suyo. La identidad y los límites estuvieron perfectos. El razonamiento sobre la tarea, no.

# CONFIGURACIÓN C — modelo con razonamiento avanzado, System Message completo
model                = "model-with-advanced-reasoning"
prompt.systemMessage  = "Eres el asistente de soporte de TuTienda. Responde en
                         español, en tono cercano y directo. Solo hablas de
                         pedidos y del catálogo propio de TuTienda — nunca
                         opines sobre la competencia ni compares precios con
                         otras tiendas; si te lo piden, di que no puedes
                         opinar sobre eso."
prompt.text           = "{{ $json.chatInput }}"

Qué esperar — Configuración C. El agente llama a get_order_status con el order_id correcto, reporta el estado real del pedido, y ante la pregunta sobre la competencia responde dentro del límite que le diste. Es la única de las tres configuraciones donde el cliente recibe algo completamente correcto.

Interpretación: modelo y prompt son ejes independientes, y cada uno rompe el agente de una forma distinta si falla solo. La Configuración A tuvo el criterio correcto pero ningún límite —falló en identidad y alcance. La Configuración B tuvo el manual perfecto pero un criterio insuficiente para la tarea —falló en razonamiento. Ninguna de las dos es "casi tan buena" como la Configuración C; cada una falla en un lugar distinto, y arreglar la pieza equivocada no habría movido el síntoma correcto. Esa es, en una escena, la razón de ser de este módulo completo.

Las siete decisiones de este módulo

El resto de este módulo son siete decisiones concretas sobre esas dos piezas —modelo primero, prompt después—, en el orden en que las vas a necesitar:

Lección	Qué decisión resuelve
2	Qué familia de modelo usar en julio de 2026 y cuáles evitar por retiradas, con un criterio de costo, latencia y calidad
3	Cómo crear y conectar la credencial de ese proveedor (Anthropic, OpenAI o Google) al nodo del modelo
4	Si te conviene correr el agente con un modelo local vía Ollama en vez de pagar por cada llamada a la nube
5	Cómo escribir el System Message: rol, límites explícitos y formato de respuesta
6	Qué parámetros ajustar (temperatura, límite de tokens) y cómo pedir salida estructurada en JSON
7	Cómo comparar variantes de modelo o de prompt con el motor de depuración, sin volver a disparar el flujo completo
8	Ensamblar todo en un agente asesor con personalidad y límites propios, y verificar que se comporta como esperas

Nota el orden: primero decides el criterio (lecciones 2-4, el modelo), después el manual (lecciones 5-6, el prompt), y al final aprendes a comparar variantes de ambos sin fricción (lección 7) antes de ensamblar el mini-proyecto (lección 8). Es la misma secuencia que viste en el ejemplo trabajado: primero qué tan bien razona, después qué le permites y qué no.

Errores comunes

Tratar modelo y prompt como si fueran un solo dial (conceptual). Qué pasa: cambias el modelo por uno más capaz esperando que el agente deje de opinar sobre la competencia o de sonar genérico, y el síntoma sigue exactamente igual porque nunca vivía en el modelo. Por qué pasa: subir de modelo se siente como una mejora universal —es un solo cambio en un dropdown—, así que es tentador probarlo antes de revisar con cuidado qué dice (o no dice) el System Message. Cómo detectarlo: si el síntoma es de identidad, tono o algo que el agente no debería hacer, y persiste después de cambiar de modelo, el problema vivía en el prompt, no en el modelo —igual que en la Configuración A del ejemplo trabajado. Cómo corregirlo: antes de tocar el modelo, clasifica el síntoma: si es de razonamiento o de confiabilidad ejecutando una tarea de varios pasos, el modelo (lecciones 2-4); si es de identidad, límites o formato de respuesta, el prompt (lección 5).

Creer que ya completaste este módulo porque ya conoces las cuatro piezas del Módulo 1 (conceptual). Qué pasa: llegas a este módulo esperando que sea puro repaso, y te tienta saltarte las lecciones 2 a 8 porque "ya sabes que el modelo y el prompt existen". Por qué pasa: la lección 5 del Módulo 1 ya nombró el modelo y el prompt como dos de las cuatro piezas del agente —es fácil confundir "saber que una pieza existe" con "saber elegirla y escribirla bien". Cómo detectarlo: si ahora mismo no puedes nombrar una familia de modelo vigente en julio de 2026 (ni una retirada), ni escribir un System Message con al menos un límite explícito, todavía no cubriste el contenido de este módulo —solo su mapa. Cómo corregirlo: completa las lecciones 2 a 8; esta introducción te da el porqué, ellas te dan el cómo.

Comparar variantes disparando el flujo completo contra un canal real (práctico). Qué pasa: para probar si un System Message nuevo funciona mejor, le escribes al bot de verdad por WhatsApp o por el chat en producción, cambias algo, le escribes otra vez, y pierdes minutos —y a veces el costo real de cada llamada al modelo— en cada comparación, sin quedarte con un registro ordenado de qué probaste. Por qué pasa: es el camino más obvio si todavía no sabes que n8n permite recargar una ejecución que ya ocurrió y volver a correrla sin pasar de nuevo por el canal real. Cómo detectarlo: si para comparar dos versiones de un prompt necesitas escribirle al bot otra vez desde tu teléfono, estás pagando un costo de iteración que no hace falta pagar. Cómo corregirlo: la lección 7 de este módulo te da el motor de depuración —cargar una ejecución pasada en el editor y volver a correrla con los mismos datos de entrada, cambiando solo el prompt o el modelo—; se adelanta aquí para que no inventes tu propio proceso manual mientras tanto.

Ejercicios

Ejercicio 1 — Diagnóstico rápido. Vuelve a la Configuración B del ejemplo trabajado: el tono fue correcto, el agente no opinó sobre la competencia, pero dio mal el estado del pedido. ¿Sospechas primero del modelo o del prompt? Justifica en una frase.

Ver solución

Del modelo. La identidad y los límites —tono cercano, no opinar sobre la competencia— son responsabilidad del prompt, y ambos funcionaron sin falla. El síntoma que quedó (el order_id mal resuelto, el dato equivocado) es un fallo de razonamiento sobre la tarea, que es exactamente el trabajo del modelo, no del System Message.

Por qué funciona: separar qué salió bien de qué salió mal, componente por componente, es el mismo diagnóstico que aplicaste en la lección 5 del Módulo 1 para las cuatro piezas —aquí lo aplicas específicamente entre las dos que se ganaron este módulo.

Ejercicio 2 — Aplica el criterio a un caso propio. Piensa en un agente —tuyo, o uno que uses como cliente en algún producto— que no se comporta como esperarías. Describe el síntoma en una frase, y clasifícalo: ¿es un problema de identidad, tono o límites (prompt), o de razonamiento y confiabilidad resolviendo la tarea (modelo)?

Ver solución

No hay una respuesta única, porque depende del caso que elijas. Pero el criterio de clasificación es siempre el mismo: si el agente hizo o dijo algo que estaba fuera de su rol, su tono o el formato esperado, aunque el dato de fondo fuera correcto, sospecha del prompt. Si el agente se mantuvo dentro de su rol pero llegó a una conclusión equivocada, se perdió a mitad de una tarea de varios pasos, o usó mal una herramienta, sospecha del modelo.

Por qué funciona: convertir el criterio abstracto en un caso propio es lo que lo vuelve una herramienta de diagnóstico real, en vez de quedarse como una distinción teórica que solo aplica al ejemplo de TuTienda.

Ejercicio 3 — El mapa sin mirarlo. Sin ver de nuevo la tabla de la sección anterior, escribe de memoria las siete lecciones que faltan en este módulo, cada una en una frase que diga qué decisión resuelve. Después compara tu lista contra la tabla.

Ver solución

El orden es: (2) qué familia de modelo usar en 2026 y cuáles evitar por retiradas; (3) cómo conectar la credencial del proveedor elegido; (4) si te conviene un modelo local con Ollama en vez de la nube; (5) cómo escribir el System Message con rol y límites; (6) qué parámetros ajustar y cómo pedir salida estructurada; (7) cómo comparar variantes con el motor de depuración; (8) el mini-proyecto que ensambla todo lo anterior.

Por qué funciona: si pudiste reconstruir el orden sin mirar, ya tienes el mapa internalizado, no memorizado de vista —y vas a notar, lección a lección, exactamente dónde encaja cada una dentro de la secuencia modelo → prompt → verificación.

Resumen y siguiente paso

En esta lección viste por qué el modelo y el prompt —de las cuatro piezas del agente— son las dos que de verdad decides tú: el modelo es el criterio de razonamiento, el prompt es el manual de identidad y límites, y son ejes independientes: cada uno falla de una forma distinta si el otro está bien, tal como viste en las tres configuraciones del ejemplo del pedido #4521. También viste el mapa de las siete decisiones que te esperan en este módulo, en el orden en que las vas a tomar.

Antes de avanzar a la lección 2 deberías poder: explicar en una frase por qué modelo y prompt son ejes independientes, citando el ejemplo del pedido #4521; nombrar, sin ver la tabla, al menos cuatro de las siete lecciones que siguen y qué decisión resuelve cada una; y, dado un síntoma de comportamiento, decir si sospechas primero del modelo o del prompt.

Esa última habilidad —diagnosticar cuál de las dos piezas falla— es la que la próxima lección convierte en una decisión real: qué familia de modelo elegir en julio de 2026, y cuáles evitar porque ya fueron retiradas.

Recursos

• AI Agent node — n8n Docs — confirma que el nodo requiere conectar un modelo de chat y al menos una tool; la referencia que ya usaste en el Módulo 1 y que vas a seguir consultando en este.
• What agents do — n8n Docs — cómo n8n describe que el comportamiento del agente se moldea tanto por la consulta como por el prompt que lo configura.
• Debug executions — n8n Docs — la función real detrás del motor de depuración que la lección 7 de este módulo te enseña a usar para comparar variantes sin disparar el flujo completo.
• Prompt engineering overview — Claude Docs — la guía de Anthropic sobre cómo un system prompt fija rol y comportamiento; el principio general que la lección 5 de este módulo aplica al System Message de n8n.
• Building Effective Agents — Anthropic — ya citada en la lección 6 del Módulo 1; aquí aporta la idea de que elegir un modelo es una decisión de costo, latencia y calidad — el eje exacto que abre la lección 2.