1. Introducción del proyecto: qué vas a entregar y cómo se evalúa

Descripción

Al terminar esta lección vas a poder enunciar con precisión qué construye el proyecto final de esta guía —los ocho requisitos del sistema, uno por uno—, vas a tener la rúbrica con la que te vas a autoevaluar antes de darlo por terminado, y vas a poder señalar, línea por línea, qué frase de una oferta de trabajo real cubre cada parte de tu entregable. También vas a saber qué NO entra en el alcance, que es la mitad de un proyecto bien definido.

Esto importa porque el Módulo 8 no te enseña nada nuevo. Los siete módulos anteriores ya te dieron cada pieza: el bucle agéntico, el cerebro, la memoria, las tools, la delegación, los canales y las defensas. Lo que falta es lo que casi nadie hace y es exactamente lo que separa un curso terminado de un trabajo conseguido: ensamblar todo en un sistema único, verificarlo contra criterios escritos de antemano, y poder defenderlo delante de alguien que va a intentar encontrarle el hueco. Un portafolio con siete mini-proyectos sueltos dice "hice los ejercicios". Un sistema completo con su matriz de permisos, su batería de casos y su hoja de costo dice otra cosa.

Y hay una diferencia práctica con todo lo que hiciste hasta ahora: en los mini-proyectos anteriores construías primero y documentabas después, si es que documentabas. Aquí el orden se invierte. El Módulo 7 terminó diciéndotelo de forma explícita: "ahí vas a diseñarlo desde el principio con la matriz de permisos escrita antes que el primer nodo — que es como se hace cuando ya sabes". Esa es la promesa de este módulo, y esta lección es donde se cobra.

Conexión con el módulo: esta lección define el destino y el criterio de aceptación; no toca un solo nodo. La lección 2 convierte esos requisitos en un diseño en papel —agentes, tools, memoria, canales y defensas— antes de abrir n8n. Las lecciones 3 a 7 lo construyen y lo miden, en el orden en que se construye un sistema de verdad: primero el cerebro, después las manos, después las puertas, después las cerraduras, y al final los instrumentos. La lección 8 lo empaqueta para que se pueda mostrar. Si en algún momento no sabes por qué estás haciendo algo, vuelve aquí: la respuesta está en la tabla de requisitos.

El acta de entrega

Cuando un contratista termina una casa, no basta con que la casa se vea bien. Hay un momento formal —la recepción de obra— donde alguien recorre el inmueble con una lista en la mano. Y esa lista no dice "que quede bonito". Dice cosas verificables: que la instalación eléctrica pasó la prueba de continuidad, que las tuberías aguantaron la prueba de presión durante tantas horas, que existen los planos de lo que quedó construido —no de lo que se planeó—, que hay certificado de los materiales que no se ven.

Fíjate en algo que tiene esa lista y que un "se ve bien" nunca va a tener: existe antes de que la obra empiece. El contratista sabe desde el primer día contra qué lo van a medir. Eso cambia cómo construye. No es lo mismo instalar tuberías sabiendo que alguien las va a someter a presión que instalarlas esperando que nadie las revise.

Y hay una segunda cosa, más sutil. La lista incluye artefactos que no son la casa: los planos de obra terminada, los certificados, el manual de mantenimiento. Nadie vive en un plano. Pero sin el plano, el día que haya una fuga vas a tener que romper tres paredes para encontrar la tubería. El plano no es burocracia; es lo que hace que la casa sea mantenible por alguien que no la construyó.

Tu proyecto funciona igual. La lista de verificación existe desde hoy, antes del primer nodo. Y la mitad de lo que entregas no son workflows: son documentos que hacen que el sistema sea entendible, auditable y defendible por alguien que no lo construyó — incluido tu yo de dentro de tres meses, que no va a recordar por qué issue_refund está detrás de una aprobación y open_dispute no.

Con eso en la cabeza, veamos qué hay en la lista.

Los ocho requisitos del sistema

El sistema se llama sistema de atención al cliente multicanal de TuTienda. Es el mismo caso que vienes trabajando desde el Módulo 5: una tienda en línea que vende productos físicos, con clientes que preguntan por pedidos, reclaman cargos y a veces piden que les devuelvan el dinero.

Estos son los ocho requisitos. Cada uno viene de un módulo, y cada uno tiene una forma de verificarse que no depende de tu opinión.

R1 — Multi-agente con delegación real. Un triage_agent recibe cada mensaje, decide de qué se trata y delega en un especialista mediante el puerto ai_tool. Los especialistas son order_specialist (pedidos, envíos, devoluciones) y billing_specialist (cargos, disputas, reembolsos). El orquestador no consulta sistemas por su cuenta; los especialistas no hablan con el cliente. Verificación: el grafo exportado muestra dos niveles de conexiones ai_tool sin ciclos, y un mensaje con dos temas produce dos delegaciones y una sola respuesta.

R2 — Tools sobre sistemas reales. El sistema consulta el CRM (lookup_order, lookup_charge), consulta una base de conocimiento (search_knowledge_base), evalúa reglas de negocio (check_return_eligibility), y ejecuta acciones: create_ticket, open_dispute, issue_refund y escalate_to_human. Verificación: cada tool tiene su contrato escrito —nombre, Description, parámetros— y al menos una de ellas escribe de verdad en un sistema externo.

R3 — Memoria persistente por cliente, no por sesión. La conversación se guarda con una clave que depende del customer_id cuando se conoce, y de la identidad del canal cuando no. El mismo cliente que escribe por WhatsApp el lunes y por la web el miércoles continúa la misma conversación. Verificación: el caso del cambio de canal pasa, y hay exactamente un nodo de memoria en toda la solución.

R4 — Dos canales, un cerebro. Chat web (widget embebido con Chat Trigger) y WhatsApp (WhatsApp Trigger + WhatsApp Business Cloud), los dos llamando al mismo wf_agent_core a través de un contrato explícito. Ningún workflow de canal contiene lógica de negocio. Verificación: la palabra whatsapp no aparece dentro del núcleo fuera del bloque de verbosidad del system prompt.

R5 — Guardrails contra prompt injection. Un nodo Guardrails entre el trigger y el agente, con su rama de fallo cableada a una respuesta segura y a un registro; el bloque de encuadre en el system prompt de los agentes conversacionales; el contenido no confiable recortado y marcado. Verificación: la batería de ataques corre antes y después, y los casos legítimos siguen funcionando igual.

R6 — Human-in-the-loop para acciones sensibles. issue_refund y la cancelación de pedidos pasan por aprobación humana, con un mensaje que permite decidir sin abrir n8n y una política de umbrales calculada contra la capacidad real del equipo. Verificación: una solicitud denegada no se reintenta, y el vencimiento del plazo no ejecuta la acción.

R7 — Trazabilidad y control de costo. Una bitácora propia (agent_audit_log) que sobrevive a la purga de ejecuciones de n8n, con sus consultas de detección; y una hoja de costo con un número concreto de costo por conversación, medido, no estimado. Verificación: puedes decir en voz alta cuánto cuesta una conversación típica y cuánto el peor caso observado, y de dónde salió ese número.

R8 — Entregable defendible. Una demo grabada de tres minutos, un README de portafolio, y las respuestas preparadas a las cinco preguntas de diseño que te van a hacer. Verificación: alguien que no construyó el sistema puede entender qué hace y por qué está hecho así leyendo solo el README.

Ahora fíjate en algo. Los primeros siete son técnicos y el octavo no. Y el octavo es el que más gente se salta, porque cuando el sistema funciona se siente terminado. No lo está: un sistema que funciona y que no puedes explicar no te sirve para lo que quieres usarlo.

Lo que NO entra en el alcance

Definir el borde es tan importante como definir el centro, y ahorra semanas. Estas cosas quedan fuera a propósito, y saber decir por qué es parte de la defensa del proyecto:

• RAG y búsqueda semántica sobre documentos. La search_knowledge_base de este proyecto busca sobre una tabla de artículos con búsqueda por texto, no sobre embeddings. La versión con vectores es otra guía del ecosistema, y meterla aquí duplicaría el alcance del proyecto sin agregar nada al argumento que estás construyendo.
• Voz. El Módulo 6 te enseñó por qué en voz el cerebro vive en la plataforma de voz y n8n son las tools. Agregar un tercer canal de voz es un ejercicio opcional excelente y no es un requisito: el argumento de "un cerebro, varias puertas" ya queda demostrado con dos canales de texto.
• Operación en producción a fondo. Entornos separados, secretos externos, control de versiones con Git, CI/CD y monitoreo con alertas. Aquí ves depuración y costo a nivel de proyecto; lo demás es la guía de mantenimiento y producción del ecosistema.
• Un CRM real de una empresa real. Puedes montar las tools sobre Postgres, Google Sheets o un Code Tool con datos fijos. Lo que se evalúa es el diseño del sistema de agentes, no de dónde salen los datos.
• Escala. No hay requisitos de concurrencia, de colas ni de workers. El sistema tiene que funcionar bien para una conversación a la vez.

Esa lista tiene un uso concreto que vas a agradecer en la lección 8: cuando alguien en una entrevista te pregunte "¿y por qué no le pusiste RAG?", la respuesta "porque estaba fuera del alcance que definí, y aquí está el alcance que definí" es infinitamente mejor que "no me dio tiempo".

Ejemplo trabajado: la oferta de trabajo, frase por frase

Vamos a hacer algo concreto con la promesa de "esto mapea a una oferta real". Esta es una oferta compuesta, armada con las frases que más se repiten en las ofertas que piden agentes con n8n. No es una oferta literal de una empresa: es el conjunto de exigencias que aparecen una y otra vez. La leemos línea por línea y vemos qué parte de tu entregable responde a cada una.

# OFERTA — AI Automation Engineer (n8n)

  Buscamos a alguien que haya puesto agentes de IA reales en
  producción. No POCs.

  Responsabilidades:
  1. Diseñar y operar flujos de agentes multi-paso que ejecuten
     acciones sobre nuestros sistemas, no solo respondan preguntas.
  2. Integrar el asistente con los canales donde están nuestros
     clientes (WhatsApp, chat web).
  3. Conectar los agentes a nuestro CRM y base de conocimiento.
  4. Implementar salvaguardas: qué puede y qué no puede hacer el
     agente sin supervisión humana.
  5. Monitorear costo y calidad de las conversaciones.
  6. Documentar decisiones de arquitectura para el equipo.

  Nos gustaría ver:
  · Un ejemplo de un sistema que hayas construido y puesto a
    funcionar.
  · Cómo decides cuándo un agente NO es la solución correcta.

Ahora el mapa. Esta tabla es, literalmente, el guion de tu entrevista:

Qué esperar de este ejercicio. Nueve frases, nueve artefactos, y ni una casilla vacía. Ese es el punto entero del Módulo 8: el proyecto no está diseñado para que aprendas algo nuevo, está diseñado para que tengas una respuesta concreta a cada cosa que se pide, con evidencia que puedes abrir en pantalla.

Y mira la última fila, porque es la que más sorprende. "Cuándo un agente NO es la solución correcta" es la pregunta favorita de quien evalúa, porque separa a quien entiende la herramienta de quien está entusiasmado con ella. Tu respuesta va a salir de la palanca 4 del Módulo 5: el especialista de elegibilidad de devolución que reemplazaste por un sub-workflow determinista porque no tomaba ninguna decisión que requiriera interpretar lenguaje. Esa historia, contada con el número de llamadas al modelo que ahorraste, vale más que cualquier discurso sobre agentes.

La rúbrica: cómo te vas a evaluar

Aquí está la lista de recepción de obra. Está organizada en tres niveles, y esa gradación es deliberada: te dice no solo si terminaste, sino qué te falta para pasar de "funciona" a "se defiende".

┌─ RÚBRICA DE ENTREGA — Proyecto TuTienda ──────────────────────────┐
│                                                                   │
│ NIVEL 1 — FUNCIONA                                                │
│   El sistema atiende un caso real de punta a punta.               │
│                                                                   │
│   [ ] Un mensaje por el chat web recibe una respuesta correcta.   │
│   [ ] Un mensaje por WhatsApp recibe una respuesta correcta.      │
│   [ ] El triage delega y el especialista usa al menos una tool.   │
│   [ ] Una acción de escritura (ticket o disputa) queda registrada │
│       en el sistema de destino.                                   │
│   [ ] El sistema recuerda el turno anterior de la conversación.   │
│                                                                   │
│ NIVEL 2 — ES ENTREGABLE                                           │
│   El sistema resiste los casos que no son el camino feliz.        │
│                                                                   │
│   [ ] Un mensaje con dos temas produce dos delegaciones y UNA     │
│       sola respuesta, con un solo saludo.                         │
│   [ ] Falta un dato → el sistema lo pide; NO inventa un order_id. │
│   [ ] Visitante anónimo → no obtiene datos de ningún cliente.     │
│   [ ] Cambio de canal → la conversación continúa sin repetir.     │
│   [ ] Cliente que exige un reembolso → aprobación humana o        │
│       escalamiento; nunca una promesa.                            │
│   [ ] Ningún nodo de Postgres usa la operación Execute Query.     │
│   [ ] Ningún campo de identidad viene de $fromAI().               │
│   [ ] Existe una credencial de solo lectura sobre vistas.         │
│   [ ] El guardrail de entrada está cableado con su rama de fallo. │
│   [ ] Los casos legítimos siguen funcionando después de           │
│       endurecer (sin falsos positivos).                           │
│                                                                   │
│ NIVEL 3 — SE DEFIENDE                                             │
│   Existen los artefactos que hacen el sistema auditable.          │
│                                                                   │
│   [ ] Contrato del núcleo escrito (entrada y salida, con qué      │
│       pasa cuando un campo viene vacío).                          │
│   [ ] Dos fichas de rol de especialista, con sus cinco cláusulas. │
│   [ ] Matriz de permisos L0–L3, INCLUIDA la sección L3.           │
│   [ ] Política de aprobación con umbrales y topes agregados.      │
│   [ ] Batería de casos con tabla de resultados antes/después.     │
│   [ ] Hoja de costo con un número por conversación y su método.   │
│   [ ] Bitácora agent_audit_log con al menos dos consultas de      │
│       detección corriendo en un reporte.                          │
│   [ ] Demo grabada de 3 minutos.                                  │
│   [ ] README de portafolio.                                       │
│   [ ] Respuestas escritas a las cinco preguntas de diseño.        │
│                                                                   │
│ PREGUNTA FINAL — la que decide todo                               │
│   ¿Puedes responder en una frase corta qué es lo peor que este    │
│   sistema puede hacer?                                            │
└───────────────────────────────────────────────────────────────────┘

Tres observaciones sobre esa rúbrica, porque la forma en que está armada dice algo.

El nivel 1 es el más corto y el menos interesante. Cinco casillas. Y es donde termina la enorme mayoría de los proyectos de portafolio que circulan por ahí: el chatbot responde, se ve bien, se graba un video. Nada de eso es mentira y nada de eso distingue a nadie.

El nivel 2 es donde se separa la gente. Diez casillas, y todas son casos que un cliente real va a producir en su primera semana: el que pregunta dos cosas a la vez, el que no da el número de pedido, el que insiste. Un sistema que aprueba el nivel 2 es un sistema que se puede poner delante de clientes; uno que solo aprueba el nivel 1 es un demo.

El nivel 3 no toca ningún nodo. Diez casillas y ninguna es código. Son documentos. Y aquí está la parte contraintuitiva: el nivel 3 es el que más se nota en una entrevista y el que más rápido se hace. La matriz de permisos son cuarenta minutos si diseñaste bien; la hoja de costo es una hora de correr casos y anotar. Comparado con las semanas que cuesta llegar al nivel 2, el nivel 3 es lo más barato del proyecto por unidad de señal que transmite.

Y la pregunta final —¿qué es lo peor que este sistema puede hacer?— atraviesa los tres niveles. Es la pregunta del Módulo 7, lección 4, y es la única que no se puede responder improvisando. Si tu respuesta es "no sé" o "muchas cosas", el proyecto no está terminado por más que funcione. La respuesta que buscas se parece a esto:

"Emitir un reembolso de hasta $800, y solo después de que una persona lo apruebe viendo el monto, el motivo y el mensaje del cliente que lo originó. Todo lo demás que hace es leer datos del cliente que ya está identificado, o escribir cosas que el equipo puede deshacer en un clic."

Esa frase cabe en una tarjeta. Y solo se puede decir si construiste el sistema pensando en ella desde el principio, que es exactamente lo que vas a hacer a partir de la lección 2.

Cómo se organiza el trabajo

Antes de cerrar, la parte práctica: cuánto es esto y en qué orden se hace.

El orden de construcción no es negociable, y tiene una razón. Es el mismo principio que aplicaste en los tres mini-proyectos anteriores: se construye de abajo hacia arriba, y cada pieza se prueba sola antes de conectarla, para que cuando algo falle solo haya un sospechoso nuevo.

Lección 2  · Diseño en papel          ── no se abre n8n
Lección 3  · Cerebro                  ── triage + 2 especialistas
Lección 4  · Manos                    ── las 8 tools, con permisos
Lección 5  · Puertas                  ── memoria por cliente + 2 canales
Lección 6  · Cerraduras               ── guardrails + HITL
Lección 7  · Instrumentos             ── traza, bitácora, costo
Lección 8  · Empaque                  ── demo, defensa, portafolio

Fíjate en dos decisiones de ese orden que quizá te sorprendan.

Las tools van después del cerebro, no antes. Podrías pensar que sin tools el agente no hace nada, y es cierto. Pero un especialista con su ficha de rol, su contrato de salida y sus condiciones de parada se puede probar con datos fijos y sin ninguna tool conectada — y probarlo así te dice si el reparto de responsabilidades está bien hecho, que es la decisión más cara de revertir después.

Las cerraduras van después de las puertas. Es lo que el Módulo 6 te dijo al cerrar: "no se puede endurecer lo que todavía no existe". Endurecer un sistema que todavía no atiende por WhatsApp te obliga a adivinar por dónde va a entrar el ataque.

Sobre el tiempo. El módulo completo son entre ocho y catorce horas de trabajo real, repartidas en tres o cuatro sesiones. La lección 2 —el diseño en papel, que es la que más ganas dan de saltarse— son unos cuarenta y cinco minutos y ahorra varias horas después. La lección 7 y la 8 juntas son unas dos horas, y son las que más cambian lo que el proyecto vale.

Sobre el punto de partida. Si hiciste los mini-proyectos de los módulos 5, 6 y 7, ya tienes entre el 60% y el 70% del sistema construido: el triage con dos especialistas, el núcleo con sus dos adaptadores, y buena parte de las capas de seguridad. En ese caso el Módulo 8 es sobre todo integración, medición y empaque. Si no los hiciste, puedes construir todo desde cero siguiendo las lecciones 3 a 7 — van completas, no dan nada por hecho — pero cuenta con el doble de tiempo y te recomiendo hacer al menos el del Módulo 5 antes, porque es el que define la arquitectura de todo lo demás.

Sobre el costo en dinero. El camino por defecto es $0: n8n self-hosted Community, Postgres en contenedor, y un modelo local con Ollama o el nivel gratuito de un proveedor. Las dos cosas que sí pueden costar están acotadas y las vas a decidir con los ojos abiertos: la API de WhatsApp Business (que en pruebas es gratis con el número de prueba de Meta y en producción cobra por conversación) y el modelo (que cobra por token). La lección 7 te va a dar el método para saber exactamente cuánto, con tus números y no con los míos.

Errores comunes

Empezar a construir sin haber leído la rúbrica (práctico). Qué pasa: alguien abre n8n en la lección 2, monta el sistema en dos sesiones intensas, y al llegar a la lección 7 descubre que la mitad de las casillas del nivel 3 exigen datos que tendría que haber ido anotando mientras construía —qué modelo usó cada agente, cuántas iteraciones consumió cada caso, por qué decidió cada nivel de permiso—. Reconstruir eso al final significa volver a correr todo. Por qué pasa: la rúbrica se lee como una lista de tareas para el final, no como una guía de lo que hay que ir registrando. Cómo detectarlo: si en la lección 5 todavía no abriste un documento aparte para el proyecto, es esto. Cómo corregirlo: crea el documento hoy, con los tres niveles de la rúbrica copiados, y ve marcando y anotando a medida que avanzas — la hoja de costo se llena sola si vas anotando cada vez que corres un caso.

Ampliar el alcance porque "ya que estoy" (práctico). Qué pasa: alguien decide que ya que va a hacer la base de conocimiento, mejor la hace con embeddings; y ya que tiene WhatsApp, mejor agrega Telegram y voz; y ya que está la memoria, mejor le pone resúmenes automáticos. Tres semanas después tiene cinco cosas a medio terminar y ninguna defendible, que es estrictamente peor que tener el alcance original completo. Por qué pasa: cada ampliación individual es interesante y parece pequeña desde afuera, y decir que no a algo que sabes hacer se siente como conformarse. Cómo detectarlo: si estás construyendo algo que no aparece en los ocho requisitos, es esto. Cómo corregirlo: la lista de "lo que no entra" existe para esto — anota la idea en una sección de "versión 2" del documento del proyecto y sigue. Un sistema completo con alcance modesto se defiende; uno ambicioso a medias, no. Y en la entrevista, la sección "versión 2" del README es un activo: muestra que sabes priorizar.

Tratar el nivel 3 como documentación opcional (conceptual). Qué pasa: alguien llega al final con el sistema funcionando y todos los casos pasando, mira las diez casillas del nivel 3 —matriz, política, hoja de costo, README— y decide que eso "lo hace después", porque lo importante ya está. El proyecto queda técnicamente terminado y prácticamente inutilizable como evidencia: nadie puede evaluarlo sin que tú estés al lado explicándolo. Por qué pasa: los documentos no producen ninguna sensación de avance mientras se escriben, y el sistema ya se ve terminado. Cómo detectarlo: pregúntate si alguien podría entender tu proyecto sin ti en la sala; si la respuesta es no, falta el nivel 3. Cómo corregirlo: esos documentos son la mitad del entregable, y el módulo entero está diseñado para que salgan como subproducto de construir —la matriz sale en la lección 2, la política en la 6, la hoja de costo en la 7— siempre que no los pospongas.

Confundir "el sistema funciona" con "el sistema está terminado" (conceptual). Qué pasa: el chat responde bien a las cinco o seis preguntas que a uno se le ocurren, y eso se siente como haber terminado. Pero las preguntas que a uno se le ocurren son, por construcción, las que el sistema sabe responder — nadie prueba espontáneamente el caso del visitante anónimo ni el del cliente que insiste. Por qué pasa: probar el propio sistema con casos difíciles requiere un esfuerzo deliberado de imaginar cómo romperlo, y es cómodo saltárselo cuando todo se ve verde. Cómo detectarlo: si en toda tu batería de pruebas nunca apareció un customer_id vacío, ni un needs_human, ni un pending_info, probaste el mejor tercio. Cómo corregirlo: la batería de casos se escribe antes de probar, en la lección 2, junto con el diseño — así los casos difíciles existen antes de que el cariño por el sistema te haga evitarlos.

Ejercicios

Ejercicio 1 — Audita tu punto de partida. Antes de construir nada, recorre la rúbrica de esta lección y marca honestamente qué casillas ya puedes marcar hoy con lo que tienes de los módulos 5, 6 y 7. Después escribe una lista de las que faltan, agrupadas por lección de este módulo. ¿Cuántas horas estimas?

Ejercicio 2 — Escribe tu respuesta a la pregunta final, hoy. Sin haber construido nada del Módulo 8, escribe tu mejor versión de la respuesta a "¿qué es lo peor que este sistema puede hacer?", con el sistema tal como lo tienes hoy. Guárdala. Al terminar la lección 7, vuelve a escribirla y compara las dos.

Ejercicio 3 — Adapta el proyecto a tu vertical. TuTienda es una tienda en línea porque es el caso más común y el que más se entiende sin explicaciones. Si tu objetivo profesional apunta a otro sector, adapta los ocho requisitos: elige el sector, define los dos especialistas, las tools de cada uno, y —lo más importante— cuál es la acción L2 que necesita aprobación humana y cuál es la L3 que ningún agente puede hacer.

triage_agent
  ├─ appointment_specialist
  │    lookup_appointment (L0) · check_availability (L0)
  │    book_appointment (L1) · cancel_appointment (L2)
  └─ billing_specialist
       lookup_invoice (L0) · search_knowledge_base (L0)
       create_ticket (L1)

L2 (aprobación): cancelar una cita con menos de 24 h de aviso
                 (implica cobro de penalización)
L3 (prohibido):  cualquier consulta o dato clínico del paciente,
                 cualquier orientación médica

triage_agent
  ├─ enrollment_specialist
  │    lookup_student (L0) · check_program_availability (L0)
  │    create_enrollment_request (L1)
  └─ academic_specialist
       lookup_grades (L0) · search_knowledge_base (L0)
       escalate_to_human (L1)

L2 (aprobación): aplicar una beca o un descuento
L3 (prohibido):  modificar una calificación, dar de baja a un
                 estudiante, ver datos de un estudiante distinto
                 al que está autenticado

triage_agent
  ├─ listing_specialist
  │    search_properties (L0) · schedule_visit (L1)
  └─ contract_specialist
       lookup_contract (L0) · search_knowledge_base (L0)
       create_ticket (L1)

L2 (aprobación): apartar una propiedad (bloquea inventario y
                 compromete a la empresa frente al cliente)
L3 (prohibido):  comprometer un precio o una condición de
                 financiamiento por escrito

Resumen y siguiente paso

Ya tienes el destino y la vara de medir. El proyecto es el sistema de atención al cliente multicanal de TuTienda, con ocho requisitos que vienen uno de cada módulo: multi-agente con delegación real, tools sobre sistemas reales, memoria persistente por cliente, dos canales sobre un cerebro, guardrails contra injection, aprobación humana para lo sensible, trazabilidad con costo medido, y un entregable que se puede defender. Y sabes qué queda fuera a propósito, que es lo que evita que el proyecto crezca hasta no terminarse nunca.

La rúbrica tiene tres niveles, y conviene tener presente cuál es cuál: el nivel 1 —que funcione— es corto y es donde termina casi todo el mundo; el nivel 2 —que resista los casos que no son el camino feliz— es donde el sistema se vuelve entregable; y el nivel 3 —los documentos— es lo más barato de hacer y lo que más señal transmite, porque es lo que hace el sistema auditable por alguien que no lo construyó. Y atravesándolo todo, la pregunta que decide: qué es lo peor que este sistema puede hacer, respondida en una frase corta con números.

Antes de avanzar a la lección 2 deberías poder: nombrar los ocho requisitos sin mirar; decir qué frase de la oferta de trabajo responde cada uno; explicar por qué la memoria se agrupa por cliente y no por canal, y por qué RAG está fuera del alcance; y tener creado el documento del proyecto con la rúbrica copiada y tu auditoría de punto de partida.

Lo que sigue es la lección más incómoda del módulo y la que más tiempo ahorra: cuarenta y cinco minutos de diseño en papel, sin abrir n8n. Vas a decidir el elenco de agentes y por qué ese corte y no otro, el inventario de tools con su nivel de permiso escrito antes de conectar la primera, la clave de memoria y qué pasa cuando no hay customer_id, el contrato entre el canal y el núcleo, y el mapa de defensas capa por capa. Al final de esa lección vas a tener el plano completo del sistema en una hoja — y a partir de ahí, construir es seguir un plano en vez de improvisar sobre un lienzo.

Recursos

• AI Agent node — n8n Docs — la referencia del nodo sobre el que se apoya todo el proyecto; confirma ahí los nombres exactos de las opciones en tu versión antes de dar por buena cualquier configuración de este módulo.
• Advanced AI in n8n — n8n Docs — el índice de todas las capacidades de IA de n8n, útil para ubicar rápidamente cualquier nodo que aparezca en las siguientes lecciones.
• Building Effective AI Agents — Anthropic — el argumento de fondo del alcance de este proyecto: empezar por lo más simple que resuelva el caso y agregar complejidad agéntica solo cuando mejora un resultado medible.
• OWASP Top 10 for LLM Applications — el marco con el que contrastar la batería de ataques del requisito R5, si quieres ampliarla más allá de los casos del Módulo 7.
• View past executions — n8n Docs — el panel del que van a salir todos los números de la hoja de costo del requisito R7; conviene tenerlo abierto desde la primera prueba.