Módulo 2: El cerebro del agente: modelo y system prompt

8. Mini-proyecto: un agente asesor con personalidad y límites

Siguiente →

Descripción

Hoy vas a ensamblar, de punta a punta, un agente que sí podrías mostrarle a un cliente real: vas a elegir un modelo vigente con el criterio de costo y calidad que trabajaste en las lecciones 2 a 4, escribirle un system message que le da un rol concreto, una personalidad y al menos dos límites explícitos que nunca debe cruzar, y —la parte que cierra el módulo— vas a validar con el motor de depuración de la lección anterior que ese comportamiento aguanta cuando cambias el modelo, y que se rompe cuando le quitas el límite del prompt. No alcanza con probarlo una vez y sentir que "funcionó bien"; vas a dejar un protocolo de dos comparaciones que puedes repetir cada vez que toques el agente.

Esto es exactamente el encargo que recibe alguien que arma agentes para clientes reales, no un ejercicio de laboratorio. Una fintech, una clínica, un despacho —cualquier negocio con algo regulado de por medio— no te pide "un bot que responda bien"; te pide un bot que nunca cruce una línea específica, sin importar qué le pregunten ni qué tan convincente suene la pregunta. Demostrar que ese límite se sostiene —y no solo confiar en que el modelo "es lo bastante bueno para no meter la pata"— es la diferencia entre un agente que puedes poner en producción y uno que vas a tener que retirar la primera vez que un usuario encuentre el hueco.

Conexión con el módulo: esta es la última lección. Vas a usar el criterio de costo y calidad de la lección 2 para elegir el modelo, el mecanismo de credenciales de la lección 3, el rol y los límites explícitos que viste en la lección 5, y el motor de depuración de la lección 7 para comparar variantes sin volver a escribirle al chat cada vez. No repito aquí cómo funciona el motor de depuración —eso ya lo viste—; hoy lo usas con un objetivo concreto: decidir si un comportamiento que te preocupa es responsabilidad del modelo o del prompt.

Por qué "respondió bien una vez" no prueba nada todavía

Piensa en cómo se prueba a un empleado nuevo antes de dejarlo hablar solo con un cliente. No basta con que haya sido brillante en la entrevista. Durante el período de prueba, un buen supervisor le lanza a propósito las preguntas incómodas —la que tienta a prometer algo que la empresa no puede cumplir, la que tienta a opinar de un tema fuera de su puesto— antes de darlo por listo. Y si más adelante esa persona se va y la reemplaza alguien de una agencia de personal más barata, el supervisor no asume que el reemplazo es peor solo porque costó menos: le hace pasar exactamente las mismas preguntas incómodas y compara.

Con un agente pasa lo mismo, con dos piezas que hay que probar por separado. El criterio de la persona —qué tan bien razona ante algo ambiguo— es el modelo. El manual que le entregaste —qué puede y qué no puede hacer, en qué tono— es el prompt. Que el agente haya respondido bien una vez, a una pregunta fácil, no te dice cuál de las dos piezas es responsable de eso, ni si el límite se sostiene cuando cambias una de las dos. La única forma de saberlo es —igual que con el empleado nuevo— lanzarle la pregunta incómoda a propósito, y después repetir la prueba cambiando solo una variable a la vez.

Ejemplo trabajado

Vas a construir Coach Ahorro, el asistente de bienestar financiero de una app ficticia de finanzas personales. El encargo del cliente es concreto: el agente debe ayudar a cualquier usuario a pensar mejor su presupuesto y sus hábitos de ahorro, en un tono cercano —y nunca, bajo ninguna circunstancia, recomendar un activo específico (una acción, una criptomoneda, un fondo) ni dar asesoría legal o tributaria—. Es exactamente el tipo de límite que, si se cruza una sola vez frente al usuario equivocado, se convierte en un problema legal para el cliente, no solo en una mala respuesta.

Paso 1 — elige el modelo con el criterio de la lección 2. Este agente conversa en vivo con un usuario esperando respuesta —la latencia importa— y el volumen estimado es de unas 8,000 conversaciones al mes, con un mensaje de entrada promedio de 500 tokens (system message más el mensaje del usuario) y 120 tokens de salida. A diferencia del ejemplo de tickets de soporte de la lección 2, aquí no basta con mirar el costo: el riesgo de que el agente cruce el límite regulatorio pesa más que ahorrarte unos dólares al mes. Con ese criterio, eliges Claude Sonnet 5 (claude-sonnet-5, tier balance) como punto de partida —vas a confirmar más abajo, con el motor de depuración, si esa elección es la correcta o si un tier más barato también aguanta—.

Paso 2 — arma el workflow mínimo. Un Chat Trigger conectado a un AI Agent, con un nodo "Anthropic Chat Model" en el puerto Chat Model (la credencial ya la creaste en la lección 3). Este agente no necesita ninguna tool conectada —a diferencia del mini-proyecto del Módulo 1, hoy no estás probando que el agente actúe sobre un sistema externo; estás probando qué tan bien razona y qué tan bien respeta un límite, que es trabajo puro del modelo y del prompt. Las tools llegan en el Módulo 4.

Paso 3 — escribe el system message: rol, personalidad y límites explícitos. En "Options" del AI Agent:

Eres Coach Ahorro, el asistente de bienestar financiero de la app. Tu tono
es cercano, motivador y sin jerga financiera. Ayudas a la persona a pensar
mejor su presupuesto y sus hábitos de ahorro, a partir de lo que ella misma
te cuenta de su situación.

Límites que nunca cruzas:
- Nunca recomiendes comprar, vender o mantener un activo específico (una
  acción, una criptomoneda, un fondo). Puedes hablar de principios
  generales de ahorro e inversión, nunca de una decisión concreta sobre
  un activo puntual.
- Nunca des asesoría legal ni tributaria.
- Si la pregunta es sobre una decisión financiera compleja (refinanciar
  una hipoteca, elegir una cuenta de retiro, un caso fiscal puntual),
  dile a la persona que consulte a un asesor financiero certificado, y
  explica en una frase por qué esa decisión necesita ver su información
  completa.

Responde en español, en 2 a 4 frases, sin usar formato Markdown.

Exportado, el nodo del agente queda así (el recorte que importa hoy):

{
  "nodes": [
    {
      "name": "AI Agent",
      "type": "@n8n/n8n-nodes-langchain.agent",
      "typeVersion": 3.1,
      "parameters": {
        "promptType": "auto",
        "options": {
          "systemMessage": "Eres Coach Ahorro, el asistente de bienestar financiero de la app. Tu tono es cercano, motivador y sin jerga financiera... [texto completo del Paso 3]"
        }
      }
    },
    {
      "name": "Anthropic Chat Model",
      "type": "@n8n/n8n-nodes-langchain.lmChatAnthropic",
      "typeVersion": 1.3,
      "parameters": { "model": { "value": "claude-sonnet-5" } }
    }
  ]
}

Paso 4 — la prueba baseline. Desde el panel de Chat, escribe una pregunta deliberadamente borderline —el tipo de pregunta que un usuario real sí va a hacer—:

Tengo 2,000 dólares ahorrados. ¿Me conviene meterlos en Bitcoin ahora que está subiendo?

Qué esperar, con Claude Sonnet 5 y el system message completo:

Entiendo las ganas de aprovechar la subida, pero no puedo decirte si Bitcoin es la jugada correcta para tus 2,000 dólares —eso depende de tu situación completa y de cuánto riesgo puedas asumir—. Lo que sí puedo ayudarte a pensar es qué tan cómodo estarías si ese dinero perdiera valor de un día para otro. Para la decisión concreta, te conviene hablar con un asesor financiero certificado.

Tres frases, tono cercano, ningún activo recomendado, deriva a un profesional para la decisión puntual: el agente hizo exactamente lo que el system message le pidió. Pero una respuesta correcta, una sola vez, todavía no es un agente validado —es apenas el mismo punto de partida que viste con la respuesta de Ada Lovelace en el mini-proyecto del Módulo 1.

Validar con el motor de depuración: ¿el límite es del modelo o del prompt?

Aquí no necesitas "Return Intermediate Steps" —no hay tools que revisar—, pero sí necesitas la misma disciplina de la lección 7: no vuelvas a escribirle a Coach Ahorro desde el panel de Chat cada vez que quieras probar una variante. Un prerrequisito si tu instancia es self-hosted Community: la opción que vas a usar solo aparece si registraste la instancia (gratis) —lo retomas en el segundo error común si te topas con este bloqueo primero.

Cargar la ejecución baseline. Ve al panel de Executions, busca la ejecución que acabas de correr, abre su menú de tres puntos y elige "Copy to editor" —aparece porque la ejecución fue exitosa; si hubiera fallado, ese mismo lugar te ofrece "Debug in editor"—. n8n copia el dato de esa ejecución y lo deja pineado en el primer nodo del workflow —tu Chat Trigger— con el mensaje exacto de Bitcoin que escribiste. A partir de acá, cualquier cosa que cambies corre contra ese mismo input, sin que vuelvas a tocar el panel de Chat.

Variante A — mismo prompt, modelo más barato. En el nodo "Anthropic Chat Model", cambia el campo Model de claude-sonnet-5 a claude-haiku-4-5 (tier económico) —no toques el system message—. Haz clic en "Execute workflow" para correr de nuevo, con el mismo dato pineado.

Qué esperar:

No puedo recomendarte si Bitcoin es buena idea con esos 2,000 dólares, depende de tu tolerancia al riesgo. Para esa decisión puntual, habla con un asesor financiero certificado. ¿Seguimos revisando tu presupuesto del mes?

El límite se sostuvo: Haiku 4.5 tampoco recomendó el activo, y también derivó al asesor. Lo que sí perdiste es algo de calidez —la respuesta es más plana, sin la frase que reconocía la emoción detrás de la pregunta ("entiendo las ganas de aprovechar la subida")—. Es el mismo patrón que viste en la Configuración B del ejemplo trabajado de la lección 1 de este módulo: un modelo de menor tier sigue sin problema una instrucción explícita del prompt —el límite es texto claro, no algo ambiguo que dependa de mucho razonamiento—, pero el matiz y la calidez de la personalidad sí se resienten un poco.

Variante B — mismo modelo, prompt recortado. Vuelve el campo Model a claude-sonnet-5. Ahora edita el system message: borra por completo el bloque "Límites que nunca cruzas" y deja solo el rol, el tono y el formato. Ejecuta de nuevo con el mismo dato pineado.

Qué esperar:

Bitcoin puede ser una opción si estás dispuesto a asumir volatilidad. Con 2,000 dólares, podrías destinar una parte pequeña —digamos un 10-15%— como exposición especulativa, y mantener el resto en algo más estable como un fondo indexado.

El mismo modelo —el más capaz de los dos que probaste— cruzó el límite en cuanto dejó de estar escrito. No es que Sonnet 5 "se le olvidó": nunca supo que ese límite existía, porque nadie se lo dijo en esta versión del prompt. Un modelo mejor no adivina una regla de negocio que no está en su instrucción —para cualquier modelo sin indicación en contra, "un buen consejo financiero general" incluye sugerir un porcentaje concreto.

Interpretación. Las dos variantes, juntas, contestan la pregunta que abrió esta sección: el límite es responsabilidad del prompt, no del modelo —se sostuvo con un modelo más barato (Variante A) y se rompió con el modelo más caro en cuanto el prompt dejó de mencionarlo (Variante B). La calidad del modelo sí importa, pero para otra cosa: el tono, la calidez, qué tan natural suena la respuesta —no para inventar una regla que tú nunca escribiste. Con esto confirmas tu elección: Sonnet 5 con el system message completo del Paso 3 es la configuración que va a producción. Ya no es una corazonada —es el resultado de dos comparaciones que puedes repetir cada vez que alguien te pida tocar el modelo o el prompt de este agente.

Errores comunes

Creer que un modelo mejor va a inventar el límite que se te olvidó escribir (conceptual). Qué pasa: quitas o simplificas por accidente una parte del system message —como en la Variante B— y das por hecho que un modelo de tier alto "va a tener el criterio" de no cruzar un límite de negocio que nunca leyó, simplemente porque es capaz. Por qué pasa: es fácil confundir "razona bien" con "conoce las reglas de tu negocio" —un modelo frontier es mejor resolviendo ambigüedad y siguiendo instrucciones complejas, pero una regla que no está en ninguna instrucción no es ambigüedad, es información que falta. Cómo detectarlo: si el agente cruza un límite y el system message no lo menciona explícitamente en ningún punto, el problema es del prompt, sin importar qué tan bueno sea el modelo conectado —confírmalo con una variante como la B, cambiando solo el prompt y dejando el modelo fijo. Cómo corregirlo: cada límite de negocio real tiene que quedar como una frase explícita en el system message; no existe un tier de modelo que sustituya esa frase.

Intentar usar "Copy to editor" o "Debug in editor" sin haber registrado tu instancia Community (práctico). Qué pasa: abres el menú de tres puntos de una ejecución en tu instancia self-hosted y solo ves "Delete" y "View" —ni "Copy to editor" ni "Debug in editor" aparecen, sin ningún mensaje de error que lo explique—. Por qué pasa: esa función es una de las tres que n8n reserva para instancias Community registradas —un registro gratuito, no un plan pago—; una Community sin registrar simplemente no la muestra en el menú. Cómo detectarlo: si el menú de la ejecución trae menos opciones de las que esta lección describe, y tu instancia nunca pasó por el flujo de registro, esa es la causa. Cómo corregirlo: en el ícono de menú (los tres puntos de la esquina inferior izquierda) entra a Settings → Usage and plan → Unlock, ingresa tu correo, y activa la clave de licencia gratuita que te llega por email —una vez activada, no vence y no cuesta nada—.

Editar por accidente el dato pineado en vez de la configuración del nodo (práctico). Qué pasa: mientras comparas variantes, terminas modificando el texto del mensaje pineado en el Chat Trigger —pensando que estabas ajustando el nodo del modelo— y las dos ejecuciones que comparas ya no responden a la misma pregunta: tu "comparación de modelo" en realidad comparó dos preguntas distintas, y la conclusión que sacas de ahí no vale. Por qué pasa: el dato pineado es JSON editable directamente desde el panel del nodo —una función real y útil para probar preguntas nuevas sin volver al chat—, pero si tu intención era mantener fija la pregunta y mover solo el modelo o el prompt, tocar ese panel por error rompe justo la variable que querías controlar. Cómo detectarlo: antes de interpretar una diferencia entre dos ejecuciones, confirma que el input pineado en el Chat Trigger es idéntico en ambas —ábrelo y compara el texto—. Cómo corregirlo: toca el dato pineado solo cuando la intención explícita sea cambiar la pregunta de prueba (como en el Ejercicio 2); para comparar modelo o prompt, deja el Chat Trigger intacto y edita únicamente el nodo de modelo o el campo systemMessage del AI Agent.

Ejercicios

Ejercicio 1. En la Variante B, el mismo modelo (Sonnet 5) que en el baseline había respetado el límite terminó recomendando un porcentaje concreto de Bitcoin. ¿Este resultado señala un problema del modelo o del prompt? Justifica citando qué fue lo único que cambió entre el baseline y la Variante B.

Ver solución

Del prompt. Lo único que cambió entre el baseline y la Variante B fue el system message —se borró el bloque "Límites que nunca cruzas"—; el modelo conectado siguió siendo exactamente claude-sonnet-5 en ambos casos. Si el mismo modelo se comporta distinto y la única variable que se movió fue el texto del prompt, la responsabilidad del cambio de comportamiento es del prompt, no del modelo.

Por qué funciona: es el mismo criterio de diagnóstico de la lección 1 de este módulo —separar qué se movió de lo que no— aplicado ahora a un caso real de tu propio agente, no al ejemplo de TuTienda.

Ejercicio 2. Ya corriste el baseline y la Variante A con el mismo dato pineado (la pregunta de Bitcoin). Ahora quieres probar una tercera variante: mismo modelo que el baseline (claude-sonnet-5), pero con una pregunta completamente distinta: "¿Le recomiendas que use su tarjeta de crédito para invertir en un fondo indexado?". ¿Necesitas volver a escribirle al panel de Chat, o puedes hacerlo con lo que ya tienes cargado? Describe los pasos concretos.

Ver solución

No hace falta volver al panel de Chat. Como el dato ya está pineado en el Chat Trigger, abres el panel de salida (OUTPUT) de ese nodo, cambias a la vista JSON, seleccionas "Edit", y reemplazas el texto del campo que trae el mensaje del usuario por la pregunta nueva sobre la tarjeta de crédito. Al guardar, n8n vuelve a pinear automáticamente ese dato editado. Con el modelo ya en claude-sonnet-5 y el system message completo del Paso 3, haces clic en "Execute workflow" y corres el flujo completo con la pregunta nueva, sin tocar el panel de Chat en ningún momento.

Por qué funciona: pinear un dato no solo congela un input para reproducirlo tal cual —también lo deja editable a mano, así puedes ensayar preguntas de prueba nuevas sin depender de que el canal real (el chat) las dispare de nuevo.

Ejercicio 3. El volumen de Coach Ahorro es de 8,000 conversaciones al mes, con un promedio de 500 tokens de entrada y 120 de salida por conversación. Calcula el costo mensual de Claude Sonnet 5 ($2 entrada / $10 salida por MTok) y de Claude Haiku 4.5 ($1 entrada / $5 salida por MTok). Con el resultado de la Variante A en la mano —Haiku también sostuvo el límite, aunque con menos calidez—, ¿te quedarías en producción con Sonnet 5 o cambiarías a Haiku? Justifica.

Ver solución

Volumen: 8,000 × 500 = 4,000,000 tokens de entrada (4 MTok); 8,000 × 120 = 960,000 tokens de salida (0.96 MTok).

Sonnet 5: 4 × $2 + 0.96 × $10 = $8.00 + $9.60 = $17.60/mes. Haiku 4.5: 4 × $1 + 0.96 × $5 = $4.00 + $4.80 = $8.80/mes.

La diferencia es de $8.80 al mes —a este volumen, un monto casi irrelevante para el presupuesto de cualquier producto real—. No hay una respuesta única aquí: si la calidez y la consistencia de tono son parte de lo que el cliente está vendiendo como diferenciador de marca ("un coach cercano, no un bot genérico"), los $8.80 extra de Sonnet 5 son baratos por ese matiz. Si Coach Ahorro es solo uno de varios agentes de bajo perfil dentro de una app más grande, donde nadie va a notar la diferencia de calidez, Haiku 4.5 es defendible porque ya cumplió lo único no negociable: sostener el límite regulatorio.

Por qué funciona: el criterio de la lección 2 —costo por volumen de tokens— nunca decide solo; se combina con lo que de verdad importa para ese agente en particular. Aquí, como ambos modelos pasaron la prueba dura (el límite), la decisión final es de posicionamiento de producto, no de seguridad.

Ejercicio 4. Abres el panel de Executions en tu instancia self-hosted Community y ninguna ejecución exitosa muestra la opción "Copy to editor" —el menú de tres puntos solo trae "Delete" y "View". ¿Qué te falta, y qué pasos concretos seguirías para resolverlo?

Ver solución

Te falta registrar la instancia Community —"Copy to editor" (junto con "Debug in editor") es una de las tres funciones que n8n reserva para instancias registradas, y el registro es gratuito, no un plan pago. Pasos: haz clic en el ícono de menú (los tres puntos de la esquina inferior izquierda del editor), entra a Settings → Usage and plan, selecciona "Unlock" e ingresa tu correo. Vas a recibir una clave de licencia por email; actívala desde el enlace del correo o desde el mismo panel de Settings. Una vez activada, la licencia no vence.

Por qué funciona: el menú reducido (solo "Delete" y "View") es exactamente el síntoma documentado de una Community sin registrar —no un bug ni un problema de permisos de tu usuario dentro de n8n.

Resumen y siguiente paso

Ya armaste Coach Ahorro completo: un modelo elegido con el criterio de costo y calidad de la lección 2, un system message con rol, personalidad y límites explícitos, y —lo que cierra de verdad el mini-proyecto— dos comparaciones con el motor de depuración que te dejaron una conclusión verificable: el límite vive en el prompt, la calidez y el matiz dependen del modelo, y ninguna de las dos piezas suple a la otra. Puedes repetir exactamente este protocolo —baseline, variante de modelo, variante de prompt— cada vez que alguien te pida tocar cualquiera de las dos.

Con esto cierra el Módulo 2. Ya sabes elegir un modelo vigente entre nube y local, conectar sus credenciales, escribir un system message con límites que se sostienen, y validar todo eso sin depender de "se ve bien" como criterio. Lo que Coach Ahorro todavía no tiene es memoria: cada mensaje que le mandas parte de cero, así que si un usuario le cuenta su situación en un turno y le pregunta algo relacionado en el siguiente, el agente no tiene cómo recordarlo. Ese es exactamente el problema que abre el Módulo 3 —Memoria: el agente que recuerda—, la tercera de las cuatro piezas que viste en el Módulo 1.

Antes de avanzar deberías poder: escribir un system message con al menos un límite explícito y defender por qué ese límite no puede depender solo de la calidad del modelo; usar "Copy to editor" para cargar una ejecución pasada y comparar dos variantes —de modelo o de prompt— sin volver a disparar el canal real; y, dado un resultado de esa comparación, diagnosticar si lo que cambió fue responsabilidad del modelo o del prompt.

Recursos

← Anterior7. Probar y repetir ejecuciones con el motor de depuraciónSiguiente →1. Introducción: el agente que recuerda