Cada sistema que he construido empezó con un número que el negocio quería mover: tickets al día, leads al mes, sitios al mes, minutos hasta la primera respuesta. La arquitectura sigue al número, no al revés.

Prompt, retrieval, orquestación, integraciones, servidores, seguridad, documentación. Si corre en producción, es mío hasta que está monitorizado, probado y entregado con los documentos que necesita la siguiente persona.

Evaluaciones en Langfuse sobre retrieval y respuestas, CSAT, una comparación de cada nueva versión del flujo con la anterior antes del release y un ciclo semanal de mejora sobre las conversaciones reales. Un score de RAG que pasó de menos de 0,6 a 0,9 es el tipo de prueba que busco.

Antes de construir, miro el mejor producto de la categoría, Intercom para el widget de soporte, Zendesk para el CRM, y escribo qué significa superarlo para este cliente. Después los bloques, los hitos y los tests de QA siguen esa lista.

Unos 50 agentes de soporte gestionaban a mano alrededor de 4.000 tickets al día, con picos de más de cien conversaciones en cinco a diez minutos. Bajo sobrecarga, la primera respuesta tardaba hasta 18 minutos y la satisfacción del cliente estaba en 2,5 sobre 5. Cada ticket, incluidos los triviales, costaba tiempo humano, y el conocimiento necesario para responder estaba disperso entre el CRM y años de historial de mensajes. El encargo: un widget que responda la mayoría de los tickets por sí solo, en el idioma del cliente, y deje a las personas solo los casos que requieren criterio. El benchmark que fijé antes de construir fue Intercom.

Un widget de chat en el sitio del cliente, desplegado mediante Google Tag Manager, que entiende la solicitud en cualquier idioma, consulta la cuenta del cliente cuando ha iniciado sesión, responde desde una base de conocimiento construida sobre el propio CRM y el historial de mensajes del cliente, y pasa los casos complejos a una persona en Zendesk con la transcripción completa y el contexto de la cuenta adjuntos. n8n orquesta los flujos principal, de escalado y de reporting; LangGraph ejecuta la lógica cíclica por intención, de modo que el grafo decide paso a paso si responder, preguntar, verificar o escalar. Cada agente tiene su propio prompt, GPT-4o mini como modelo principal y Gemini 2.5 a través de OpenRouter como fallback. Pinecone aloja la base de conocimiento, MongoDB la memoria compartida, Redis la caché. Configuré y endurecí los servidores yo mismo: todo corre en Docker sobre la infraestructura propia del proyecto, con monitorización en los servidores y en cada nodo de n8n para que los bugs salgan a la luz antes de que el negocio los note.

• Un prompt, un modelo principal y un modelo de fallback por agente. El propio widget tiene una versión de respaldo para cuando la ruta de IA está caída.
• GPT-4o mini por coste y latencia: respuesta media ~3 s, conversaciones largas limitadas a unos 7 s, pico de 9 s.
• La memoria compartida en MongoDB alimenta un ciclo semanal de mejora sobre tráfico real: calidad de las respuestas, prompts, CSAT, seguridad del LLM.
• Cada nueva versión de un flujo se compara con la anterior antes del release, nodo por nodo, para detectar los cambios de comportamiento antes de que los vean los clientes.
• Visión y OCR: un cliente envía una foto, por ejemplo un recibo; los datos se extraen, se guardan en MongoDB y los usan los agentes.

• Servidores construidos y endurecidos desde cero; la ruta de datos entre orquestador, servidor y navegador está protegida de extremo a extremo.
• Tests de penetración ejecutados con agentes que construí con reglas basadas en el modelo de permisos, tests grey-box sobre API, latencia y puntos de entrada de la infraestructura, revisión del equipo interno de seguridad y un test black-box de una empresa externa. Cada hallazgo corregido por mí.
• Defensa contra prompt injection y control de lo que llega al modelo; los datos sensibles nunca salen del perímetro sin un motivo.

• Proyecto en solitario, más de seis meses hasta el release, dividido en bloques: cada bloque entregado con su propio QA, monitorización y documentación.
• Todas las automatizaciones versionadas en GitHub con pipelines de CI/CD.
• Entregables finales: documentación de la API, un playbook para el equipo de atención al cliente y el documento técnico del proyecto.

El equipo de soporte de 50 personas no fue recortado. Se formó en el nuevo flujo y en parte se ofreció a otras empresas como servicio, de modo que el negocio convirtió un centro de coste en una nueva línea de ingresos.

Migración a Qwen 3 de Hugging Face con Qdrant, construida con los equipos de ML y DevOps, por privacidad, latencia, control y la opción de mejorar el modelo. El modelo local actúa además como filtro de los datos que se envían a LLMs externos. Fine-tuning en preparación; después el mismo modelo servirá a los equipos internos y al propio widget.

Las marcas necesitaban decenas de sitios web cada mes para crecer en presencia y enviar tráfico a la página principal: sitios satélite alrededor de una o dos marcas, cada uno lo bastante específico para ser indexado y leído. No había un equipo de contenidos que los investigara, escribiera, diseñara, ilustrara y construyera, y cada sitio tenía que ser lo bastante específico para indexarse y lo bastante barato para hacer decenas al mes.

Un pipeline de agentes Hermes, autoalojados en el servidor de la empresa, con un agente dedicado a la investigación, uno al scraping y la composición, uno al diseño y un script final que publica. Dos vías de entrada. Desde una URL de ejemplo: los agentes investigan y hacen scraping de un sitio similar y componen uno nuevo inspirado en él. Desde cero: la solicitud entra por MCP desde Claude Code o Codex, la investigación corre en Perplexity y la Anthropic API, el sistema hace scraping de lo que pidió el operador, después realiza una breve entrevista para recoger los datos que solo un humano conoce y construye el sitio. GPT-6 Astra genera las imágenes. Un clic clona un sitio con un diseño ligeramente distinto, o completamente diferente. Una base de datos de cada ejecución crece con el uso y mejora el segundo modo con el tiempo. La salida es HTML estático, exportado y desplegado en los servidores del cliente mediante el script de DevOps.

Las plantillas dan el mismo sitio cada vez, y los buscadores lo saben. Los agentes investigan el tema, entrevistan al operador y escriben para ese tema, así que cada sitio es específico, legible e indexable. El coste se mantiene cerca de los cinco euros porque los pasos caros, investigación e imágenes, se cachean en la base de datos de ejecuciones y se reutilizan.

• Investigación de keywords y asignación keyword-página; title tags y meta descriptions; jerarquía H1, H2, H3.
• URLs limpias, etiquetas canonical, sitemap.xml, robots.txt; enlazado interno.
• Texto alternativo e imágenes ligeras y optimizadas para el rastreo; Core Web Vitals; mobile first.
• Datos estructurados en JSON-LD de schema.org; Open Graph.
• GEO, Generative Engine Optimization: secciones de FAQ y llms.txt para que los buscadores de IA puedan leer y citar el sitio; hreflang para sitios multilingües.

Alrededor de cien sitios al mes, de cinco a diez minutos cada uno, unos cinco euros por sitio. Los sitios son satélites de una o dos marcas y envían tráfico a la página principal de la marca; el tráfico se mide a nivel de marca.

Soporte, ventas y dirección trabajaban en herramientas separadas y veían al mismo cliente desde ángulos distintos. Los eventos de negocio, señales de fraude, pagos y reembolsos, cuentas bloqueadas, actividad de afiliados e influencers, llegaban tarde a las personas, en informes, en lugar de en el momento en que ocurrían. El encargo: una plataforma para los tres equipos, con Zendesk como benchmark a superar, construida en los servidores propios de la empresa.

Una plataforma para soporte, ventas y dirección: los mismos clientes, alertas en tiempo real, voz, SMS y Telegram desde una sola pantalla, una base de conocimiento al estilo de Notion integrada en el producto, analítica en AWS y Tableau, y una capa de IA que enruta las solicitudes y responde desde la base de conocimiento. Arquitectura definida junto con DevOps, el departamento de desarrollo y el PM y el Quality Manager del cliente; microservicios en Kubernetes sobre servidores de la empresa, un servicio por motor, front end íntegramente en TypeScript con partes en Java. Lidero a tres ingenieros de IA: sprints de dos semanas con una reserva de unas diez horas para correcciones urgentes, test de QA al final de cada hito contra el benchmark, mejoras en asíncrono, gestión de bloqueos, resolución diaria de problemas con Atención al Cliente, el Quality Manager y el responsable de QA.

• Backend y front end.
• Gestión de accesos: roles y permisos.
• Espacio de trabajo para los operadores de soporte.
• Analítica conectada a AWS y un espacio de trabajo en Tableau.
• Alertas de negocio integradas en el CRM a partir de los datos de los departamentos en AWS.
• Alertas en tiempo real sobre Kafka, construidas con un ingeniero de ML.
• Base de conocimiento integrada, voz y SMS a través de Voiso, Telegram para la comunicación con los clientes.

Bloques con hitos; un test de QA al final de cada hito y una comparación con el benchmark; mejoras gestionadas en asíncrono; bloqueos eliminados a diario. Sprints de dos semanas por ingeniero, mentalidad Agile y una pequeña reserva en cada sprint para lo que se rompe.

Un agente con enrutamiento inteligente, una base de conocimiento con búsqueda semántica y una extensión de navegador del agente que ejecuta tareas rutinarias para los operadores. El CRM sirve a atención al cliente, dirección y ventas, así que el mismo agente trabaja sobre solicitudes de soporte y sobre la generación de leads.

Un LLM on-premise (Qwen 3) con acceso completo a los datos del CRM y a la plataforma interna de datos de cliente; un agente con su propia base de conocimiento que ayuda a soporte a responder más rápido; la extensión de navegador con la que soporte define acciones que se ejecutan automáticamente para el cliente.

Los empleados hacían a RR. HH., Finanzas y Legal las mismas preguntas rutinarias cada día: días de vacaciones, límites de gastos, qué plantilla usar. Cada respuesta quitaba tiempo a quien tenía que darla, y el conocimiento vivía en documentos que nadie abría. En el sitio web de la empresa, los visitantes no tenían autoservicio ni una forma sencilla de dejar una solicitud. La empresa ya vivía en Microsoft 365, así que la respuesta tenía que vivir allí también.

Un asistente por departamento, en el canal de Teams donde la gente ya trabaja. El agente de RR. HH. contiene todo el conocimiento compartido de RR. HH., responde a las preguntas frecuentes y registra todo; Finanzas y Legal siguen la misma lógica. Agentes construidos en Microsoft Copilot Studio, anclados en documentos de SharePoint, con Azure OpenAI para los modelos y Databricks para logs, compartición de datos y mejora continua. El mismo stack impulsa un asistente en el sitio web de la empresa: información general, conectado directamente a SharePoint y Databricks, con un paso de lead que pide al visitante enviar la solicitud por email cuando la conversación muestra intención. Construido justo después del widget de soporte, en solitario, para un stakeholder interno de Acrh Software.

El cliente ya vivía en Microsoft 365: Teams, SharePoint, Azure. Construir donde la gente ya está eliminó la fricción de adopción; nadie tuvo que aprender una herramienta nueva. Anclar las respuestas en SharePoint mantiene cada una con fuente y auditable, y Databricks guarda los logs que alimentan el ciclo de mejora.

• RR. HH.: vacaciones, políticas, preguntas de onboarding, con todo el conocimiento compartido de RR. HH. detrás.
• Finanzas: reglas de gastos, límites, procedimientos.
• Legal: plantillas, versiones, cuándo una cláusula necesita revisión humana.
• Cada conversación registrada, para que los departamentos vean qué pregunta la gente realmente y corrijan los documentos, no solo las respuestas.

El asistente responde primero y pide la solicitud por email solo cuando el visitante muestra intención de compra. Los leads llegan a ventas con la conversación adjunta, así que la primera respuesta humana ya conoce el contexto.

Los leads llegaban por email y se leían tarde. Cinco gestores comerciales pasaban el día en cualificación rutinaria, copiando nombres y teléfonos, y perdían compradores que ya se habían ido a la siguiente agencia. El cliente quería una innovación visible en el sitio web y, sobre todo, leads que llegaran limpios y se atendieran de inmediato.

Un widget conversacional integrado en el sitio del cliente con toda la información de los inmuebles y edificios en venta. El código y el prompt del bot viven en Replit, OpenAI es el modelo, la conversación está diseñada en Voiceflow, Airtable es el CRM, Make ejecuta las automatizaciones. El widget recoge nombre, teléfono y email del comprador, el campo clave. Flujo uno: en el momento en que se guarda un lead, el gestor recibe una notificación de Telegram con el lead. Flujo dos: el comprador recibe un email personalizado con la disponibilidad que encaja con su búsqueda y un botón para reservar una cita. Flujo tres: el clic abre una solicitud en el Google Calendar y Meet del gestor, el gestor acepta, el comprador recibe la confirmación. Los mensajes proactivos se disparan cuando el visitante hace clic en botones clave, lo que subió los leads otros cinco puntos.

El email era el campo clave: el seguimiento con inmuebles que encajaban hacía la venta mientras el gestor estaba ocupado. Los mensajes proactivos en clics clave, calculadora de hipoteca, plano, añadieron cinco puntos de leads por sí solos. Y los gestores dejaron de copiar datos a mano, porque llegaban ya estructurados.

• Automatizaciones de contenido y publicación automática en Facebook, Instagram, VK y X mediante Make, para la agencia y para clientes.
• Toda la forma de trabajar de la agencia reconstruida en ClickUp mientras el equipo crecía de 50 a 200 personas: integraciones de RR. HH. con onboarding y offboarding automáticos, analítica del CRM del cliente dentro de ClickUp, conversaciones estructuradas con roles y permisos, un gestor de tareas y una plataforma a medida de agenda y reuniones.
• Más de 20 sitios web de clientes construidos de principio a fin en JavaScript, Next.js y Astro, con conexiones por API al CRM, desplegados en los servidores de los clientes.

Los clientes necesitaban responder a sus clientes a cualquier hora y cualificar cada contacto sin contratar personal. Las conversaciones se disparaban con cada campaña publicitaria, y un mensaje perdido era un cliente perdido. Era el desarrollo más solicitado de la agencia, y cada cliente tenía un stakeholder distinto, un canal distinto y una definición distinta de buen lead.

Un bot que arranca con una palabra clave en WhatsApp, Instagram o Telegram, ejecuta un flujo definido con un LLM dentro, cualifica el contacto con un prompt preciso escrito para ese cliente y lo archiva en un CRM a medida construido en Google Apps Script, donde el lead pasa de frío a tibio a caliente según los pasos completados. Los bots servían tanto para atención al cliente, hablando directamente con el usuario final, como de apoyo al propio equipo del cliente. Desde 2022 los mismos clientes recibieron agentes de voz: una recepcionista de voz y un agente de RR. HH. que recoge datos de candidatos, construidos sobre Twilio y ElevenLabs; agentes salientes en Vapi y Retell que llaman a los leads de las listas del cliente y hacen las preguntas de cualificación. Orquestación en Make y n8n con código a medida; modelos de OpenAI, Anthropic y OpenRouter.

• Un prompt por cliente, con los criterios de cualificación escritos como preguntas explícitas, nunca dejados al criterio del modelo.
• Las etapas del pipeline cambian solo con pasos completados: un lead no puede pasar a caliente sin datos de contacto.
• Cada bot funciona 24/7; cuando una campaña se dispara, las conversaciones crecen sin que ningún canal quede sin cubrir.

• Recepcionista de voz en Twilio y ElevenLabs: responde, deriva, toma el mensaje.
• Agente de voz de RR. HH.: recoge datos de candidatos en una conversación que sigue el prompt.
• Agentes salientes en Vapi y Retell: llaman a los leads, hacen las preguntas de cualificación y pasan el resultado al CRM.
• Un agente de Ventas y un agente de Finanzas que procesa datos internos, sobre la misma orquestación.

Grupo automovilístico en Roma, más de 1.000 empleados, una flota de unos 200.000 vehículos. Cuadros de mando de KPI en Power BI construidos sobre SQL, extracciones de AWS y APIs internas con el departamento de IT, para todo el departamento comercial y para la dirección, con alertas. Stock inmovilizado reducido un 25% porque los datos se movían más rápido y los vehículos usados se vendían antes. Control de KPI y facturas de un proveedor de dos a tres millones de euros al año. Cuatro analistas nuevos incorporados y formados.