01Mensajelenguaje humano02LLMinterpreta el texto03Datosestructura JSON04Lógicareglas en un Switch05Acciónresponder o escalar
Mensaje · LLM · Datos · Lógica · Acción
01 · OBJETIVO Y AGENDA
¿Qué vas a poder hacer al terminar?
Leer el mensaje de un cliente, entender qué quiere, sacar los datos importantes en una estructura ordenada y usar esa estructura en n8n para decidir qué hacer después.
Lo lograste si…
procesas correctamente 3 mensajes distintos e identificas en cada uno:
la intención principal;
la intención secundaria, si existe;
los datos del cliente;
los datos que faltan;
si necesita o no a una persona.
Y puedes explicar este camino
Lenguaje humanoEl cliente escribe como habla: todo junto.
LLMEl modelo interpreta el mensaje siguiendo un prompt.
Datos estructuradosSale un JSON con campos fijos.
LógicaReglas (por ejemplo, un Switch) leen esos campos.
AcciónSe crea un ticket, una cotización o se escala a una persona.
El lunes lo desarmamos. Hoy lo ponemos a trabajar.
El lunes vimos cómo está construido un agente: modelo, System Prompt, memoria, contexto, tools, skills, guardrails y loop. Hoy no repetimos esa anatomía: la usamos en casos reales.
Lunes
¿Cómo está construido un agente?
Sus piezas y cómo se conectan.
Hoy
¿Cómo usa la información para actuar?
Del mensaje de un cliente a una decisión dentro de un workflow.
Cinco conceptos que usamos hoy
ModeloInterpreta el mensaje.
PromptEspecifica qué debe buscar.
ClasificaciónDecide qué tipo de solicitud es.
ExtracciónObtiene datos concretos del texto.
Structured OutputConvierte lenguaje natural en información que un software puede usar.
Un prompt para conversar y un prompt para automatizar no buscan la misma salida.
Para conversar
“Carlos tiene un problema con su pedido 18492: le llegaron dos laptops dañadas. Además quiere cotizar 20 más para su oficina.”
Perfecto para una persona. Difícil de usar para un programa.
Cada dato en su campo. n8n puede leerlo y decidir.
Para arrancar: si Carlos escribe que su pedido llegó dañado, pero además quiere comprar 20 productos más, ¿cuántas necesidades tiene?
Por lo menos dos: soporte (el pedido llegó dañado) y ventas (quiere comprar más). Hoy vamos a lograr que un modelo detecte eso automáticamente.
03 · CLAUDE CODE APLICADO · 30 MIN
Claude Code: un agente trabajando en un proyecto real
No es “un ChatGPT que escribe código”. Es un agente especializado: recibe un objetivo, revisa el contexto, decide qué herramienta necesita, actúa, comprueba el resultado y continúa. Fíjate menos en lo que genera y más en cómo trabaja.
3.1Primero, conocer el proyecto
Antes de ejecutar, Claude necesita conocer el proyecto. Por eso lo primero que hace es inspeccionar los archivos. Usamos un proyecto pequeño: una página sencilla de atención al cliente.
novashop-demo/
index.htmlla página
styles.csslos estilos
app.jsla lógica del formulario
3.2Plan Mode y permisos
Un agente que puede editar archivos y ejecutar comandos necesita límites. Claude Code te deja elegir cuánto control quieres tener:
Pedir permiso
Para aprender
Claude te pide autorización antes de editar archivos o ejecutar comandos. Ves y apruebas cada paso.
Plan Mode
Tareas complejas
Primero investiga y te propone un plan. No cambia nada hasta que tú lo apruebas.
Omitir permisos
Solo entornos aislados
Ejecuta todo sin preguntar. Solo tiene sentido en un contenedor o una máquina virtual, nunca en tu computadora con archivos importantes.
Para aprender y en proyectos importantes, no empieces saltándote los permisos. Primero mira qué planea hacer.
3.3CLAUDE.md vs. Skill
CLAUDE.md
Las reglas permanentes del proyecto. Es un archivo en la carpeta del proyecto y Claude lo tiene en cuenta cada vez que trabaja ahí.
Siempre activo
Skill
Un procedimiento reutilizable: instrucciones, conocimiento o un flujo de trabajo que Claude carga solo cuando la tarea lo necesita.
Se carga cuando hace falta
Ejemplo · CLAUDE.md
Proyecto NovaShop.
Reglas:
- Todo texto visible debe estar en español.
- Mantén HTML/CSS/JS separados.
- Antes de terminar, prueba la interfaz.
- No elimines archivos sin aprobación.
3.4El loop en acción
Esta es la instrucción que le damos. Fíjate en que le pedimos un plan antes de tocar nada y que no termine hasta comprobar que funciona:
Prompt de la demo
Inspecciona este proyecto. El formulario debería impedir que se
envíe si el correo no es válido. Primero revisa los archivos y
explícame tu plan. Después corrige el problema, verifica el
comportamiento y no des por terminada la tarea hasta comprobar
que funciona.
1Inspeccionar
2Planear
3Modificar
4Probar
5Observar
6Corregir
Si algo falla, vuelve al inicio del ciclo hasta que funciona.
Mientras trabaja, identifica las piezas del agente. Toca cada tarjeta para ver la respuesta:
¿Por qué esto sí se parece al agente que vimos el lunes?
Porque no produjo una sola respuesta: inspeccionó un entorno, actuó sobre él y verificó el resultado. Lo importante de la demo no es la página final, es ver ese proceso.
04 · CLASIFICAR Y EXTRAER
Clasificar no es lo mismo que extraer
Son dos tareas distintas que el modelo hace sobre el mismo mensaje. Una responde qué quiere la persona; la otra, qué datos dio.
Clasificar
¿Qué quiere?
Decide a qué categoría pertenece el mensaje.
soporteventasfacturacionseguimientootro
Extraer
¿Qué datos dijo?
Saca datos concretos del texto, cada uno en su campo.
“Hola, soy Carlos Mendoza. Mi pedido 18492 llegó con dos laptops dañadas y además necesito cotizar otras 20 para nuestra oficina.”
dato extraído
intención: soporte
intención: ventas
Resultado de clasificar
soportellegó con dos laptops dañadas
ventasnecesito cotizar otras 20
Un mismo mensaje puede tener una intención principal y una secundaria.
Resultado de extraer
nombre_cliente
"Carlos Mendoza"
numero_pedido
"18492"
producto
"laptop"
cantidad_afectada
2
cantidad_solicitada
20
problema
"producto_danado"
“dos” se convierte en el número 2. El pedido va entre comillas porque es un identificador, no una cantidad.
De lenguaje a estructura
JSON
LLM
TEXTO
Lenguaje naturalCarlos escribe como escribe una persona: todo junto, sin orden.
LLM + promptEl modelo interpreta el texto siguiendo tus instrucciones.
Datos estructuradosSale un objeto con campos fijos que otro sistema puede leer.
05 · LABORATORIO N8N
Construye el workflow: mensaje → LLM → JSON → decisión
Vamos a construir un workflow que recibe un mensaje y devuelve datos estructurados. Después, un Switch usa esos datos para decidir a dónde va cada caso.
Te permite ejecutar el workflow a mano mientras pruebas.
Edit Fields
Crea un campo llamado mensaje (tipo texto) y pega ahí el mensaje del cliente.
Basic LLM Chain
Pega el prompt de abajo. Al final lleva el mensaje con la expresión {{ $json.mensaje }}. Activa Require Specific Output Format para conectar el parser.
Chat Model
Conéctalo a la entrada Model del Basic LLM Chain. Usa la credencial que ya está configurada para la clase.
Structured Output Parser
Conéctalo a la entrada Output Parser. Genera el esquema a partir de un ejemplo JSON y pega la salida esperada.
Switch
Crea una salida por intención comparando {{ $json.output.intencion_principal }} con soporte, ventas, facturacion y seguimiento. Agrega otra para cuando requiere_humano sea true.
Nunca muestres, copies ni compartas una API key en pantalla, en el chat de la clase o en capturas.
Material para copiar
Mensaje del cliente
Hola, soy Carlos Mendoza.
Mi pedido 18492 llegó con dos laptops dañadas
y además necesito cotizar otras 20 para nuestra oficina.
Eres un sistema de clasificación y extracción
de información para atención a clientes de NovaShop.
Analiza el mensaje recibido.
TAREAS
1. Identifica la intención principal entre:
- soporte
- ventas
- facturacion
- seguimiento
- otro
2. Si existe otra intención, identifícala
como intención secundaria.
3. Extrae cuando exista:
- nombre_cliente
- numero_pedido
- producto
- cantidad_afectada
- cantidad_solicitada
- problema
4. Determina si requiere intervención humana.
REGLAS
- No inventes información.
- Si un dato no está disponible, utiliza null.
- No deduzcas números de pedido.
- La intención secundaria puede ser null.
- Devuelve exclusivamente la estructura solicitada.
MENSAJE DEL CLIENTE:
{{ $json.mensaje }}
Tu workflow está bien si…
la intención es correcta;
los datos extraídos son correctos;
los datos que no existen quedan en null;
la estructura es siempre la misma;
no inventa datos.
¿Y la intención secundaria?
Carlos también quiere comprar. Para atender las dos cosas, agrega reglas sobre intencion_secundaria y activa la opción del Switch para enviar a todas las salidas que coincidan.
Plan B
Si n8n o el modelo fallan, pega el mismo prompt en un chatbot (con el mensaje en lugar de {{ $json.mensaje }}) y obtén el JSON. La lógica es la misma: JSON → Switch → acción.
06 · CUANDO LA IA NO SABE
Si un dato no está, no se inventa
Un modelo siempre intenta dar una respuesta. En una automatización eso es peligroso: un número de pedido inventado puede mandar un reembolso o un ticket al cliente equivocado.
No inventarEl prompt lo dice explícitamente.
nullEl campo existe, pero va vacío: dato faltante.
Preguntar o escalarEl workflow pide el dato o pasa el caso a una persona.
Ejemplo
“Hola, me llegaron dos laptops con la pantalla rota. ¿Qué hago?”
Algunas ideas para discutir: cuando el cliente está muy molesto o amenaza con una queja, cuando la confianza es baja, cuando faltan datos que no se pueden pedir automáticamente o cuando hay dinero de por medio y el caso no está claro.
07 · TU TURNO
Procesa estos 3 mensajes
En cada uno identifica: intención principal, intención secundaria, datos del cliente, datos faltantes y si necesita a una persona. Después compara con la solución.
Mensaje 1
“Buenas tardes, soy Ana Torres. Me cobraron dos veces el pedido 30118.”
Humano: cliente molesto y sin datos para resolverlo solo
También se acepta soporte como intención. Lo importante es requiere_humano: true.
08 · PRÓXIMA PARADA
RAG: cuando el modelo necesita información de tu empresa
El modelo sabe mucho en general, pero no conoce las reglas de NovaShop: su política de devoluciones, sus precios o sus horarios. RAG resuelve eso: primero busca la información y después responde con ella.
FAQ
Catálogo
PolíticasRECUPERADO
Pedidos
PreguntaEl cliente pregunta algo propio de la empresa.
BuscarSe busca en los documentos de la empresa.
Recuperar contextoSe toma solo el fragmento que sirve.
LLMEl modelo recibe la pregunta junto con ese fragmento.
RespuestaResponde basándose en esa información, no en suposiciones.
Pregunta
“¿Puedo devolver este producto después de 45 días?”
Fragmento recuperado
Política de devoluciones: se aceptan devoluciones dentro de los 30 días posteriores a la entrega.
Respuesta
“No. Según la política de NovaShop, las devoluciones se aceptan hasta 30 días después de la entrega.”
Ejemplo ficticio. Por ahora quédate con la idea; cómo se busca la información por dentro lo veremos más adelante.
09 · AUTOEVALUACIÓN
Comprueba lo que aprendiste
Piensa tu respuesta y después revísala. Es una práctica: si hay una evaluación publicada en la plataforma, esa es la que cuenta.
1. ¿Cuál es la diferencia entre clasificación y extracción?
La clasificación determina a qué categoría pertenece el mensaje. La extracción recupera datos específicos que vienen dentro del mensaje.
2. ¿Por qué estructurar la salida?
Porque un workflow necesita campos predecibles para tomar decisiones y enviar información a otros nodos o sistemas.
Pregunta 3
El usuario no proporciona número de pedido. ¿Qué debería hacer el modelo?
4. ¿Qué problema resuelve RAG?
Permite recuperar información relevante de una fuente externa (por ejemplo, los documentos de la empresa) y dársela al modelo para que responda con base en esa información específica.
Meta3 de 4 respuestas correctas y tu workflow funcionando.
10 · CIERRE
Lunes: diseccionamos al agente. Miércoles: lo ponemos a trabajar.
Esta semana empezamos entendiendo cómo está construido un agente. Hoy vimos cómo esa inteligencia entra a una automatización: recibe lenguaje humano, clasifica lo que la persona quiere, extrae los datos y entrega una estructura que otros sistemas pueden usar.
Lo que sigue: ¿qué pasa cuando el modelo necesita conocer información específica de nuestra empresa? Ahí entra RAG.