Módulo 8: Proyecto: sistema de atención al cliente multicanal

8. Entrega: demo, defensa y cómo presentarlo en tu portafolio

Descripción

Al terminar esta lección vas a tener el proyecto empaquetado y defendible: los seis artefactos consolidados en un solo lugar, una demo grabada de tres minutos con su guion cronometrado, un README de portafolio que alguien puede leer sin que tú estés en la sala, y las respuestas escritas a las ocho preguntas que te van a hacer — con la que más gente reprueba, que no es técnica.

Esto importa porque hay una asimetría incómoda en este trabajo: el sistema que construiste vale lo que puedas demostrar de él. Un proyecto excelente que nadie entiende en tres minutos rinde menos que uno modesto bien presentado. Y la diferencia no es carisma ni marketing — es tener los artefactos correctos y haber decidido de antemano qué mostrar y en qué orden.

Hay algo que conviene decir sin adornos antes de empezar. Casi todo el mundo presenta un sistema de IA de la misma forma: abre el chat, escribe una pregunta, el bot responde bien, y explica la arquitectura. Eso demuestra que el sistema funciona, y "funciona" es la parte que quien evalúa da por supuesta — si no funcionara, no lo estarías mostrando. Lo que nadie muestra, y lo que decide la conversación, es qué pasa cuando alguien intenta romperlo, y qué sabes tú sobre tus propios límites. Toda esta lección gira alrededor de eso.

Conexión con el módulo: esta lección no construye nada. Consolida. La lección 1 definió los criterios de evaluación; hoy los marcas. Las lecciones 2 a 7 produjeron los artefactos —el plano, la matriz, la política, la batería, la hoja de costo, la bitácora—; hoy se juntan. Y varias preguntas de la defensa tienen su respuesta ya escrita en los descartes que documentaste en la lección 2, que es exactamente por qué aquella lección insistía tanto en escribirlos.

El plato que sale a la mesa

Hemos usado la cocina tres veces en este módulo, así que cerremos ahí.

Un cocinero puede pasar meses perfeccionando un plato. Ajusta el punto de cocción, prueba tres proveedores de pescado, calibra la salsa. Todo ese trabajo es real y ninguna parte de él sale a la mesa. Lo que sale es un plato, en un minuto de atención de quien lo va a comer.

Y aquí está lo que separa a un cocinero de un cocinero que consigue el puesto. Cuando el crítico pregunta "¿de dónde viene el pescado?", hay dos respuestas posibles. Una es "del proveedor de siempre" — honesta, y no dice nada. La otra es "de una lonja de la costa, llega martes y viernes; probé tres proveedores y este es el único que me da pieza entera, que es lo que necesito para el punto que busco; el jueves el plato no está en la carta". La segunda respuesta no es más larga por adorno: contiene una decisión, una comparación y un límite reconocido.

Esa es exactamente la estructura de una buena respuesta de entrevista sobre tu proyecto. Decisión, comparación con lo que descartaste, y el límite que reconoces. Las tres partes, siempre. Y la tercera es la que más señal transmite, porque es la única que no se puede improvisar.

Lo otro que hace el cocinero: no explica el plato antes de servirlo. Lo sirve, y explica alrededor de lo que la persona está probando. Tu demo funciona igual — el ataque va en el segundo veinte, no la arquitectura.

Vamos a empaquetar.

Fase 1 — El paquete de entrega

Seis artefactos, en un solo lugar. Si están repartidos entre notas de siete lecciones, no existen.

proyecto-tutienda/
├── README.md                    ← el que lee quien te evalúa
├── demo.mp4                     ← 3 minutos (o el enlace)
├── workflows/
│   ├── wf_agent_core.json
│   ├── wf_channel_web.json
│   ├── wf_channel_whatsapp.json
│   ├── wf_tool_return_eligibility.json
│   ├── wf_tool_escalate.json
│   └── wf_tool_issue_refund.json
├── docs/
│   ├── 01-plano.md              ← lección 2
│   ├── 02-fichas-de-rol.md      ← lección 3
│   ├── 03-matriz-de-permisos.md ← lecciones 2 y 4, con la sección L3
│   ├── 04-politica-aprobacion.md← lección 6
│   ├── 05-bateria-de-casos.md   ← los 12, con la tabla antes/después
│   ├── 06-hoja-de-costo.md      ← lección 7
│   └── 07-limitaciones.md       ← lo que NO hace y por qué
├── sql/
│   ├── schema.sql               ← vistas, usuarios, GRANT
│   ├── seed.sql                 ← datos de ejemplo + KB + identidades
│   └── deteccion.sql            ← las tres consultas
└── defensa.md                   ← tus respuestas a las 8 preguntas

Antes de exportar los workflows, revisa dos cosas. Que ninguna credencial vaya dentro del JSON —n8n exporta referencias, no secretos, pero conviene verificarlo abriendo el archivo— y que no queden datos de clientes reales en los ejemplos. Un portafolio que filtra un teléfono real es un portafolio que descalifica.

Y el archivo que más gente omite: 07-limitaciones.md. Es la lista de lo que tu sistema no hace, con la decisión de por qué. Vas a entender por qué importa cuando llegues a la fase 4.

Fase 2 — La demo de tres minutos

Tres minutos es el formato correcto, y no por moda: es lo que alguien mira sin pausar, es lo que cabe en un mensaje, y es lo que te obliga a decidir qué es lo importante.

Qué grabar y con qué

Pantalla y voz. No hace falta que aparezcas tú. Cualquier grabador de pantalla sirve; lo que importa es que se lea el texto en pantalla, así que sube el zoom del navegador antes de grabar — un canvas de n8n a tamaño normal es ilegible en un video comprimido.

Prepara tres ventanas y déjalas listas: el chat de TuTienda, la vista de Logs de n8n al lado, y el canal donde llegan las aprobaciones. Vas a cambiar entre ellas y no hay tiempo de buscar nada.

Ensaya con reloj antes de grabar. El primer intento siempre dura cinco minutos, y no porque sobre contenido: porque uno explica de más. La segunda toma suele salir bien.

El guion

0:00–0:15 — El sistema en una frase
  "Es el sistema de atención al cliente de una tienda en línea:
   un agente de triage que delega en dos especialistas, atendiendo
   por chat web y por WhatsApp, con memoria compartida entre los
   dos canales. Lo que quiero mostrarte no es que funcione, sino
   qué pasa cuando alguien intenta romperlo."

  ▸ En pantalla: el plano de una página. Dos segundos, no más.

0:15–0:50 — El ataque, en vivo
  Pegar el mensaje de ingeniería social —el falso ingeniero de
  calidad— en el chat, con la vista de Logs abierta al lado.
  NO uses el bloque [SYSTEM OVERRIDE]: se ve como un ataque, y
  quien evalúa asume que cualquier filtro lo atraparía.

  "Fíjate que no tiene ninguna frase sospechosa. Es un mensaje
   que cualquier filtro deja pasar, y con razón."

0:50–1:30 — Dónde se detiene
  Señalar en la traza el momento en que el especialista decide
  llamar issue_refund. Cambiar a la ventana de aprobaciones.

  "El modelo se convenció. Pasó. Y aquí está lo que quería
   mostrarte: la solicitud dice motivo 'verificación de sandbox',
   abajo está el mensaje del cliente que la originó, y dice con
   qué medio se verificó su identidad. Yo, desde fuera de la
   conversación, veo que eso no tiene sentido."

  Denegar. Volver al chat. Mostrar que el agente no reintenta y
  no promete nada.

1:30–2:00 — La capa que no depende de nadie
  Abrir la matriz de permisos, sección L3.

  "Esto es lo que hago cuando ni el filtro ni la persona alcanzan.
   El agente no tiene ninguna tool que cancele pedidos, que
   actualice precios ni que mande correo a un destinatario que él
   decida. Y sus consultas corren con un usuario de base de datos
   que solo tiene SELECT sobre tres vistas que no exponen
   direcciones ni datos de tarjeta."

2:00–2:30 — El multicanal, en diez segundos
  Escribir por WhatsApp desde el teléfono. Después seguir la misma
  conversación desde el chat web.

  "Mismo cliente, dos canales, una sola conversación. La clave de
   memoria es la misma porque las dos identidades resuelven al
   mismo cliente. Es un solo cerebro con dos adaptadores de cinco
   nodos."

2:30–2:50 — Los números
  Mostrar la hoja de costo y la tabla antes/después.

  "Doce casos de prueba, corridos antes y después de endurecer.
   Los clientes legítimos siguen atendidos igual — ese era el
   requisito difícil. Y cada conversación cuesta entre tres y ocho
   centavos de dólar en modelo; el sistema completo ronda los cien
   dólares al mes para dos mil conversaciones."

2:50–3:00 — El cierre honesto
  "Lo que no puedo decirte es que sea inmune. Dos de cada cinco
   intentos siguen convenciendo al modelo, y eso hoy no lo resuelve
   nadie. Lo que sí puedo decirte es que convencerlo dejó de
   alcanzar."

Cinco decisiones de ese guion que conviene entender, porque son transferibles a cualquier demo técnica.

El ataque va en el segundo quince. No hay introducción sobre arquitectura. El gancho es el ataque, y todo lo demás se explica alrededor. Si empiezas explicando el diagrama, pierdes a quien te escucha antes del minuto.

Se elige el ataque que no parece un ataque. El bloque [SYSTEM OVERRIDE] es más espectacular y menos convincente: se ve raro, y quien evalúa piensa que cualquier filtro lo atraparía. El falso ingeniero de calidad se ve como un cliente, y ese es el punto entero.

Se muestra la matriz L3. Es el artefacto que menos gente lleva a una entrevista y el que más dice sobre cómo piensas. Documentar lo que el sistema no puede hacer convierte una intuición en una garantía verificable.

Los números van al final y son concretos. No "es barato": tres a ocho centavos, cien dólares al mes, dos mil conversaciones. Un número invita a una pregunta; un adjetivo no.

Se cierra reconociendo el límite. Es contraintuitivo terminar con una debilidad, y es lo que hace creíble todo lo anterior. Quien evalúa sabe que la prompt injection no está resuelta; escuchar a alguien afirmar lo contrario invalida el resto de lo que dijo.

Fase 3 — El README de portafolio

El documento que alguien lee sin ti en la sala. Tiene que responder, en ese orden: qué es, qué problema resuelve, cómo está hecho, qué decisiones tomaste, qué mediste, y qué no hace.

# Sistema de atención al cliente multicanal — TuTienda

Sistema de agentes de IA para atención al cliente de una tienda
en línea, construido en n8n self-hosted. Atiende por chat web y
por WhatsApp con un solo cerebro, consulta el CRM y una base de
conocimiento, crea tickets, abre disputas, y exige aprobación
humana antes de mover dinero.

**Demo (3 min):** [enlace]
**Stack:** n8n 2.0 Community (self-hosted) · Postgres ·
WhatsApp Business API · un modelo económico para el triage y uno
capaz para los especialistas.

## Qué resuelve

Una tienda en línea recibe unas 300 consultas diarias por dos
canales, mayormente sobre estado de pedidos, cargos no
reconocidos y devoluciones. El sistema resuelve la mayoría sin
intervención humana, escala las que no puede, y nunca mueve
dinero sin que una persona lo apruebe.

## Arquitectura

[diagrama del plano de una página]

Tres agentes: un `triage_agent` que clasifica y delega, y dos
especialistas —`order_specialist` y `billing_specialist`— conec-
tados como tools. Los canales son workflows delgados de cinco
nodos que hablan un contrato de ocho campos con un núcleo único
(`wf_agent_core`). La memoria se agrupa por cliente, no por
canal, así que un cliente que empieza en WhatsApp continúa en la
web sin repetir contexto.

## Decisiones de diseño

**Multi-agente en vez de un agente único.** Un prompt que
contiene las reglas de devoluciones y las de facturación produce
contaminación de dominio, y ninguna cantidad de instrucciones lo
estabiliza. Además, con el corte, un mensaje sobre envíos no
tiene ninguna ruta física hacia `issue_refund`.

**Human-in-the-loop solo sobre reembolsos, y solo por encima de
$150.** El umbral se calculó contra la distribución real de
reembolsos y la capacidad del equipo (dos personas, diez
aprobaciones diarias). Deja el 70% de los casos sin fricción y
concentra la atención humana en nueve decisiones al día. Con
topes agregados de $1,500 diarios para cubrir el tramo
automático.

**La política de devoluciones vive en código, no en el prompt.**
`check_return_eligibility` es un sub-workflow con un nodo `Code`
determinista: dos corridas con los mismos datos dan el mismo
resultado, cuesta cero tokens, y la política se puede auditar
leyendo catorce líneas.

**Permisos por capacidad, no por instrucción.** El agente corre
con un usuario de Postgres que solo tiene `SELECT` sobre tres
vistas que no exponen direcciones, teléfonos ni datos de tarjeta,
y un segundo usuario que solo puede `INSERT` en tres tablas. No
hay ninguna operación de consulta libre.

## Qué mediste

| Métrica | Valor |
|---|---|
| Costo por conversación típica | ≈ $0.026 USD |
| Costo p90 (dos temas) | ≈ $0.075 USD |
| Costo mensual, 2,000 conversaciones | ≈ $90–100 USD |
| Latencia típica / p90 | 9 s / 21 s |
| Casos de prueba | 12, corridos antes y después |
| Ataques que convencen al modelo | 2 de 5 (sin cambio tras endurecer) |
| Ataques que consiguen mover dinero | 0 de 5 |
| Falsos positivos sobre clientes legítimos | 0 de 3 |

## Seguridad

Seis capas, de las cuales cuatro no dependen de que el modelo
decida bien: permisos de base de datos, parámetros fijos de
identidad, validación determinista de la salida, y aprobación
humana. Las otras dos —guardrail de entrada y encuadre en el
system prompt— reducen volumen, no garantizan nada.

**Lo peor que el sistema puede hacer:** emitir un reembolso
automático de hasta $150 a un cliente identificado sin reembolsos
previos en 90 días, por un monto que no supera el total de su
pedido, con tope agregado de $1,500 diarios. Entre $150 y $800,
solo con aprobación de una persona que ve el monto, el motivo, la
identidad verificada y el mensaje original. Por encima de $800,
no puede.

## Limitaciones conocidas

- **Concurrencia.** Tres mensajes seguidos del mismo cliente
  disparan tres ejecuciones que leen y escriben la misma memoria.
  Resolverlo requiere una cola; queda fuera del alcance.
- **Teléfono compartido.** Dos personas de la misma casa
  escribiendo desde el mismo número comparten historial de
  conversación. Las tools los protegen de ver los pedidos del
  otro; la memoria no. Mitigado con una instrucción de
  desambiguación, no resuelto.
- **Ventana de 24 horas de WhatsApp.** Si el equipo responde un
  caso escalado al día siguiente, la respuesta requiere una
  plantilla aprobada por Meta, con su costo.
- **Base de conocimiento léxica.** La búsqueda es por texto, no
  semántica. Con 20 artículos funciona; con 2,000 haría falta
  otro enfoque.

## Cómo reproducirlo

1. `sql/schema.sql` y `sql/seed.sql` sobre una base Postgres.
2. Importar los seis workflows de `workflows/`.
3. Configurar credenciales (dos de Postgres, dos de WhatsApp,
   una del proveedor de modelo, una del canal de aprobaciones).
4. Poblar `channel_identities` con tu propio número.
5. Correr la batería de `docs/05-bateria-de-casos.md`.

Tres cosas sobre ese README que valen más de lo que parecen.

La sección de limitaciones está y es específica. No dice "podría mejorarse la escalabilidad": dice qué falla, en qué caso, y por qué se decidió no cubrirlo. Un hueco decidido es una limitación; un hueco no visto es una falla esperando aparecer, y quien evalúa sabe distinguirlos.

Los números están en una tabla, arriba, sin buscarlos. Alguien que revisa veinte portafolios en una tarde no va a leer tu prosa. Va a mirar la tabla, y si tiene números medidos, se detiene.

La frase "lo peor que el sistema puede hacer" está escrita, literal. Es la respuesta a la pregunta que decide todo, y tenerla en el README significa que quien te entreviste ya la leyó antes de preguntártela. Eso cambia el tono de la conversación entera.

Fase 4 — La defensa

Ocho preguntas. Las respuestas van escritas, en tus palabras, en defensa.md. No para leerlas —eso se nota— sino porque escribir una respuesta la ordena, y una respuesta ordenada se dice de memoria.

El molde de todas: decisión, comparación con lo descartado, límite reconocido.

1. ¿Por qué multi-agente y no un solo agente con todas las tools?

"Por dos razones, y una es más fuerte que la otra. La primera es de precisión: cuando probé un agente único con las ocho tools, el prompt tenía que contener las reglas de devoluciones y las de facturación a la vez, y aparecía contaminación de dominio — el agente aplicaba un plazo de devolución a un cargo, o intentaba abrir una disputa sobre un pedido en tránsito. Se puede reducir con instrucciones, pero no se estabiliza.

La segunda es la que de verdad decidió: con el corte, un mensaje sobre envíos no tiene ninguna ruta física hacia issue_refund. No es que esté prohibido por el prompt; es que la tool no está conectada a ese agente. Esa diferencia —una restricción estructural en vez de una de texto— es la que sigue funcionando cuando alguien convence al modelo.

Y el costo de la decisión: son unas cuatro llamadas al modelo más por conversación con delegación, y unos ocho segundos más de latencia. Lo compenso poniendo el orquestador en un modelo económico, porque su trabajo es elegir entre dos opciones bien descritas y componer un texto, no razonar sobre dinero. Con eso, el multi-agente cuesta parecido al monolito y falla menos.

Dicho eso, si el caso fuera un solo dominio —solo pedidos, sin facturación— no lo habría hecho multi-agente. El corte se justifica con evidencia de contaminación, no por defecto."

2. ¿Por qué human-in-the-loop en reembolsos y no en todo?

"Porque una barrera que se cruza sin leer no es una barrera. El equipo de soporte de este caso son dos personas con capacidad para unas diez aprobaciones al día. Si mando a aprobación los reembolsos, las disputas, los tickets y los escalamientos, son treinta y cinco solicitudes diarias, y a partir de la quinta nadie las lee. El sistema se vería igual de seguro en el diagrama y no protegería nada — ese es el modo de falla propio de esta capa y se llama fatiga de aprobación.

Así que puse el umbral donde la distribución lo pedía. De los cuarenta reembolsos diarios, veintiocho son de menos de $150: esos van automáticos, con registro obligatorio y un tope agregado de $1,500 al día en todo el sistema por si alguien descubre el umbral e intenta diez de $149. Nueve están entre $150 y $800: esos son los que van a una persona, y nueve caben en el presupuesto de diez. Y los tres de más de $800 no son una acción del agente: se escalan, y el equipo los atiende en su flujo normal de trabajo en vez de como una interrupción con botón.

Todo lo demás —tickets, disputas— es reversible en un clic, así que ahí la defensa correcta no es una persona: son permisos recortados y registro."

3. ¿Cuánto cuesta una conversación?

"Entre 2.6 y 7.5 centavos de dólar en modelo, según si el cliente trae uno o dos temas. Lo medí sobre veinte ejecuciones del panel de n8n: para una conversación simple son siete llamadas al modelo, unos 18,600 tokens de entrada y 720 de salida, repartidos entre un modelo económico para el guardrail y el triage y uno capaz para el especialista. Con dos mil conversaciones al mes y una mezcla de setenta-treinta, son unos ochenta dólares al mes en modelo.

El canal es la otra mitad y se comporta distinto. El chat web no cuesta nada. En WhatsApp, este sistema solo tiene conversaciones de servicio —las inicia el cliente y se responden dentro de la ventana de veinticuatro horas—, que están en una categoría de precio distinta de las plantillas que inicia la empresa, y ese esquema Meta lo ha cambiado varias veces, así que lo verifico contra su tabla vigente antes de dar un número. Lo caro de WhatsApp son las campañas, que este sistema no hace.

Total defendible: alrededor de cien dólares al mes, incluyendo el servidor. Y el marco con el que lo comparo: dos mil conversaciones a cinco minutos cada una serían ciento sesenta y seis horas de una persona.

Y sé qué palanca mueve ese número. El sesenta por ciento del ahorro viene de una sola decisión: el orquestador corre en el modelo económico. Es el agente que más tokens de entrada consume, porque arrastra la memoria de la conversación completa; si estuviera en el modelo capaz, ese componente costaría casi diez veces más."

4. ¿Qué es lo peor que tu sistema puede hacer?

"Emitir un reembolso automático de hasta $150 a un cliente ya identificado, que no haya tenido reembolsos en los últimos noventa días, por un monto que no supere el total de su pedido, con un tope agregado de $1,500 diarios en todo el sistema. Entre $150 y $800 puede hacerlo solo si una persona lo aprueba viendo el monto, el motivo que dio el agente, con qué medio se verificó la identidad del cliente y el mensaje original que lo originó. Por encima de $800 no tiene la capacidad: escala.

Todo lo demás que hace es leer datos del cliente que ya está identificado, sobre vistas que no exponen dirección, teléfono, correo ni datos de tarjeta, o escribir tickets, disputas y escalamientos que el equipo revierte en un clic. No puede cancelar pedidos, no puede cambiar direcciones, no puede modificar precios, no puede mandar correo a un destinatario que él decida, y su credencial de base de datos no tiene UPDATE ni DELETE sobre ninguna tabla."

5. ¿Cómo evitas la prompt injection?

"No la evito, y creo que quien diga que la evita no la probó. Lo que hago es que convencer al modelo deje de alcanzar.

Tengo la medición: con quince intentos de manipulación de tres tipos distintos, cinco lograron que el agente decidiera llamar issue_refund. Después de endurecer el sistema, esos cinco siguen convenciendo al modelo en la misma proporción — no bajó. Lo que cambió es que ninguno consigue mover dinero, porque hay cuatro capas debajo que no dependen de que el modelo decida bien: la credencial no puede escribir donde no debe, el customer_id de cada consulta no viene del modelo sino del contrato del canal, la salida se valida campo por campo contra lo que las tools devolvieron, y el reembolso pasa por una persona.

El guardrail de entrada existe y lo tengo calibrado a propósito por encima de lo que atraparía todos los ataques, porque lo calibré contra los casos legítimos: un cliente enojado en mayúsculas exigiendo su dinero tiene que pasar, y no tiene ninguna capa debajo que lo rescate si lo bloqueo. Los ataques sí las tienen.

El hueco que sí me queda abierto y lo tengo documentado: estas capas protegen las acciones, no las afirmaciones. Un mensaje que no pide ejecutar nada y solo pide que el agente confirme por escrito algo falso no dispara ninguna barrera. Eso lo cubre parcialmente la validación de salida, con un campo refund_status que solo puede decir 'aprobado' si la tool corrió con éxito en esa ejecución."

6. ¿Cuándo un agente NO es la solución correcta?

"Cuando la decisión es determinista. Y tengo un caso concreto de este mismo proyecto: la elegibilidad de una devolución.

Al principio era criterio del agente — miraba la fecha de entrega, la categoría, el plazo, y decidía. Funcionaba casi siempre. El problema es que 'casi siempre' no es aceptable cuando el resultado le niega una devolución a alguien que sí tenía derecho, y además el error es invisible: la respuesta suena perfectamente razonable. Lo saqué a un sub-workflow con un nodo Code de catorce líneas. Ahora dos corridas con los mismos datos dan el mismo resultado, cuesta cero tokens en vez de entre dos y cuatro llamadas al modelo cada vez, y la política de devoluciones de la empresa se puede auditar leyendo código en vez de un prompt.

La regla general que uso: si el resultado tiene que ser el mismo con los mismos datos, no puede vivir en el modelo. El agente sirve para lo que sí requiere interpretar lenguaje o elegir entre caminos —entender qué pide el cliente, decidir a quién delegar, redactar la respuesta—. Un sistema multi-agente maduro suele terminar con menos agentes de los que tenía al principio y más sub-workflows.

Y hay un segundo caso: cuando hay una restricción dura de latencia. En voz, cada delegación agrega una ronda completa, y si el presupuesto son dos segundos, la delegación no cabe."

7. ¿Cómo sabes que funciona?

"Con doce casos de prueba escritos antes de construir el sistema, corridos antes y después de endurecerlo, con la tabla de resultados. Y la parte que importa: tres de esos doce son casos legítimos difíciles —un cliente furioso en mayúsculas, uno que cita una instrucción sospechosa que le dijeron, y un reembolso que sí procede— y el criterio de éxito es que no cambien entre el antes y el después. Si después de seis capas de seguridad mis clientes reales dejaron de ser atendidos, no endurecí el sistema: lo rompí.

Los escribí antes a propósito, en la fase de diseño, porque cuando el sistema ya funciona uno prueba lo que sabe que funciona. Nadie inventa espontáneamente el caso del visitante anónimo mientras admira su propio chatbot respondiendo bien.

Y hay dos cosas que corren solas. Una validación determinista que compara lo que el agente afirma contra lo que las tools devolvieron, campo por campo — medí que en dos de cada diez corridas de una consulta simple el agente estimaba una fecha de entrega que ninguna tool había dado, y el validador la atrapa. Y tres consultas diarias sobre una bitácora propia, porque las ejecuciones de n8n se purgan a los catorce días y los incidentes aparecen después. Una de esas consultas me dice si mis capas están vivas: una defensa que nunca reporta nada es indistinguible de una defensa apagada."

8. ¿Qué harías distinto para 50,000 conversaciones al mes?

"Tres cosas, en este orden.

Primero, la concurrencia, que hoy es mi limitación conocida más seria. Tres mensajes seguidos del mismo cliente disparan tres ejecuciones que leen y escriben la misma memoria. A trescientas conversaciones diarias pasa poco; a cincuenta mil al mes pasa todo el tiempo. Se resuelve con una cola y agrupación de mensajes por sesión, y es trabajo de infraestructura, no de agentes.

Segundo, el costo dejaría de ser un detalle. A este volumen serían unos dos mil dólares al mes, y ahí empieza a valer la pena lo que hoy no vale: cachear las respuestas de la base de conocimiento, que son las mismas veinte respuestas repetidas miles de veces; y medir si el especialista de pedidos puede correr en el modelo económico, porque sus decisiones son más simples que las de facturación. Las dos son mediciones, no intuiciones.

Y tercero, la aprobación humana no escala tal como está. Nueve solicitudes diarias con dos personas funciona; doscientas veinticinco no. A ese volumen habría que subir el umbral automático apoyándolo en datos —qué porcentaje de los reembolsos aprobados manualmente se aprueban siempre— y probablemente pasar a un modelo de muestreo: aprobar automáticamente por debajo de un umbral más alto y revisar una muestra a posteriori en vez de todos a priori. Es una decisión de riesgo, no técnica, y la tomaría con el dueño del negocio y con los números delante."

La pregunta que más gente reprueba

No es ninguna de las ocho. Es esta:

"¿Qué es lo que más te costó de este proyecto?"

Parece conversación y no lo es: es la pregunta que distingue a quien construyó algo de quien siguió un tutorial. Las respuestas que no funcionan son "nada en particular", "configurar WhatsApp" y "aprender n8n". Las tres son ciertas y ninguna dice nada sobre tu criterio.

Una que sí funciona tiene esta forma: un problema que no era técnico, la decisión que tomaste, y qué aprendiste que aplicarías otra vez. Por ejemplo:

"Calibrar el guardrail. Mi instinto era bajarle el umbral hasta que bloqueara todos los ataques, y cuando lo hice descubrí que también bloqueaba a un cliente furioso escribiendo en mayúsculas que quería su dinero. Estuve un rato convencido de que era un problema de configuración, hasta que me di cuenta de que era un problema de orden: estaba calibrando contra las amenazas cuando tenía que calibrar contra los clientes. Subí el umbral aceptando que dos de cada cinco ataques pasaran el filtro, porque esos dos tienen cuatro capas debajo y el cliente enojado no tiene ninguna. Eso me cambió cómo pienso las defensas en capas: la de arriba no tiene que atrapar todo, tiene que no estorbar."

Escribe la tuya. Tiene que ser verdad, y tiene que haberte pasado.

La honestidad como estrategia

Hay un patrón que atraviesa toda esta lección y conviene decirlo directo, porque es contraintuitivo y es lo que más funciona.

Reconocer los límites de tu sistema te hace más creíble, no menos. Y no por una cuestión de modestia: por una razón práctica. Quien te evalúa sabe que la prompt injection no está resuelta, que un sistema de agentes tiene modos de falla, y que ningún proyecto de portafolio escala a millones de conversaciones. Si tu presentación no contiene ninguna limitación, o no probaste el sistema, o estás ocultando algo — y las dos posibilidades son peores que la limitación.

Tres formas concretas de aplicarlo, y las tres las tienes ya construidas:

La tabla de antes y después que muestra que los ataques siguen funcionando. Es un dato que juega en tu contra en apariencia y es el más fuerte que tienes, porque demuestra que mediste en vez de asumir.

La sección de limitaciones conocidas del README. Específica, con la decisión de por qué cada una queda fuera.

El cierre de la demo. "No puedo decirte que sea inmune; puedo decirte que convencerlo dejó de alcanzar."

Y la contraparte, porque la honestidad no es autoflagelación: lo que hiciste bien se afirma con seguridad. Los permisos de base de datos funcionan siempre, no "casi siempre". El filtro de customer_id no depende del modelo, punto. La política de devoluciones es determinista, sin matices. La humildad va en lo que es genuinamente incierto; los hechos técnicos se afirman.

Dónde publicarlo

Tres formatos, y conviene tener los tres porque sirven en momentos distintos:

El repositorio. El paquete completo de la fase 1, con el README como cara. Es lo que enlazas en tu currículum y lo que alguien revisa si le interesaste.

El video de tres minutos, suelto. Súbelo donde puedas enlazarlo sin que nadie tenga que descargar nada. Es lo que mandas en un mensaje, y es lo que más gente va a ver de tu proyecto.

Una publicación corta contando una decisión. No el proyecto entero: una decisión, con su medición. "Por qué calibré el filtro de seguridad de mi agente para que dejara pasar ataques" es un texto de quinientas palabras que se lee, se comparte, y demuestra criterio mejor que un recorrido por la arquitectura. El proyecto entero aburre; una decisión con un número no.

Errores comunes

Grabar la demo explicando la arquitectura primero (práctico). Qué pasa: el video empieza con el diagrama, sigue con el recorrido por los nodos, y al minuto y medio —cuando ya perdiste a quien mira— llega lo interesante. Por qué pasa: es el orden en que construiste el sistema y el orden en que lo tienes en la cabeza. Cómo detectarlo: si en los primeros treinta segundos de tu video no pasa nada que sorprenda, es esto. Cómo corregirlo: el ataque en el segundo quince, y la arquitectura explicada alrededor de lo que se está viendo. El orden de construcción y el orden de presentación casi nunca coinciden.

Presentar el sistema afirmando que es inmune a la prompt injection (conceptual). Qué pasa: alguien ve su tabla con los cinco ataques detenidos y dice "el sistema está protegido contra prompt injection". Quien evalúa —que sabe que eso no existe— escucha una afirmación imposible, y a partir de ahí duda de todo lo demás, incluidas las partes que sí eran ciertas. Por qué pasa: la tabla es genuinamente buena y es tentador resumirla en una frase fuerte. Cómo detectarlo: si tu frase de presentación no contiene ninguna limitación, es demasiado fuerte. Cómo corregirlo: "no puedo prometerte que nadie convenza al modelo; puedo mostrarte que convencerlo no alcanza", y después la tabla, que muestra exactamente eso.

Llevar el proyecto sin ninguna medición (práctico). Qué pasa: la demo se ve bien, la arquitectura está bien explicada, y cuando preguntan cuánto cuesta o cuántos casos probó, la respuesta es una estimación. La conversación se enfría de inmediato, porque acaba de quedar claro que el sistema nunca salió de la fase de que funcione. Por qué pasa: medir no produce ninguna funcionalidad visible y siempre parece que se puede hacer después. Cómo detectarlo: si tu README no tiene una tabla de números, es esto. Cómo corregirlo: la hoja de costo de la lección 7 y la tabla de casos de la lección 2 son dos horas de trabajo, y son lo que más señal transmiten por unidad de esfuerzo de todo el proyecto.

Improvisar la defensa el día de la entrevista (práctico). Qué pasa: alguien conoce su sistema perfectamente y asume que puede explicar cualquier decisión sobre la marcha. Y puede — pero la respuesta improvisada sale desordenada, se olvida de mencionar la alternativa que descartó, y no llega al límite reconocido, que es la parte que más transmite. Por qué pasa: escribir respuestas a preguntas que nadie ha hecho todavía se siente artificial. Cómo detectarlo: intenta decir en voz alta y de corrido tu respuesta a "por qué multi-agente"; si dura más de noventa segundos o se te va por una rama, no está escrita. Cómo corregirlo: las ocho respuestas escritas en defensa.md, cada una con el molde de decisión, comparación y límite. No para leerlas: para haberlas pensado una vez con calma.

Dejar datos reales en el paquete (práctico). Qué pasa: el seed.sql tiene el teléfono de verdad de quien probó el sistema, o una captura de la demo muestra un correo real en la tabla de identidades. Un portafolio que filtra datos personales no es un descuido menor en este campo concreto: es exactamente lo contrario de lo que el proyecto dice demostrar. Por qué pasa: los datos de prueba salen de la vida real porque es lo más rápido. Cómo detectarlo: busca tu propio número y tu propio correo en todos los archivos antes de publicar. Cómo corregirlo: números y correos de ejemplo en todo el paquete, y revisar el video fotograma por fotograma en las partes donde se ve una tabla.

Ejercicios

Ejercicio 1 — Graba la demo y córtala a tres minutos. Sigue el guion, cronometra, y si te pasas, corta. Después mira la grabación con el sonido apagado y pregúntate si se entiende qué está pasando en cada momento.

Ver solución

Lo que casi siempre hay que cortar, en orden de frecuencia:

La explicación de qué es n8n. Quien te evalúa lo sabe o no le importa. Son veinte segundos que no compran nada.

El recorrido por el canvas. Es la parte que más orgullo da y la que menos comunica: un canvas con veinte nodos en un video es una mancha. El plano de una página dice lo mismo en dos segundos y se lee.

La segunda mitad de cada frase. Al ensayar, casi todas las frases del guion tienen una coletilla explicativa que se puede quitar sin perder nada. "El modelo se convenció, pasó, y eso es normal porque los modelos actuales son susceptibles a este tipo de..." → "El modelo se convenció. Pasó."

Lo que la prueba del sonido apagado revela, y es el motivo de hacerla: los momentos en que hablas de algo que no está en pantalla. Si a los cincuenta segundos estás explicando la aprobación humana y la pantalla todavía muestra el chat, quien mira está buscando y no escuchando. Cada afirmación necesita su evidencia visible al mismo tiempo.

Y un detalle que mejora mucho el resultado y cuesta poco: pausa medio segundo antes de cada cambio de pantalla. Da tiempo a que la persona termine de leer lo anterior. Los videos técnicos suelen ir demasiado rápido precisamente porque quien graba ya sabe lo que viene.

Por qué funciona: cortar obliga a decidir qué es lo importante, y lo que queda después de cortar es lo que de verdad defiende el proyecto.

Ejercicio 2 — Haz que alguien evalúe tu README sin ti. Dale el README a alguien que no conozca el proyecto —idealmente alguien técnico que no sepa de agentes— y pídele que responda tres cosas: qué hace el sistema, qué es lo peor que puede hacer, y qué no hace. Anota qué tuvo que preguntarte.

Ver solución

Todo lo que te haya tenido que preguntar es una sección que falta o que está mal escrita. Los huecos que más aparecen:

"¿Qué es un agente de triage?" El README usa vocabulario del dominio sin definirlo. La corrección no es agregar un glosario: es que la primera frase de la sección de arquitectura describa el comportamiento antes que el nombre — "un agente que lee el mensaje, decide de qué se trata y se lo pasa al especialista correspondiente".

"¿Esto está funcionando ahora mismo o es una maqueta?" Es la pregunta que más se hace y la que más cuesta responder. Merece una frase explícita: qué corre de verdad —el chat web, WhatsApp con el número de prueba de Meta, Postgres con datos de ejemplo— y qué está simulado —el gateway de pagos—. Ocultarlo se nota; declararlo no resta nada.

"¿Por qué WhatsApp es gratis?" El README dice que las conversaciones de servicio están en otra categoría de precio, y quien lee sin contexto entiende "WhatsApp es gratis", que es falso. Vale la pena una frase más de precisión.

Y la señal buena: si tu lector pudo responder las tres preguntas sin ayuda, el README funciona. Si además te preguntó algo sobre una decisión de diseño —"¿por qué no cachean las respuestas de la base de conocimiento?"— eso no es un hueco: es que el documento consiguió que alguien pensara sobre tu sistema, que es lo máximo a lo que puede aspirar.

Por qué funciona: tú no puedes evaluar tu propio README, porque sabes lo que quisiste decir. La única prueba válida es alguien que no estuvo ahí.

Ejercicio 3 — Escribe la publicación de una decisión. Elige una decisión de tu proyecto y escribe quinientas palabras contándola: el problema, lo que probaste, lo que mediste, y qué decidiste. No el proyecto entero — una decisión.

Ver solución

Las que mejor funcionan, y por qué:

"Calibré el filtro de seguridad de mi agente para que dejara pasar ataques." Es contraintuitivo desde el título, y la explicación —que el filtro se calibra contra los clientes legítimos y no contra las amenazas, porque el cliente enojado no tiene ninguna capa debajo y el ataque tiene cuatro— es un razonamiento que la mayoría no ha hecho.

"Le quité una regla de negocio a mi agente y la puse en catorce líneas de código." Cuenta la decisión de check_return_eligibility con su número: de dos a cuatro llamadas al modelo por uso a cero, y de "acierta casi siempre" a determinista. Es la respuesta a "cuándo un agente no es la solución", en formato de historia.

"Cuánto cuesta de verdad un agente de atención al cliente." Es la que más se lee, porque casi nadie publica números. Con la hoja de costo desglosada por componente y el hallazgo de que el sesenta por ciento del ahorro viene de una sola decisión de modelo.

La estructura que funciona, en cuatro párrafos:

  1. El problema, en una situación concreta. No "la seguridad en agentes es importante", sino "bajé el umbral del filtro hasta bloquear todos los ataques y bloqueé a un cliente que exigía su dinero en mayúsculas".
  2. Lo que probaste, con el detalle suficiente para que alguien pueda repetirlo.
  3. El número. Sin número no hay publicación: hay opinión.
  4. La decisión y su costo. Qué elegiste y qué aceptaste perder.

Y lo que no hay que hacer: cerrar pidiendo opiniones ni con una frase motivacional. Un texto que termina en el dato termina bien.

Por qué funciona: el proyecto entero es demasiado grande para que alguien lo lea sin un motivo previo. Una decisión con un número es del tamaño correcto, y es lo que hace que alguien quiera ver el proyecto entero — que es exactamente el orden que buscas.

Resumen y cierre de la guía

El proyecto está entregado. Tienes los seis artefactos en un paquete, con los workflows exportados, el esquema SQL reproducible y los siete documentos que hacen el sistema auditable por alguien que no lo construyó. Una demo de tres minutos que empieza por un ataque en el segundo quince, muestra dónde se detiene, abre la sección L3 de la matriz, demuestra el cambio de canal en diez segundos, da tres números concretos y cierra reconociendo el límite. Un README con la tabla de mediciones arriba, la frase de "lo peor que puede hacer" escrita literal, y cuatro limitaciones conocidas con su decisión. Y ocho respuestas escritas con el molde de decisión, comparación y límite, más la novena que nadie prepara.

Mirando el módulo completo: empezaste con ocho requisitos y una rúbrica de tres niveles. Dedicaste cuarenta y cinco minutos a un plano en papel con cinco decisiones y doce casos de prueba escritos antes de que existiera nada que probar. Construiste el cerebro con tools falsas para poder equivocarte gratis. Le pusiste manos reales con vistas recortadas, credenciales de solo lectura y una regla de negocio movida a código determinista. Le abriste dos puertas sobre un núcleo único con memoria por cliente y una tabla de identidades que registra cómo se verificó cada una. Le pusiste cerraduras calibradas contra los clientes y no contra los ataques, con una aprobación humana cuyo umbral salió de la distribución real y de la capacidad de dos personas. Le pusiste instrumentos: una validación determinista, una bitácora que sobrevive a la purga, tres consultas que corren solas, y una hoja de costo con dólares. Y lo empaquetaste para que se entienda sin ti.

Y mirando la guía entera: empezaste distinguiendo un agente de un chatbot y de la IA procedural. Le diste un cerebro con un modelo vigente y un system prompt con rol y límites. Le diste memoria, y aprendiste cuándo esa memoria se degrada y cuándo hay que dejarla ir. Le diste tools sobre sistemas reales, con sus contratos y sus límites de confianza. Lo partiste en un equipo que delega de forma nativa, con condiciones de parada y una economía medida. Lo llevaste a los canales donde está la gente, con una arquitectura que no duplica la lógica. Lo endureciste contra quien intenta secuestrarlo y contra su propia tendencia a afirmar lo que no sabe. Y lo pusiste todo junto en un sistema que se entrega, se mide y se defiende.

No está mal para algo que empezó con un nodo que respondía una pregunta.

Lo que sigue depende de a dónde vayas. Si tu camino es el conocimiento documental —que un agente responda sobre tus propios PDF, facturas y manuales con recuperación semántica— esa es la siguiente guía del ecosistema, y este sistema es la base sobre la que se monta: search_knowledge_base es exactamente el punto donde entra. Si tu camino es operar esto en serio —entornos separados, secretos externos, versionado con Git, monitoreo con alertas y CI/CD— esa es la guía de producción y mantenimiento, que retoma justo donde la lección 7 puso su límite honesto. Y si tu camino es construir agentes en código en vez de orquestarlos, todo el criterio de esta guía se transfiere: los contratos, los niveles de permiso, la aprobación humana y la validación determinista son los mismos, solo cambia dónde los escribes.

Sea cual sea, ya tienes lo que las ofertas piden: un sistema de agentes real, medido, seguro y defendible. No un POC.

Recursos

← Anterior7. Depuración, monitoreo básico y control de costos