Jacobo: Agente IA Omnicanal con Sub-agentes y Tool Calling

~15 interrupciones al día. Cada una, una reparación parada. Cada WhatsApp sin responder, un cliente que se iba a la competencia. Construí un agente IA que gestiona ambos canales: ~90% de las interacciones, 24/7, por menos de 200€/mes.

No un chatbot con respuestas enlatadas. Un agente que consulta precios reales, verifica stock, gestiona citas y sabe cuándo escalar a un humano con todo el contexto. Así nació Jacobo. En este artículo comparto la arquitectura completa y los workflows de producción para que puedas replicarlo.

El Problema#

Con +30.000 reparaciones completadas y múltiples canales de atención (teléfono, WhatsApp, web), el cuello de botella era claro:

Sabía tres cosas desde el principio: Airtable era el cerebro (el Business OS ya llevaba años como SSOT), necesitaba tool calling real contra esos datos, y el agente tenía que ser multimodal (voz + chat) compartiendo los mismos recursos. La pregunta era qué herramienta de orquestación usar:

La Arquitectura#

Jacobo no es un chatbot con un prompt largo. Es un sistema de sub-agentes especializados, cada uno desplegado como un webhook independiente en n8n, orquestados mediante tool calling desde un router central. Cada workflow que ves en este artículo es descargable: podrás importarlo directamente en n8n.

Stack

Jacobo se apoya en 8 servicios que cubren desde la entrada del cliente hasta el escalado humano. Cada uno tiene un rol único; ninguno es reemplazable sin cambiar la arquitectura.

¿Por qué sub-agentes en vez de un prompt monolítico?

4 Agentes y 3 Tools Para Gobernarlos a Todos

4 agentes con LLM propio toman decisiones. 3 tools sin LLM ejecutan lógica de negocio pura. Todo conectado por webhooks.

Tools (sin LLM)

Memoria Conversacional

Jacobo no tiene estado propio entre mensajes. Cada vez que llega un mensaje nuevo, reconstruye el contexto leyendo el historial real de la conversación desde WATI:

Tests de memoria episódica: animales, ciudades y autocorrección cuando Jacobo olvida Barcelona

Memoria en acción: marcas recordadas en orden, cita recuperada desde el estado del sistema y re-negociación cuando no hay disponibilidad

Herramientas de debug en producción

Dos comandos ocultos para depurar la memoria en producción sin tocar n8n. "Borrar memoria" reseteaba el buffer del cliente, útil cuando una conversación se corrompía o el LLM entraba en bucle. "HISTORIAL" volcaba el JSON crudo del buffer. Y eso fue lo que nos enseñó a sanitizar las respuestas: el LLM devolvía el JSON completo al cliente si no se filtraba.

Comandos de debug en producción: HISTORIAL volcaba el JSON crudo del buffer y BORRAR MEMORIA reseteaba la conversación

Pseudo-Streaming en WhatsApp

WhatsApp no soporta streaming. Un párrafo largo se siente como un bot; mensajes secuenciales se sienten como una persona escribiendo. El router divide cada respuesta por saltos de línea y envía cada fragmento con 1 segundo de espera entre ellos vía la API de WATI. El resultado: la experiencia de "está escribiendo..." sin infraestructura de streaming.

Los Dos Canales

Jacobo opera en dos canales simultáneos. Lo importante: ambos comparten los mismos sub-agentes webhook. La lógica de negocio se escribe una vez.

WhatsApp (mayor volumen)

WATI como WhatsApp Business API + n8n como orquestador. El 70% de las consultas llegan por aquí.

Teléfono Fijo (voz)

Aircall como Cloud PBX + Twilio como bridge telefónico + ElevenLabs como agente de voz conversacional. Jacobo es literalmente un "compañero más" en la centralita Aircall con sus propias reglas de routing.

Recuperación de Llamadas Perdidas

Si el cliente colgaba o nadie atendía, Aircall enviaba un webhook a Make.com que disparaba un template de WhatsApp vía WATI con botones de acción. Una gran parte de los leads llegaban por aquí: gente que llamaba, no esperaba, y Jacobo los cazaba. Como se nutría del contexto de WATI, al contestar ya sabía que habían intentado llamar.

Aircall → Make.com → template WhatsApp con botones → Jacobo retoma la conversación con contexto completo

UX Unificada: Una Sola Voz

Todos los audios de la centralita (bienvenida, menú IVR, buzón de voz) fueron generados con ElevenLabs usando la misma voz que Jacobo. Cuando el cliente pulsa 3 o nadie puede atender y salta el agente real, la voz es idéntica. No hay ruptura. Y si nadie atiende y Jacobo le escribe por WhatsApp tras la llamada perdida, la identidad sigue siendo la misma. Una experiencia unificada de principio a fin, da igual el canal.

Escucha la centralita real. La misma voz de Jacobo en bienvenida, IVR y agente en vivo:

Pre-filtrado: ¿Debe Jacobo Responder?

Antes de que el mensaje llegue al AI Agent, tres switches filtran el ruido y deciden quién debe responder:

Flujos End-to-End#

Cada flujo traza el happy path desde la consulta del cliente hasta la resolución. Los sub-agentes involucrados aparecen etiquetados en cada paso.

Cita de Reparación

Consulta de Precios

Escalado a Humano (HITL)

Los Dos Cerebros#

Jacobo tiene dos routers independientes que comparten los mismos tools y sub-agentes. Uno orquesta WhatsApp, el otro gestiona las llamadas de voz. Misma lógica de negocio, dos interfaces completamente distintas.

Router WhatsApp (n8n)

El cerebro de texto: un workflow de n8n con 37 nodos que clasifica cada mensaje, decide qué sub-agente invocar y orquesta la respuesta. Aquí viven el tool calling, el prompt engineering y toda la lógica de enrutamiento.

Router Voz (ElevenLabs)

El cerebro de voz: un agente conversacional en ElevenLabs con Gemini 2.5 Flash, knowledge bases con la documentación del negocio, y los mismos tools expuestos como webhooks. El cliente habla por teléfono y Jacobo responde en tiempo real, consultando precios, disponibilidad y gestionando citas, exactamente igual que por WhatsApp.

Tool Calling en Producción

Jacobo no genera respuestas desde su training data. Cada respuesta se construye consultando sistemas reales vía 7 tools definidos como HTTP endpoints:

mensajeConsulta: UX mientras piensa

Cuando Jacobo llama a presupuestoModelo (1-3 segundos de latencia), primero dispara mensajeConsulta: un "Estoy consultando disponibilidad..." que llega al cliente antes de que el sub-agente responda. Sin esto, el cliente veía 5 segundos de silencio y pensaba que el bot se había colgado. Un detalle de UX que marca la diferencia entre "chatbot roto" y "asistente que trabaja".

Adaptabilidad: el cliente pide formato email y Jacobo responde con asunto, presupuesto desglosado, descuento combo y firma corporativa

El Tool "Think"

Antes de ejecutar una cadena de tools (consultar precio → verificar stock → ofrecer cita), el agente invoca Think para planificar la secuencia. Esto reduce errores en cadenas multi-tool porque el LLM explicita su razonamiento antes de actuar.

Stock-Aware Routing

El output de presupuestoModelo determina el siguiente paso. No es un flujo fijo: el CTA cambia según la disponibilidad real.

Prompt Engineering en Producción

No hice fine-tuning. Para un chatbot de tienda de reparaciones, iterar sobre el prompt con hard rules es más pragmático, más barato y más rápido de ajustar que entrenar un modelo custom. Cada regla que ves abajo nació de un caso real en producción.

¿Por qué hard rules en el prompt y no fine-tuning?

Detección de horario comercial

Un nodo de código JavaScript verificaba si la tienda estaba abierta antes de cada conversación. El resultado se inyectaba como variable dinámica en el prompt: si `isBH` era false, Jacobo ajustaba su tono ("fuera de horario intentaré ayudarte igualmente") y no prometía respuestas inmediatas de compañeros humanos.

const madridTime = new Date().toLocaleString('en-US', {
  timeZone: 'Europe/Madrid',
});
const madridDate = new Date(madridTime);
const day  = madridDate.getDay();   // 0-domingo … 6-sábado
const hour = madridDate.getHours();

const isBH = day >= 1 && day <= 5 &&
             ((hour >= 10 && hour < 14) || (hour >= 17 && hour < 21));

return [{ json: { isBH } }];

La misma pregunta, respuestas opuestas: a las 11:56 cerrado (pausa mediodía), a las 13:12 abierto. Consciencia de horario en tiempo real.

System prompt del router principal (n8n)

Versión simplificada del prompt de producción. El original tiene 18 reglas y variables adicionales, pero cada bloque aquí refleja una técnica deliberada de prompt engineering.

## ROL
Te llamas Jacobo y trabajas en Santifer iRepair, tienda de reparación
de móviles, tablets, smartwatches en Sevilla. Eres un experto comercial
y en electrónica, que sabe diagnosticar los problemas que tienen los
usuarios en sus dispositivos móviles.

HorarioComercial={{ $('isBH').item.json.isBH }}
- Si false → la tienda está cerrada: informa con amabilidad
- Si true → responde con normalidad y ofrece ayuda inmediata

## Objetivo
Identificar modelo + avería → consultar stock → conversión hacia cita,
pedido o presupuesto.

Si el dispositivo no es móvil, tablet o
smartwatch, dar ayuda general pero no invitar a dejarlo en tienda.

## Instrucciones
1. Identificar modelo y síntomas → llamar a "presupuestoModelo"
2. Si varias reparaciones → llamar a "Calculadora" (array de precios)
3. Tras respuesta de presupuestoModelo:
   3.1 Hay stock → ofrecer cita vía "subagenteCitas" con urlCita
   3.2 No hay stock → ofrecer pedido urgente vía "hacerPedido"
   3.3 No hay presupuesto → facilitar urlPresupuesto

## Herramientas
- "mensajeConsulta": mensaje de espera antes de consultar precio
- "presupuestoModelo": lookup de modelo + avería en Airtable
- "contactarAgenteHumano": escalado HITL vía Slack
- "Think": razonamiento interno antes de tool calls complejos
- "Calculadora": descuento multi-reparación
- "subagenteCitas": gestión de citas vía YouCanBookMe
- "hacerPedido": crear pedido en Airtable cuando no hay stock

## HARD RULES (nacidas de producción)
1. Siempre llamar a Think antes de responder o pasar datos

2. No modificar URLs de "presupuestoModelo" (Meta da error)
3. Un solo * para negrita (WhatsApp), no dos **
4. iPhone + Pantalla → ofrecer SIEMPRE opción premium (12 meses
   garantía vs 6). No está en web → derivar a humano si interesa
5. Enlaces planos, sin markdown (Meta rechaza [text](url))
6. Solo llamar a subagenteCitas TRAS presupuestoModelo
7. Diagnóstico: 19€, solo se cobra si no acepta la reparación
8. Correo: contacto@santiferirepair.es (no info@)

9. No decir "agendar" cita → decir "tomar" cita
10. No recomendar otras tiendas

System prompt del agente de voz (ElevenLabs)

Versión simplificada del prompt de voz en producción. Mismo dominio, adaptado a conversación telefónica. Comparte las mismas tools webhook pero el flujo es más directo.

## ROL
Te llamas Jacobo y trabajas en Santifer iRepair, tienda de reparación
de móviles, tablets, smartwatches en Sevilla. Sé conciso, amigable y
resolutivo.

## Objetivo
Identificar modelo + avería → consultar stock → facilitar enlace.
Solo dar detalles técnicos cuando el cliente no tenga clara la avería.
Objetivo: que el cliente tome cita (si hay stock) o genere pedido.

## Instrucciones
1. Obtener modelo y avería
2. Indicar que estás haciendo la consulta → llamar a "presupuestoModelo"
3. Enviar "urlSantifer" vía "EnviarMensajeWati" (WhatsApp en paralelo)
4. Si varias reparaciones → llamar a "Calculadora"
5. Informar precio + disponibilidad + "te he mandado la info por WhatsApp"

## HARD RULES
1. No modificar URLs de "presupuestoModelo"
2. iPhone + Pantalla → ofrecer opción premium (12 meses garantía)
3. No decir "agendar" → decir "tomar"
4. Cierre 18-22 agosto: si necesitan recoger equipo → mensajería gratis

Número del cliente: {{system__caller_id}}

Ejemplos de iteraciones reales

Iteración real: Jacobo simplificó la política de diagnóstico → el prompt se refinó para incluir la condición exacta

Deep Dive: Reservar Cita en Lenguaje Natural#

El sub-agente de citas es el workflow más sofisticado del sistema. Su trabajo: convertir "mañana por la mañana" en una cita confirmada con piezas reservadas, sin que el cliente toque un formulario.

El reto: cruzar dos mundos

El cliente habla en lenguaje natural ("el jueves a media mañana, o si no el viernes por la tarde"). La API de YouCanBookMe habla en timestamps Unix. El sub-agente tiene que traducir uno al otro y encontrar la intersección.

ParseURL

Un nodo Code que extrae el subdomain de la URL de YouCanBookMe para determinar qué perfil de reservas usar. Parsea el query string para campos dinámicos del formulario (tipo de reparación, datos del cliente). Diferentes calendarios para diferentes servicios: santifer-citav2-componentes para reparaciones de componentes, santifer-citav2-diagnostico para diagnósticos. El subdomain determina el flujo completo que seguirá la reserva.

AnalizarDisponibilidad (LLM)

Un agente LLM con MiniMax M2.5 convierte lenguaje natural en un array JSON estructurado: [{date, start, end, exact}]. El system prompt contiene 15 reglas de parseo temporal que cubren todos los casos reales. Incluye un Structured Output Parser para garantizar formato válido y memoria por sesión (sessionKey = teléfono/ycbmUrl) para que el cliente pueda refinar preferencias sin empezar de cero. Si no hay preferencia explícita, devuelve los próximos 3 días laborables con horario completo.

YCBM API (3 llamadas)

Pipeline secuencial de 3 HTTP Requests contra la API de YouCanBookMe. Cada llamada depende de la anterior; no se puede paralelizar:

FilterSlots: El Cruce

Un nodo Code puro que realiza la intersección de conjuntos: rangos del LLM × slots reales de YCBM. Convierte timestamps Unix a Europe/Madrid usando Intl.DateTimeFormat, luego filtra: localDate === r.date && localTime >= r.start && localTime < r.end. El output es un array [{date, timestamp, start}] que puede contener 0, 1, o N slots. Es el nodo más elegante del workflow: pura lógica de conjuntos, sin LLM, sin API. Solo matemáticas temporales.

Auto-booking Condicional

Un nodo If evalúa slots.length y bifurca en 3 caminos. El sub-agente tiene su propia memoria por sesión: el cliente puede refinar ("no, mejor el jueves") sin empezar de cero.

Flujo completo de reserva: el cliente pide cita en lenguaje natural, Jacobo negocia horario, confirma en calendario y envía mensaje de confirmación — todo transparente para el usuario.

System prompt del sub-agente de citas (n8n)

15 reglas de parseo temporal que convierten frases coloquiales en rangos horarios JSON. Este prompt es la pieza clave del sub-agente más sofisticado del sistema: traduce lenguaje natural a timestamps compatibles con la API de YouCanBookMe.

Eres un micro-servicio que convierte frases de preferencia horaria fecha y hora (español de España)
en un array JSON de rangos.

REGLAS DE NEGOCIO
1. Rangos por defecto:
   – mañana = 10:00-14:00
   – tarde   = 17:00-21:00
   – "todo el día" = 10:00-21:00
2. exact será true solo si el usuario da una hora puntual que termine
   en 00 o 30 (ej. "lunes a las 10" o "martes a las 17:30" pero no
   "miércoles a las 10:15").
   Si menciona un rango ("martes de 10 a 12") ⇒ exact:false.
3. Horas con minutos ≠ 00 ó 30 se redondean:
   - Redondea hacia abajo al múltiplo de 30 min anterior.
   - Crea un rango de 1 hora a partir de esa hora redondeada
     (ej. 10:15 ⇒ 10:00-11:00, exact:true porque era puntual).
4. La fecha actual es {{ $now.format('yyyy-MM-dd HH:mm') }} (Europe/Madrid).
5. Acepta varias peticiones separadas por "y", comas o punto y coma.

6. Devuelve EXCLUSIVAMENTE una llamada de función con esta forma:
   {"name":"slots","arguments":{"slots":[
     {"date":"AAAA-MM-DD","start":"HH:mm","end":"HH:mm","exact":true/false}
   ]}}
6.1 Si la frase incluye "mañana" sin especificar parte del día,
    trátalo como «todo el día» de mañana (10:00–21:00).

7. PLURAL ("mañanas", "tardes"): devuelve las próximas N=3 franjas.
   Incluye hoy si la franja aún no ha terminado.
8. Solo abre de lunes a viernes. Nunca sábado ni domingo.
9. Conectores condicionales ("o", "o bien", "o si no"):
   preferencias alternativas en el mismo orden.
10. "A partir de [día]": todo el día (10:00-21:00) + N-1 laborables.
11. N=5 por defecto.
12. Día concreto: solo las horas de ese día.
13. "Esta semana": todas las franjas laborables restantes (Lu-Vi).
14. Plurales: próximas 3 franjas.
15. Sin preferencia horaria: próximos 3 días laborables, todo el día.

# EJEMPLOS
Input: "mañana por la mañana"
→ {"slots":[{"date":"[mañana]","start":"10:00","end":"14:00","exact":false}]}

Input: "martes de 10 a 12 y viernes todo el día"
→ {"slots":[
  {"date":"[martes]","start":"10:00","end":"12:00","exact":false},
  {"date":"[viernes]","start":"10:00","end":"21:00","exact":false}
]}

Input: "lunes a las 10"
→ {"slots":[{"date":"[lunes]","start":"10:00","end":"11:00","exact":true}]}

Deep Dive: Sub-agente de Presupuestos#

El sub-agente de presupuestos es el más crítico del sistema: cada consulta de precio pasa por aquí. Usa GPT-4.1 mini vía OpenRouter por su precisión en structured output. Su respuesta determina el siguiente paso del flujo completo.

El reto: del texto libre al presupuesto estructurado

El cliente escribe "cuánto cuesta cambiar la pantalla de un iPhone 15 Pro Max". El router necesita un JSON con precio, stock, URLs de cita y pieza. El sub-agente conecta lenguaje natural con la base de datos de Airtable en tiempo real.

CleanModel: Codificar conocimiento tácito

Los clientes no escriben modelos como una base de datos. Escriben "iphone 15", "iPhone15 pro max", "ip 15 pro", "I-Phone 15Pro Max". Un técnico humano resolvía esto con experiencia: sabía que "el grande negro" probablemente era un Pro Max. Ese conocimiento tácito se pierde si no se diseña para ello.

CleanModel normaliza el input: elimina espacios, paréntesis, guiones y pasa a minúsculas. "iPhone 15 Pro Max" → "iphone15promax". Esto alimenta una búsqueda con SEARCH() en Airtable por campo modeloLimpio (también normalizado), permitiendo fuzzy matching sin depender de escritura exacta.

AI Agent: GPT-4.1 mini vía OpenRouter

El cerebro del sub-agente. System prompt con ROL ultra-scoped: "agente especializado en buscar precios". Incluye Think tool para razonamiento explícito antes de cada tool call y Simple Memory (buffer window) con sessionKey estática.

Si no encuentra coincidencia, el system prompt instruye: "tienes que ir acotando el modelo para obtener más resultados, hasta que te quedes con el que corresponda", replicando el razonamiento de un humano experimentado.

FiltrarRespuesta: Post-procesado determinista

Nodo Code que valida y limpia la respuesta del AI Agent antes de devolverla al router. Valida que urlSantifer apunte al dominio correcto (si no contiene "santiferirepair.es" → "NO DISPONIBLE EN WEB AUN"). Después aplica 3 paths de eliminación de campos según estado:

System prompt del sub-agente de presupuestos (n8n)

El prompt define tres herramientas (BuscarModelo, BuscarReparacionesModelo, Structured Output Parser) y un flujo de 4 pasos para devolver presupuestos estructurados con estado de stock.

## ROL
Eres un sub-agente de presupuestos para Santifer iRepair.
Tu trabajo: recibir un modelo y una reparación, buscarlos en Airtable
y devolver un presupuesto estructurado.

## OBJETIVO
Buscar el modelo exacto y la reparación solicitada en la base de datos.
Devolver precio, disponibilidad de stock y siguiente paso recomendado.

## HERRAMIENTAS
- "BuscarModelo": busca el modelo del dispositivo en Airtable
- "BuscarReparacionesModelo": busca reparaciones disponibles para ese modelo
- "Structured Output Parser": formatea la respuesta en JSON estructurado

## PASOS
1. Recibir modeloInput y reparacionInput del router
2. Llamar a BuscarModelo con modeloLimpio
3. Si encuentra el modelo → llamar a BuscarReparacionesModelo
4. Devolver JSON: precio, stock, tiempo estimado, urlCita, urlPresupuesto

// User message template (n8n inyecta las variables)
Modelo: {{ $json.modeloInput }}
Modelo limpio: {{ $json.modeloLimpio }}
Reparación: {{ $json.reparacionInput }}

Presupuestos reales: diagnóstico con precio y enlace, presupuesto triple con desglose y total con estado de stock

Deep Dive: Tools#

No todas las piezas del sistema necesitan un LLM. Estas tres tools son workflows ligeros que ejecutan una sola operación cada uno, simples por diseño: la lógica de decisión vive en el router.

hacerPedido: Pedidos Urgentes

Cuando el sub-agente de presupuestos detecta que no hay stock de la pieza, el router invoca hacerPedido. El workflow crea un registro en la tabla "Pedidos" de Airtable con todos los datos necesarios para que el equipo gestione el pedido al proveedor.

Webhook → Airtable Create (tabla Pedidos) → Respond to Webhook

Calculadora de Descuentos

Lógica pura de negocio, cero LLM. Cuando el cliente necesita varias reparaciones (ej: pantalla + batería + cámara), el router envía un array de precios y la calculadora aplica descuentos escalonados automáticamente.

Webhook → Code (lógica de descuentos) → Response

const precios = item.json.body.precios;

// Validaciones básicas
if (!Array.isArray(precios) || precios.length < 2) {
    throw new Error('Debes enviar un array "precios" con al menos 2 números.');
}

// 1) Ordenamos de mayor a menor
const ordenados = [...precios].sort((a, b) => b - a);

// 2) Calculamos descuento por posición (el primero no tiene)
const descuentos = ordenados.map((precio, idx) => {
    if (idx === 0) return 0;        // sin descuento para el más caro
    if (precio <= 50)  return 15;
    if (precio <= 100) return 20;
    return 25;                      // >100 €
});

// 3) Totales
const totalSinDescuento = ordenados.reduce((s, p) => s + p, 0);
const descuentoTotal    = descuentos.reduce((s, d) => s + d, 0);
const totalConDescuento = totalSinDescuento - descuentoTotal;

// 4) Preparar respuesta
const resumen =
    `Presupuesto total sin descuento: ${totalSinDescuento.toFixed(2)} €
Descuento aplicado: ${descuentoTotal.toFixed(2)} €
Presupuesto reparándolo todo junto: ${totalConDescuento.toFixed(2)} €`;

HITL Handoff: Escalada a Humano

La válvula de escape del sistema. Cuando Jacobo detecta que no puede resolver (cliente frustrado, caso complejo, petición fuera de scope), escala a un humano vía Slack con contexto completo.

Webhook → Slack (#chat) → Respond to Webhook

Cuando Jacobo escala a humano, llega un mensaje al canal #chat de Slack con el contexto completo de la conversación

Edge cases reales: petición absurda, pedido masivo rechazado, escalada por frustración y respuesta ante emergencia falsa con redirección al 112

EnviarMensajeWati: Cross-Channel

El puente entre canales. Cuando el cliente habla por teléfono con Jacobo (ElevenLabs), este workflow envía enlaces y confirmaciones por WhatsApp en paralelo. El cliente recibe la info por escrito mientras sigue hablando.

Webhook → HTTP Request (API WATI) → Respond to Webhook

Resultados#

Métricas de producción tras 6 meses operando (los workflows son descargables al final para verificar la arquitectura):

Antes vs Después

Benchmark de industria: los contact centers enterprise promedian un 20-30% de resolución por IA. Los asistentes virtuales más avanzados alcanzan un 15%. Jacobo logró ~90% en un dominio especializado. La diferencia: sub-agentes con acceso a datos en tiempo real vs chatbots genéricos.

Decisiones Técnicas (ADRs)#

Cada decisión técnica tiene un porqué. Estas son las más importantes:

Evolución de la Plataforma#

Jacobo no fue una ocurrencia. Fue la consecuencia inevitable de 5 años construyendo un Business OS robusto debajo.

Los primeros momentos de vida de Jacobo: pruebas de endpoints, iteración del copy de fidelización y el template CRM final

Lecciones Aprendidas#

Qué Haría Diferente#

Jacobo funcionó en producción durante meses, pero con perspectiva hay decisiones que cambiaría:

Patrones Transferibles a Enterprise#

Jacobo se construyó para una PYME, pero los patrones de arquitectura son enterprise-grade. Esto es lo que construí vs. lo que añadiría a escala enterprise:

Aplicabilidad por industria

Pruébalo Tú Mismo#

Estos son los workflows reales que corren en producción desde hace 2 años. Sanitizados, documentados, listos para importar en n8n. Si construyes algo con ellos, me encantaría verlo.

Todos los workflows están en GitHub: haz fork, dale star, o descarga directamente.

Cómo importar en n8n

Preguntas Frecuentes#

Recursos#

• n8n · Workflow Automation
• OpenRouter · Model Gateway
• ElevenLabs · Conversational AI
• WATI · WhatsApp Business API
• Aircall · Cloud PBX
• Airtable · Database Platform