Ya no basta con anunciar un modelo más potente que el anterior o con conseguir una puntuación superior en un benchmark concreto.

A medida que estas herramientas se incorporan al desarrollo de software, la automatización, el análisis de información y los procesos empresariales, la pregunta realmente importante empieza a ser otra: ¿qué modelo funciona mejor para cada tipo de trabajo?
La comparativa entre ChatGPT 5.6 y Fable 5 refleja precisamente esta evolución. No hay un ganador absoluto, sino dos modelos con fortalezas diferentes.

Mientras Fable 5 destaca especialmente en razonamiento profundo, análisis y resolución de problemas complejos de programación, ChatGPT 5.6 apuesta por una mayor eficiencia, un mejor rendimiento en escenarios agénticos y una clara ventaja en coste y capacidades multimodales.

La elección, por tanto, depende cada vez menos de cuál es “el modelo más inteligente” y más de qué tipo de inteligencia necesita realmente cada organización o cada usuario.

ChatGPT 5.6: más inteligencia por token

Uno de los principales argumentos de la nueva generación de ChatGPT 5.6 es la búsqueda de una mayor eficiencia. La propuesta no consiste únicamente en ofrecer un modelo más potente, sino en conseguir más capacidad de razonamiento utilizando menos tokens y, por tanto, reduciendo el coste asociado a las tareas complejas.

Esta cuestión es especialmente relevante en entornos empresariales. El precio por token no siempre refleja el coste real de utilizar un modelo. Un sistema aparentemente barato puede terminar siendo más caro si necesita consumir una enorme cantidad de tokens para completar una tarea. Por eso, la eficiencia debe medirse teniendo en cuenta el coste total de resolver un problema, y no únicamente el precio unitario de cada token.

ChatGPT 5.6 se presenta además en diferentes niveles de capacidad (Sol, Terra y Luna), lo que permite ajustar el modelo a las necesidades concretas de cada tarea. La idea es sencilla: no utilizar siempre la máxima capacidad de razonamiento cuando el problema no lo requiere.

A esta estrategia se suma la posibilidad de configurar diferentes niveles de intensidad y un modo Ultra capaz de combinar múltiples agentes trabajando en paralelo. Esta orientación refuerza una de las principales apuestas de la nueva generación de modelos: pasar de responder preguntas a ejecutar tareas complejas mediante flujos de trabajo cada vez más autónomos.

En este sentido, el valor de ChatGPT 5.6 no está únicamente en su capacidad para generar una buena respuesta, también en su potencial para integrarse en procesos en los que intervienen herramientas externas, terminales, búsquedas y diferentes pasos de ejecución.

Fable 5: cuando el contexto y el razonamiento marcan la diferencia

Si ChatGPT 5.6 apuesta especialmente por la eficiencia y la capacidad agéntica, Fable 5 parece encontrar su principal fortaleza en otro terreno: la comprensión profunda del contexto y la resolución de problemas complejos.

La sensación de uso es, en muchos casos, la de estar trabajando con un modelo que entiende especialmente bien grandes cantidades de información y es capaz de mantener una visión global del problema. Esto resulta particularmente relevante en tareas de análisis, razonamiento prolongado y desarrollo de software sobre bases de código grandes.

La diferencia se hace especialmente visible cuando el trabajo requiere algo más que generar código que “parece correcto”. En proyectos reales, donde existen dependencias entre módulos, código heredado, restricciones técnicas y errores difíciles de reproducir, la capacidad de comprender el contexto completo puede marcar una diferencia importante.

Es precisamente en este tipo de escenarios donde Fable 5 consigue una ventaja significativa frente a ChatGPT 5.6.

Los benchmarks cuentan una historia diferente según el problema

Comparar modelos de inteligencia artificial únicamente a partir de benchmarks puede resultar engañoso. La razón es sencilla: el ganador cambia dependiendo del tipo de tarea que se esté midiendo.

En inteligencia general, ambos modelos se encuentran en una posición muy cercana. Diferencias pequeñas en una prueba concreta pueden estar dentro del margen de variabilidad y no necesariamente representan una superioridad clara de un modelo sobre otro.

Sin embargo, cuando se analizan capacidades específicas aparecen diferencias mucho más interesantes.

Uno de los terrenos donde ChatGPT 5.6 destaca especialmente es ARC-AGI 3, un benchmark diseñado para evaluar la capacidad de los modelos para enfrentarse a problemas nuevos y situaciones que no han encontrado previamente.

En este escenario, ChatGPT 5.6 Sol alcanza un 7,8 % de aciertos y establece un nuevo estado del arte, mostrando una capacidad especialmente destacada para orientarse ante problemas desconocidos.

La situación cambia radicalmente cuando se analiza la resolución de bugs reales en proyectos de software. En SWE-bench Pro, Fable 5 alcanza un 80% frente al 64,6% de ChatGPT 5.6.

La diferencia es considerable y apunta a una fortaleza concreta del modelo de Anthropic: su capacidad para enfrentarse a problemas complejos de ingeniería de software en contextos reales.

Esto demuestra por qué conviene mirar los benchmarks con perspectiva. No existe un único indicador capaz de definir qué modelo es mejor para todas las situaciones. Un modelo puede destacar en razonamiento abstracto y otro ofrecer mejores resultados en ingeniería de software, mientras un tercero puede ser más eficiente en tareas multimodales.

La pregunta correcta no es “¿qué modelo ha ganado?”, sino “¿qué modelo gana en la tarea que necesito resolver?”.

El coste: la ventaja silenciosa de ChatGPT 5.6

Hay un aspecto que quizá tenga menos impacto en los titulares, pero que puede ser decisivo cuando hablamos de uso empresarial: el coste.

Según las notas analizadas, ChatGPT 5.6 presenta una estructura de precios de aproximadamente 5 dólares por millón de tokens de entrada y 30 dólares por millón de tokens de salida, frente a los 10 y 50 dólares, respectivamente, de Fable 5.

Pero la diferencia más interesante no está únicamente en el precio por token. La eficiencia del modelo hace que, en determinadas tareas, el coste total por trabajo completado pueda situarse alrededor de un tercio del de su competidor.

Este factor cambia completamente la conversación cuando pasamos de experimentar con IA a desplegarla a escala.

Para un perfil de desarrollo que utiliza un modelo ocasionalmente, la diferencia de precio puede no ser determinante. Para una compañía que ejecuta miles o millones de tareas automatizadas, utiliza agentes de forma continua o integra modelos dentro de sus productos, la eficiencia económica puede convertirse en una de las principales ventajas competitivas.

En esta situación, disponer de diferentes niveles de capacidad también permite optimizar el consumo. Las tareas sencillas pueden resolverse con modelos más ligeros, reservando Sol para aquellos problemas que realmente requieren una mayor capacidad de razonamiento.

¿Cuál elegir?

La respuesta depende del tipo de trabajo.

Fable 5 parece la opción más adecuada cuando el objetivo principal es trabajar con código complejo, resolver bugs reales en bases de código grandes o realizar análisis que requieren razonamiento profundo y una comprensión prolongada del contexto.

También puede ser una buena elección cuando el coste no es la principal restricción y se prioriza el margen adicional de calidad en tareas complejas.

Por su parte, ChatGPT 5.6 resulta especialmente atractivo para escenarios agénticos, automatizaciones, integración con herramientas externas y tareas multimodales. Su estructura de costes lo convierte además en una opción especialmente interesante cuando existe un volumen elevado de operaciones y la factura final es un factor importante.

También ofrece una ventaja práctica al permitir utilizar diferentes niveles de capacidad según la complejidad de cada tarea. En un entorno empresarial, esta flexibilidad puede facilitar una estrategia de optimización de costes sin renunciar a utilizar modelos más potentes cuando realmente son necesarios.

Una de las conclusiones más interesantes de esta comparativa es que la estrategia más inteligente no tiene por qué consistir en elegir un único modelo para todo.

En una empresa pueden coexistir diferentes necesidades. Un equipo de desarrollo puede necesitar Fable 5 para trabajar sobre una base de código compleja, mientras que otros departamentos pueden utilizar ChatGPT 5.6 para automatizaciones, análisis visuales o procesos agénticos.

Incluso dentro de un mismo flujo de trabajo puede tener sentido utilizar diferentes modelos en función de la tarea. El verdadero reto no será decidir qué modelo gana, sino construir una arquitectura de IA capaz de seleccionar el modelo adecuado para cada problema.

Esto nos lleva hacia un escenario en el que los modelos dejan de competir únicamente por ser “el mejor” y empiezan a competir por ser el más adecuado para cada contexto.

Una carrera que cada vez parece más cosa de dos

La evolución de los últimos meses apunta además a una tendencia evidente. El debate sobre los modelos de frontera parece concentrarse cada vez más alrededor de dos grandes actores: OpenAI y Anthropic.

Mientras otros competidores siguen avanzando y ofreciendo propuestas interesantes, la distancia en capacidades de razonamiento, programación y uso agéntico parece haberse reducido a una disputa cada vez más directa entre estos dos laboratorios.

Y quizá la clave esté precisamente ahí. La carrera ya no consiste únicamente en conseguir un modelo capaz de responder mejor que el anterior. Ahora se trata de construir sistemas que razonen, utilicen herramientas, comprendan grandes volúmenes de contexto, ejecuten tareas y lo hagan de forma económicamente sostenible.

La comparativa entre ChatGPT 5.6 y Fable 5 es un buen ejemplo de este cambio de paradigma. Fable 5 parece tener ventaja cuando la prioridad es la profundidad y la complejidad; ChatGPT 5.6 cuando importan la eficiencia, la velocidad, la multimodalidad y la capacidad de operar como agente.

Por eso, más que buscar un ganador absoluto, conviene entender qué necesita cada proyecto. Porque en la nueva generación de inteligencia artificial, la pregunta ya no es qué modelo es mejor, sino qué modelo es mejor para cada trabajo.

Cada vez es más habitual encontrar sistemas de IA en asistentes virtuales, chatbots de atención al cliente, herramientas de generación de contenido, cámaras inteligentes, robots autónomos o aplicaciones capaces de analizar enormes cantidades de información en cuestión de segundos.

Sin embargo, aunque estos avances son impresionantes, existe una realidad que a menudo pasa desapercibida: la inteligencia artificial también se equivoca, y algunas de esas equivocaciones pueden llegar a ser tan sorprendentes como divertidas.

En este episodio analizamos cuatro casos reales que se hicieron virales en todo el mundo y que demuestran que la IA, por muy avanzada que sea, sigue teniendo importantes limitaciones.

El chatbot que casi vende un coche por un dólar

Uno de los casos más conocidos fue el de un concesionario de automóviles que incorporó un chatbot basado en inteligencia artificial para responder automáticamente a las consultas de los clientes.

Lo que parecía una excelente forma de mejorar la atención terminó convirtiéndose en un problema cuando un usuario consiguió manipular las respuestas del sistema mediante instrucciones cuidadosamente redactadas.

El resultado fue una conversación que parecía cerrar la venta de un vehículo valorado en decenas de miles de dólares por un precio irrisorio. Aunque la operación nunca llegó a realizarse, esta historia dejó claro que los modelos de lenguaje necesitan controles, supervisión y una configuración adecuada para evitar respuestas incoherentes.

Un abogado, ChatGPT y sentencias que nunca existieron

Otro ejemplo muy llamativo tuvo lugar en el ámbito legal. Un abogado decidió utilizar ChatGPT como apoyo para preparar la documentación de un juicio y terminó presentando referencias a sentencias que nunca habían existido.

El sistema había generado información falsa con apariencia completamente real, un fenómeno conocido como "alucinación" en inteligencia artificial.

Este incidente puso de manifiesto la importancia de verificar siempre cualquier dato generado por una IA, especialmente cuando se utiliza en contextos profesionales donde la precisión resulta imprescindible.

El algoritmo que siguió al árbitro en vez del partido

El deporte tampoco ha escapado a este tipo de errores tecnológicos. Durante un partido de fútbol retransmitido mediante un sistema de cámaras automatizadas con visión artificial, el algoritmo confundió repetidamente la cabeza calva de un juez de línea con el balón.

Como consecuencia, la retransmisión dejó de seguir el juego para enfocar al árbitro durante buena parte del encuentro.

Aunque esta anécdota provocó miles de comentarios en redes sociales, también sirvió para explicar cómo funcionan los sistemas de visión por computadora, que identifican patrones visuales pero carecen del contexto y del sentido común que posee una persona.

El robot de reparto: entrega completada, contexto ignorado

La última historia de este episodio tiene como protagonista a un robot autónomo de reparto.

Mientras seguía la ruta programada para entregar un pedido, atravesó sin detenerse el perímetro de una escena policial acordonada.

El robot no entendía el significado de las cintas de seguridad ni era capaz de interpretar la gravedad de la situación. Simplemente continuó siguiendo las instrucciones de navegación para completar su recorrido.

Este ejemplo demuestra que una máquina puede cumplir perfectamente una tarea concreta y, al mismo tiempo, ser incapaz de comprender el contexto que la rodea.

Cuatro errores, una misma lección

Todos estas historias comparten una misma conclusión: la inteligencia artificial no piensa como un ser humano.

Analiza patrones, procesa datos y genera respuestas basándose en probabilidades, pero no comprende realmente el significado de aquello que hace.

Carece de intuición, experiencia, criterio propio y sentido común, por lo que siempre necesita supervisión humana cuando sus decisiones pueden tener consecuencias importantes.

Con la entrada en vigor de normativas como la CSRD y la urgencia de cumplir con los criterios ESG, la sostenibilidad ha dejado de ser una declaración de intenciones corporativa para convertirse en un requisito de arquitectura y testing.

En este recopilatorio nos adentramos en el Green QA, analizamos las cinco capas de su framework de implantación y desgranamos los KPIs fundamentales para detectar fugas energéticas en la infraestructura cloud.

Además, compartimos pautas para transicionar hacia un modelo de testing contextual que elimine por completo el desperdicio digital en los pipelines de CI/CD.

¡Arrancamos!

¿Qué es Green QA? La calidad que respira

El Green Quality Assurance redefine las pruebas y el control de calidad para reducir el consumo energético y la huella de carbono del software sin perder rigurosidad. Este enfoque conecta la ingeniería de calidad con los criterios ESG y la normativa europea CSRD, midiendo el impacto técnico directo en vatios y emisiones de CO2. Implica optimizar las suites automatizadas, mitigar el tráfico ineficiente en peticiones de API y auditar la infraestructura cloud. Una práctica necesaria para alinear el desarrollo de software con los objetivos de sostenibilidad actuales.

El framework de Green QA, la calidad que respira

Implementar Green QA requiere una estructura metodológica clara. En este post podrás ver las 5 capas esenciales de su framework (gobernanza, procesos, datos, tecnología y mejora continua) y propone un modelo de madurez inspirado en TMMi. El enfoque define responsabilidades compartidas entre los equipos de desarrollo y cumplimiento, e introduce herramientas como Scaphandre para metrología energética o plugins específicos en SonarQube para análisis estático de código. Una guía práctica para automatizar el control de la huella de carbono dentro de los pipelines de CI/CD.

Métricas en Green QA, la calidad que respira

Este post es el último de la serie de Green QA y se centra en la medición mediante KPIs y OKRs para identificar fugas energéticas y desperdicio digital. Las métricas se agrupan en eficiencia técnica (intensidad energética y ciclos de CPU), impacto planetario (huella de carbono por release), cumplimiento ESG y optimización operativa (eliminación de tests zombis y datasets redundantes). Te contamos los mecanismos para auditar estos datos bajo normativas como CSRD, GHG Protocol e ISO 21031, asegurando que cada métrica se corresponda con evidencias técnicas verificables.

Bonus: un podcast para ponerte al día en Green QA en pocos minutos

Si prefieres actualizarte en formato audio, te proponemos este episodio de nuestro podcast "Apasionados por la tecnología". Debatimos los retos de implantar Green QA, su impacto en la estrategia ESG de la compañía y las claves para eliminar el desperdicio digital en tus pipelines.

El punto de partida es una pregunta incómoda: si mañana tuvieras carta blanca para rediseñar tu plataforma con criterios ambientales, sociales y de gobernanza como condición, ¿seguirías tomando las mismas decisiones que hoy? A partir de ahí, construimos un mapa de ocho decisiones tecnológicas clave donde esa integración es posible y necesaria.

¿La conclusión? Decidir tecnología es decidir el futuro. Las plataformas con propósito no son más caras ni más lentas, son más competitivas, y las organizaciones que lo entiendan antes tendrán una ventaja difícil de replicar.

Plataformas tecnológicas con propósito: integrando criterios ESG desde el diseño

¿Seguirías tomando las mismas decisiones tecnológicas si ESG fuera una condición de diseño y no un añadido? Con esa pregunta arranca esta serie. Argumentamos por qué los criterios ambientales, sociales y de gobernanza han dejado de ser un complemento de la estrategia para convertirse en su núcleo y presentamos el mapa de 8 decisiones tecnológicas clave desde el que construir plataformas con propósito real.

Plataformas tecnológicas con propósito: alineando tecnología, negocio y sostenibilidad

Profundizamos en los primeros cuatro pilares del mapa: arquitectura cloud sostenible, IA responsable, diseño inclusivo y plataformas interoperables. Cada decisión tiene impacto directo en los tres ejes ESG y, lejos de ser un coste, genera ventajas competitivas tangibles: reducción de huella de carbono, confianza regulatoria, ampliación de mercado y eliminación de silos que frenan la innovación.

Plataformas tecnológicas con propósito: gobernanza, seguridad y resiliencia digital

Cerramos el mapa con los cuatro pilares que garantizan la integridad y la continuidad del ecosistema digital: gobierno del dato y trazabilidad, ciberseguridad y resiliencia, integración ESG en la cadena de suministro y optimización del ciclo de vida del software. Porque una plataforma con propósito no solo se construye bien, también se gestiona y protege con el mismo nivel de consciencia.

De hecho, implantar IA sobre procesos ineficientes es un poco como ponerle un motor de carreras a un coche que no tiene frenos: solo acelerará el desastre.

La verdadera agilidad no consiste en coleccionar las últimas herramientas del mercado, sino en diseñar un sistema donde las personas trabajen a gusto y el valor fluya sin atascarse en silos jerárquicos.

En este recopilatorio dejamos a un lado la teoría abstracta y vemos las principales claves sobre transformación y cultura de ingeniería:

• Deuda organizacional: cómo identificar y limpiar esas ineficiencias internas que queman a tu equipo mucho más que la deuda técnica.
• Extreme Programming (XP) al rescate: por qué las prácticas de ingeniería de los 90 son hoy el mejor escudo frente al burnout en la era de la IA.
• La operativa real: las tres barreras invisibles que hacen que tus mejores planes estratégicos se rompan al chocar con el día a día.
• El "Sprint Cero": una defensa firme de por qué parar a pensar un poco al principio te ahorra meses de parches y dramas en el futuro.

¿Empezamos? 👇

La IA no resolverá tus problemas organizativos

La IA no soluciona las taras de una empresa, funciona como un espejo que las amplifica. Implantar herramientas de IA sobre silos de información, desalineamiento de objetivos o falta de foco estratégico no arregla los flujos internos, solo hace más evidente la lentitud burocrática. La IA es un acelerador potente, pero necesita que el sistema organizativo y la cultura corporativa estén preparados para adoptarla. Si el terreno no es el adecuado, la tecnología solo automatizará la ineficiencia.

Por qué XP (y no la IA) es lo que evitará que tu equipo se queme

La Inteligencia Artificial promete generar código de forma instantánea, pero la velocidad desmedida puede quemar a los equipos de desarrollo. Si quieres evitar este tipo de colapsos, en este post recuperamos los principios de Extreme Programming (XP) como un mecanismo técnico de sostenibilidad humana. Prácticas clásicas como el ritmo sostenible, el Pair Programming evolucionado frente a la amenaza del incontrolable Vibe Coding, y el desarrollo guiado por pruebas (TDD) actúan como contrapesos necesarios para mitigar la ansiedad y garantizar la mantenibilidad y diseño del software en la era de la IA.

Tres barreras sistémicas que ningún excel detecta y cómo superarlas

Cuando los planes estratégicos fallan, no suele ser por falta de visión, sino por ceguera sistémica. Vemos las tres dimensiones invisibles que fracturan la ejecución en la operativa: la barrera cognitiva (el colapso por incertidumbre y falta de seguridad psicológica), la estructural (la trampa de la optimización local por incentivos de silo) y la de flujo (el valor estancado en colas de espera invisibles). Superarlo exige cambiar el control jerárquico por la arquitectura del sistema, aplicando Value Stream Management (VSM) y métricas de conducta compartidas (KBIs).

¿Qué es la deuda organizacional y por qué tu empresa necesita gestionarla hoy?

Así como medimos la deuda técnica en el software, las empresas acumulan una deuda organizacional silenciosa: procesos obsoletos, silos y roles difusos que frenan la proactividad. ¿Sabes que puedes mitigar este problema estructural aplicando patrones de la ingeniería y el movimiento Lean? Vemos cómo visibilizar la deuda en un backlog colaborativo, priorizar las acciones según su ROI en el negocio, ejecutar planes de acción pragmáticos e iterativos, y reservar una capacidad orgánica continua para su refactorización interna.

¿Qué hay que tener en cuenta antes del primer Sprint?

A pesar de que la ortodoxia de Scrum no reconoce el "Sprint Cero", la práctica demuestra que lanzarse a picar código en el Sprint 1 sin asentar las bases aboca el proyecto al fracaso. En este post te contamos el por qué de la necesidad de un periodo de descubrimiento para alinear expectativas, dimensionar riesgos, acordar las reglas del juego y estructurar una primera versión del backlog junto al cliente. Un ejercicio de mitigación temprana indispensable para forjar la confianza del equipo, diseñar un roadmap adaptativo y pensar lo justo al principio para no pagar las consecuencias después.

Hablamos de decisiones técnicas aparentemente pequeñas que tienen un impacto enorme en usuarios con dificultades motrices o en pantallas táctiles, de hacia dónde evoluciona el estándar internacional de accesibilidad y qué significa ese cambio para quienes construyen productos digitales.

Además, hay algo que muchas veces se olvida: la accesibilidad también es responsabilidad de quien escribe. Encabezados, enlaces, emojis, imágenes, todas son decisiones editoriales que marcan la diferencia para muchos usuarios y mejoran la experiencia de todo el mundo.

Target Size, el gran ignorado de la accesibilidad

Un icono de 16x16 píxeles puede parecer un detalle menor, pero para alguien con dificultades motrices o en una pantalla táctil puede ser una barrera real. En este post exploramos el criterio Target Size de las WCAG, qué tamaños mínimos exige en los niveles AA y AAA, cómo cumplirlos con padding sin alterar el diseño visual, y una extensión de navegador creada específicamente para analizar estos elementos directamente en cualquier página.

WCAG 3.0: cómo está cambiando la forma de entender la accesibilidad web

Las WCAG 3.0 siguen siendo un borrador, pero ya dejan ver un cambio profundo en la forma de evaluar la accesibilidad. Este post analiza las novedades más relevantes: el nuevo sistema de conformidad con niveles Bronce, Plata y Oro, el concepto de declaraciones de rendimiento funcional que describe limitaciones de uso en lugar de discapacidades concretas, y cómo el modelo pasa de ser binario a estar basado en la experiencia real del usuario.

Escribe mejor para todo el mundo: guía de accesibilidad para la redacción de contenidos web

La accesibilidad no empieza ni termina en el código. Quien escribe también tiene una responsabilidad. Este post recorre cinco buenas prácticas editoriales: estructurar el contenido con encabezados jerárquicos, escribir texto alternativo que transmita el mensaje y no solo describa la imagen, usar enlaces que tengan sentido por sí solos, moderar el uso de emojis que los lectores de pantalla traducen literalmente, y evitar contenido visual que pueda provocar ataques fotosensibles.

Extreme Programming lleva casi treinta años entre nosotros, discretamente eclipsado por Scrum y Kanban, pero nunca tan relevante como ahora. No porque la industria lo haya redescubierto por nostalgia, sino porque la irrupción de la IA Generativa ha puesto en evidencia exactamente el problema que XP fue diseñado para resolver: ¿cómo vas rápido sin romper el producto ni quemar al equipo?

En este recopilatorio hablamos de los fundamentos de XP y su evolución a lo que Justin Beall denomina AI-XP. La IA no hace obsoleto el marco, lo potencia. De Pair Programming a Cyborg Pairing, Planning Game y TDD como red de seguridad, hablamos de cómo XP se adapta a los tiempos de la IA.

Eso sí, el marco trae sus propias paradojas: ¿estamos volviendo a la hiper-documentación para que la IA nos entienda? ¿Se convierte la IA en el nuevo silo de conocimiento que XP siempre quiso eliminar?

AI-XP: del manifiesto del craftsmanship a la era de la IA

Kent Beck no inventó nada radicalmente nuevo cuando creó XP: recopiló lo que funcionaba y lo llevó al extremo. Tres décadas después, la IA Generativa nos plantea el mismo reto en sentido inverso: tenemos una herramienta que genera código a velocidad vertiginosa, pero sin la estructura adecuada solo acelera el caos. En este post exploramos cómo XP evoluciona hacia AI-XP con nuevos bucles de retroalimentación que integran la inteligencia artificial en la planificación, las iteraciones y la ejecución diaria, y las paradojas que ese modelo trae consigo.

La paradoja de la velocidad: por qué XP (y no la IA) es lo que evitará que tu equipo se queme

Si la IA no se cansa, ¿esperamos que nuestros equipos humanos sigan ese ritmo? En este segundo post abordamos el lado humano de la ecuación: el ritmo sostenible, la seguridad psicológica y el fin del lobo solitario que XP lleva décadas defendiendo como reglas técnicas, no como soft skills. También revisamos qué ocurre con el Pair Programming cuando entra la IA en la ecuación, por qué el Vibe Coding es una trampa y cómo el TDD se convierte, paradójicamente, en la herramienta de productividad más potente de la era artificial.

La clave de una interfaz memorable está en la fluidez de sus microinteracciones y en la precisión del feedback gráfico que recibe quien navega por la web.

En este recopilatorio nos centramos en exprimir el rendimiento de GSAP (GreenSock Animation Platform) a través de dos guías de código puramente prácticas.

Te enseñamos a estructurar un efecto de partículas en el DOM controlando variables físicas como la gravedad o la velocidad, y a implementar un cursor tracking fluido que reaccione al movimiento del ratón en tiempo real sin penalizar la carga ni la maquetación del navegador.

Prepara tu entorno de desarrollo y dale una dosis extra de reactividad y dinamismo a tus proyectos web.

Cómo usar GSAP para crear efectos de partículas en el DOM

No hace falta saturar una web con animaciones pesadas; a veces, el secreto de una buena UX está en el feedback visual de las microinteracciones. En este post te enseñamos a estructurar un efecto de partículas en el DOM utilizando GSAP y su plugin Physics2DPlugin. Vemos paso a paso cómo registrar el plugin, capturar los elementos HTML esenciales y configurar variables físicas como la gravedad, la velocidad o la cantidad de partículas. Un flujo limpio y mantenible mediante Custom Properties de CSS para transformar la respuesta visual de cualquier botón.

Cursor tracking con GSAP: dándole vida al movimiento del ratón

El movimiento del ratón es una excelente oportunidad para enriquecer la UX, y el cursor tracking con GSAP permite exprimirlo con un gran rendimiento. Te explicamos cómo implementar efectos interactivos fluidos y cursores personalizados basados en las coordenadas del puntero. En esta guía técnica vemos la captura de eventos en tiempo real, el suavizado de los movimientos y cómo evitar problemas clásicos de rendimiento al manipular el DOM en maquetaciones complejas. Una solución directa para aportar reactividad y dinamismo a la interfaz web.

Lo que nació como una forma sencilla de compartir conocimiento sobre Google Cloud se acabó convirtiendo en una comunidad increíble de más de 240.000 escuchas y en un punto de encuentro para los/as profesionales del sector.

Las buenas historias merecen un gran cierre y, aunque los micrófonos ya se han apagado, no queríamos dejarte sin un último mapa de carreteras técnico.

Por eso, te traemos este recopilatorio especial con los cinco capítulos más potentes y recientes del canal, ideales para entender cómo hemos pasado de pelearnos con los prompts de un chatbot a diseñar ecosistemas complejos basados en la Web Agéntica y la automatización total.

Prepara tus auriculares y dale al play para repasar con el equipo de Goodly desde el potencial de los protocolos MCP y las Skills en Gemini, hasta el gobierno de la IA con Vertex AI o el duelo definitivo de la automatización entre n8n y Google Workspace.

¡Arrancamos con este último gran viaje por la infraestructura actual!

Guía definitiva de los nuevos protocolos de la IA

Pasamos del software pasivo a la "web agéntica": agentes autónomos que buscan, negocian y compran por nosotros/as.

En este episodio, nuestro equipo de Goodly analiza los protocolos que definen este nuevo stack tecnológico. Repasan cómo MCP (Anthropic) conecta LLMs con datos externos, la comunicación entre IA mediante A2A y Agent-to-UI, y el impacto de UCP en el eCommerce.

Nos asomamos a un escenario donde el cliente final es un algoritmo, lo que obliga a cambiar por completo las reglas del SEO tradicional y las estrategias de posicionamiento.

Los MCPs y Skills llegan a Gemini. Diferencias clave y casos de uso

La llegada de MCP y Skills a Gemini Enterprise entierra las integraciones a medida. Analizamos en este podcast cómo personalizar la IA corporativa sin el coste de entrenar modelos desde cero.

Mientras el protocolo MCP estandariza la conexión segura de sistemas con agentes de IA, las Skills funcionan como "recetas" en Markdown que otorgan capacidades específicas sin saturar el contexto del modelo.

Combinar ambas tecnologías duplica la precisión y ofrece una portabilidad real para saltar entre entornos como Cursor, Claude o Gemini casi sin despeinarse.

¿El próximo gran hit de Google? Descubriendo los experimentos de IA más prometedores

La era de las aplicaciones AI Native ya es una realidad y el laboratorio de Google no para de lanzar prototipos.

Vemos en detalle los experimentos más prometedores de Google Labs: desde herramientas creativas como Pomelli (campañas de marketing mediante una URL) o Stitch (diseño de interfaces que exporta a Figma), hasta apuestas técnicas como Project Genie, que genera mundos jugables con una frase, y Jules, un agente autónomo que firma Pull Requests directamente en GitHub.

¡Una radiografía perfecta de hacia dónde se dirige el desarrollo de software!

Vertex AI: el centro de mando de la GenAI empresarial

Vertex AI ya no es solo para Machine Learning tradicional, es el ecosistema central de Google Cloud para gobernar y escalar IA generativa enterprise.

Nos adentramos en este universo para ver la creación visual de agentes con Agent Designer, el despliegue en producción mediante Agent Engine y la integración de datos corporativos con Vertex AI Search y Vector Search (RAG).

Además, analizamos la seguridad con Model Armor y cómo Gemini Enterprise democratiza el uso de estas herramientas poniéndolas a un clic del usuario de negocio.

¿Quiere Google matar a n8n?Opal y Workspace Studio a debate

¿Quién se quedará con el trono de la automatización? Google Opal llega como una propuesta experimental para montar prototipos multimodales solo con lenguaje natural.

Si buscas exprimir Gemini de forma nativa en Gmail o Drive, Workspace Studio es la opción clave para la productividad diaria.

En el otro extremo, el veterano n8n sigue siendo imbatible si necesitas flujos lógicos complejos, grandes volúmenes de datos y un despliegue self-hosted que garantice la privacidad absoluta del negocio.

Bonus: el último episodio del canal

En este último capítulo tan especial, el equipo de Goodly echa la vista atrás para recordar los curiosos inicios del canal (¡cuando se grababa en mitad de la montaña!) y repasar las mejores anécdotas, debates internos y risas que nunca salieron en el guion.

Pero no todo es nostalgia: este episodio también mira hacia adelante para analizar hacia dónde se dirigen el futuro del ecosistema cloud y la Inteligencia Artificial. Una despedida cargada de agradecimiento para la comunidad que ha hecho posible superar las 240.000 escuchas. ¡Gracias por acompañarnos!

El primer síntoma suele aparecer en la forma de gestionar el trabajo. Las PMO tradicionales, diseñadas para controlar costes y plazos, se quedan cortas cuando lo que se necesita es demostrar valor real. Al mismo tiempo, los equipos de desarrollo se encuentran saturados, atrapados en ciclos largos y dependientes de perfiles senior para tareas que podrían automatizarse. Y en el plano industrial, la presión sobre la cadena de suministro no da tregua: volatilidad, escasez de talento y exigencias regulatorias que no esperan.

La buena noticia es que la IA está dejando de ser parte del problema para convertirse en parte de la solución, y no de forma teórica. Hablamos de frameworks que transforman el conocimiento en código automático, probado y seguro, de oficinas de proyectos que evolucionan hacia modelos orientados al valor con apoyo de IA en la priorización y la toma de decisiones y de cadenas de suministro que ya operan con autonomía real gracias a tecnologías como los Gemelos Digitales de Operación, Edge AI o la IA Agéntica.

Estos tres informes comparten una misma idea: el cambio no es solo tecnológico, es organizativo y cultural. Y quienes lo aborden antes no solo ganarán eficiencia, sino una ventaja competitiva difícil de replicar.

¿Te has perdido alguno? Échale un vistazo a este recopilatorio 👇

Informe - 7 buenas prácticas para evolucionar tu PMO a VMO

Las oficinas de gestión de proyectos tradicionales han dejado de ser suficientes. En este informe exploramos cómo transformar la PMO en una Value Management Office que alinee estrategia con ejecución, priorice el impacto en el negocio y ponga al cliente en el centro. No es solo un cambio metodológico: es una evolución cultural que, además, incorpora la IA en aspectos clave como la priorización y el seguimiento del flujo de valor.

Informe - Industria 2026: el salto haciala supply chain autónoma

En 2026, la IA ha dejado de ser una herramienta de consulta para convertirse en un motor de acción. En este informe analizamos las cinco tendencias que están redefiniendo el sector industrial: IA Agéntica, Gemelos Digitales de Operación, Edge AI, GreenOps y cobótica de nueva generación. En un entorno de volatilidad global y escasez de talento, la autonomía operativa ya no es una opción tecnológica, es una necesidad financiera.

Informe - Desarrollo AI First: acelera laentrega de software con IA, contexto y activos reutilizables

¿Tu modelo de delivery ha tocado techo? Equipos saturados, ciclos largos y dependencia de perfiles senior para tareas repetitivas es uno de los patrones actuales. Paradigma Context Delivery Framework es un framework que mueve el eje hacia el desarrollo AI First para generar código automático, probado y seguro, y escalar sin disparar los costes.

"La historia no se repite, pero rima."

En mayo de 2026, en el I/O, Google presentó WebMCP como protagonista de la web agéntica: un estándar abierto, voluntario, que "mejora la experiencia de tus usuarios". Si llevas más de diez años en marketing digital, ese lenguaje te suena. También es, palabra por palabra, el mismo que usó con HTTPS en 2014, con el diseño responsive en 2012 y con Core Web Vitals en 2020.

Ninguna de esas recomendaciones siguió siendo opcional.

Resumiendo: Google nunca obliga de golpe. Publica una recomendación, regala herramientas de medición, da un periodo de gracia y después convierte la recomendación en la condición para existir en su buscador. WebMCP está hoy en la fase 1 de ese ciclo, y quien dirija marketing en 2026 debería leer el calendario con las gafas de 2014 por eso de que, quien no tiene memoria, repetirá los errores del pasado.

Qué es WebMCP (la respuesta corta)

WebMCP es una propuesta de estándar web, impulsada por Google y Microsoft en el W3C, para que una página exponga "herramientas" estructuradas (funciones JavaScript y formularios anotados) que los agentes de IA puedan invocar directamente en lugar de interpretar el DOM a ciegas haciendo scraping.

La diferencia práctica es que si hoy un agente que quiere reservar en tu web "mira" la página y adivina dónde hacer clic, con coste alto y resultados inconsistentes. Con WebMCP, tu web le dice exactamente qué puede hacer y cómo. Menos error, menos tokens, más conversión agéntica, menos carga de sistemas, más eficacia y rentabilidad para sus agentes.

El estado a julio de 2026: origin trial desde Chrome 149, Gemini in Chrome como primer consumidor y Expedia, Booking.com, Shopify, Credit Karma y Target ya experimentando. Todo "opcional", claro.

El patrón de Google: 4 veces que lo opcional dejó de serlo

Contenido de calidad → Panda

En enero de 2011, Google avisó en su blog de que actuaría contra las content farms. Era una recomendación editorial: "haz contenido útil". El 23 de febrero de 2011 llegó Panda y borró del mapa al 12% de los resultados de búsqueda. eHow y Suite101 pasaron de imperios a notas al pie en semanas. El mismo ciclo se repitió en 2022 con el Helpful Content Update: la recomendación de las Quality Rater Guidelines se convirtió en filtro algorítmico.

HTTPS → "sitio no seguro"

En el I/O de junio de 2014, Google lanzó la campaña "HTTPS Everywhere": cifrar era una buena práctica. En agosto de 2014 ya era señal de ranking, aunque "ligera". En julio de 2018, Chrome 68 empezó a marcar todo sitio HTTP como "No seguro" en la barra de direcciones. Lo opcional duró cuatro años y al final no era un tema de SEO: era que tu web parecía rota delante del cliente, el propio navegador empezó a mostrar señales y bloquear el acceso a sites que no cumplieran con ese criterio, inicialmente opcional.

Mobile-friendly → mobile-only

Google recomendaba responsive desde 2012. En febrero de 2015 puso fecha: "el 21 de abril, la compatibilidad móvil será señal de ranking". Llegó Mobilegeddon y, con él, la primera vez que Google avisaba con un día exacto. Pero el ciclo no terminó ahí: en noviembre de 2016 anunció el mobile-first indexing como "un experimento", en 2019 lo hizo default y en octubre de 2023 completó la indexación mobile-only: si tu web no funciona en móvil, para Google no existe. Once años de "recomendación" a requisito absoluto.

¿Empezáis a ver el patrón?

Velocidad → Core Web Vitals

La velocidad fue señal de ranking en desktop desde 2010, afectando a menos del 1% de las consultas: puro gesto simbólico. Durante años, Google regaló PageSpeed Insights y Lighthouse "para ayudarte". En 2018, el Speed Update la llevó a móvil. Y, en mayo de 2020, presentó las métricas Core Web Vitals con una promesa inédita: seis meses de aviso antes de activarlas. En junio de 2021, el Page Experience Update las convirtió en señal de ranking. Métrica publicada, herramienta gratuita, periodo de gracia, factor de ranking, histeria masiva. El manual completo, ejecutado sin prisa.

Podría añadir AMP (opcional en 2015, peaje de facto para salir en Top Stories en 2016, irrelevante en 2021) o los datos estructurados de schema.org. El patrón no cambia: nadie te obliga, simplemente desapareces.

Dónde estamos ahora con WebMCP

Si superponemos el calendario histórico sobre WebMCP, la lectura es clara:

1. Fase de recomendación (estamos aquí): estándar abierto, discurso de "experiencia de usuario", early adopters de referencia haciendo de escaparate. Es el HTTPS de junio de 2014.
2. Fase de medición: llegará una herramienta de validación de agent-readiness, el equivalente al test de mobile-friendly o a Lighthouse donde ya está informada la posibilidad de revisar. Cuando Google te regala un medidor, no es generosidad: es que va a puntuar con él.
3. Fase de ventaja visible: los sitios con WebMCP convertirán mejor en Gemini in Chrome y en las experiencias agénticas de búsqueda. Los case studies de Expedia o Shopify harán el trabajo comercial que Google no necesita hacer. Todos querremos contar una historia de "hemos mejorado la conversión de este transaccional de esta forma y en este canal".
4. Fase de peaje: las webs sin herramientas expuestas serán para los agentes lo que una web sin versión móvil fue en 2015: invisibles. No habrá penalización anunciada, no hará falta.

¿Tengo pruebas de que esto pasará? No. Tengo 4 precedentes en quince años y ninguno en contra. En mi trabajo, a eso lo llamamos un patrón con el que planificar.

Cómo se ve WebMCP en la práctica: dos ejemplos

La teoría del patrón está bien, pero un/a CMO decide mejor viendo el coste real. WebMCP tiene dos APIs y la elección no es técnica, es de negocio: la imperativa (JavaScript) para acciones transaccionales como buscar o añadir al carrito y la declarativa (atributos HTML) para formularios, donde el coste de implementación es casi cero.

Ejemplo 1: un ecommerce en Shopify

Un agente que hoy quiere comprar en tu tienda "mira" la página y adivina: localiza el buscador, interpreta el grid de productos, encuentra el botón de compra. Cada paso es una oportunidad de error. Con la API imperativa, tu tienda declara sus dos acciones de valor como herramientas, apoyándose en los endpoints AJAX que Shopify ya expone (/search/suggest.json y /cart/add.js):

// En el theme.liquid o como snippet: la tienda declara sus herramientas.

// Herramienta 1: buscar producto (solo lectura).
await document.modelContext.registerTool({
  name: 'buscar_producto',
  description: 'Busca productos en el catálogo por texto libre. Devuelve nombre, precio, disponibilidad y variantes (talla, color).',
  inputSchema: {
    type: 'object',
    properties: {
      consulta: { type: 'string', description: 'Texto de búsqueda, ej. "zapatillas running mujer"' }
    },
    required: ['consulta']
  },
  execute: async ({ consulta }) => {
    const res = await fetch(`/search/suggest.json?q=${encodeURIComponent(consulta)}&resources[type]=product`);
    const data = await res.json();
    return JSON.stringify(data.resources.results.products.map(p => ({
      titulo: p.title, precio: p.price, url: p.url, disponible: p.available
    })));
  },
  annotations: { readOnlyHint: true } // Señala al agente que esta acción no modifica nada.
});

// Herramienta 2: añadir al carrito (acción sensible).
await document.modelContext.registerTool({
  name: 'anadir_al_carrito',
  description: 'Añade una variante de producto al carrito. No completa la compra: el checkout siempre lo confirma el usuario.',
  inputSchema: {
    type: 'object',
    properties: {
      variantId: { type: 'number', description: 'ID de la variante (producto + talla/color)' },
      cantidad: { type: 'number', description: 'Unidades, por defecto 1' }
    },
    required: ['variantId']
  },
  execute: async ({ variantId, cantidad = 1 }) => {
    const res = await fetch('/cart/add.js', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ items: [{ id: variantId, quantity: cantidad }] })
    });
    const cart = await res.json();
    return `Añadido al carrito. Total actual: ${cart.items?.length ?? 1} artículos.`;
  },
  annotations: { readOnlyHint: false }
});

Hay 3 decisiones de negocio escondidas en estas 40 líneas que no debería tomar solo el implementador:

• Qué expones y qué no. Aquí el agente puede buscar y añadir al carrito, pero el checkout queda en manos del usuario. Dónde pones esa frontera es una decisión de riesgo y de margen, no de código.
• Qué devuelves. El agente decide con lo que le das: si buscar_producto no devuelve disponibilidad, el agente recomendará productos agotados. El diseño del output es el nuevo merchandising.
• La descripción es tu nuevo copy. description es lo que "lee" el agente para decidir si usa tu herramienta o la de tu competidor. Escribirla bien es trabajo de marketing, no de sistemas.

Ejemplo 2: un formulario de captación (API declarativa)

Para leads, soporte o presupuestos no hace falta JavaScript: la API declarativa convierte el formulario que ya tienes en herramienta añadiendo tres atributos HTML. El coste marginal es tan bajo que el argumento de "ya lo haremos" pierde la excusa técnica:

<form toolname="solicitar_presupuesto"
      tooldescription="Solicita un presupuesto de proyecto. Recoge datos de contacto, tipo de proyecto y presupuesto estimado. Un consultor responde en 24h laborables."
      action="/contacto/enviar">

  <label for="nombre">Nombre y apellidos</label>
  <input type="text" name="nombre" id="nombre" required>

  <label for="email">Email corporativo</label>
  <input type="email" name="email" id="email" required>

  <select name="tipo_proyecto" required
          toolparamdescription="Determina a qué equipo se enruta la solicitud.">
    <option value="analitica">Analítica digital y medición</option>
    <option value="cro">CRO y experimentación</option>
    <option value="data">Data e IA</option>
  </select>

  <label for="detalle">Cuéntanos tu proyecto</label>
  <textarea name="detalle" id="detalle"></textarea>

  <button type="submit">Enviar solicitud</button>
</form>

El navegador traduce esto a un JSON Schema que el agente entiende sin ambigüedad: el agente rellena los campos delante del usuario (el formulario permanece visible, con el indicador de foco :tool-form-active), y el envío final lo hace la persona, salvo que añadas toolautosubmit.

Y un detalle que a mí me parece el más relevante del estándar para los equipos de analítica: el evento de envío llega marcado con agentInvoked.

document.querySelector('form').addEventListener('submit', (e) => {
  if (e.agentInvoked) {
    // Lead generado por un agente: márcalo en tu dataLayer / CRM.
    dataLayer.push({ event: 'generate_lead', lead_source_type: 'ai_agent' });
  }
});

Es decir: el estándar ya trae de serie la pieza para segmentar tráfico humano vs. tráfico agéntico en tu medición. Si en 2015 la pregunta era "¿qué porcentaje de tu tráfico es móvil?", la de 2027 será "¿qué porcentaje de tus leads los genera un agente?". Quien empiece a medirlo ahora tendrá la línea base que los demás tendrán que improvisar.

Si quieres verlo funcionando antes de tocar tu web, Google publica demos completas en GitHub: la demo coffee-shop es el ejemplo más cercano a un ecommerce real (catálogo, carrito y pedido con herramientas expuestas), y en el mismo repositorio hay ejemplos de ambas APIs.

Nota: WebMCP está en origin trial (Chrome 149+) y la sintaxis puede cambiar; navigator.modelContext quedó deprecado en Chrome 150 a favor de document.modelContext. Los ejemplos usan la sintaxis vigente a julio de 2026.

Qué haría yo si dirigiese marketing digital en 2026

1. Inventaría tus transacciones críticas. Reserva, alta, presupuesto, compra: esas son las "herramientas" que un agente querrá invocar. Si no sabes cuáles son tus 5 acciones de más valor, ese es el primer trabajo, no el código.
2. Mete WebMCP en el roadmap técnico de 2027, no en el de "ya veremos". El origin trial de Chrome 149 permite experimentar hoy con coste bajo. Los que probaron responsive en 2013 vivieron Mobilegeddon como un trámite y los que esperaron, como una crisis.
3. Mide tu tráfico agéntico desde ya. Antes de optimizar para agentes necesitas saber cuántos te visitan, qué intentan hacer y dónde fallan. Sin esa línea base, cualquier decisión de 2027 será a ciegas.
4. No externalices el criterio. Igual que con los CDP o con la IA en CRO, la tecnología es lo de menos: el valor está en decidir qué expones, a qué agentes y con qué reglas de negocio. Eso no se delega en el implementador de turno.
5. Desconfía del "es opcional". Es la palabra con la que empiezan todos los requisitos de Google.

La web agéntica no va a preguntarte si estás preparado/a, igual que Mobilegeddon no preguntó en 2015. La buena noticia es que, esta vez, el patrón está escrito y el calendario, publicado. Lo opcional es la fase uno.

La pregunta cambia. El problema de fondo, no.

¿Quién te dice cómo es tu cliente? ¿Qué control tienes sobre esa información? ¿Cuánto pagas por ella? ¿Puedes activarla cuando quieras, o dependes de que alguien de IT abra un ticket?

Y la más importante, la que pocas veces llega al comité de dirección: ¿cuánto tiempo tarda tu organización en pasar de detectar una oportunidad de negocio a tener una campaña en producción?

Esa es la pregunta real. No qué plataforma tiene mejores conectores.

Qué es realmente un CDP composable y por qué la metáfora importa

La definición formal habla de centralizar y unificar datos de cliente de múltiples fuentes. En la práctica, la mayoría de los equipos lo describen como "una coctelera en la que metes todos los datos del cliente y sirves a cada equipo lo que necesita". Y aunque suene simplista, esa metáfora tiene valor: ayuda a que legal, negocio, tecnología y marketing hablen del mismo proyecto sin que cada uno entienda algo diferente.

Un CDP composable no es un producto, es una filosofía de construcción. En lugar de comprar una plataforma cerrada que copia tus datos a su propio entorno, usa el data warehouse que ya tienes (Snowflake, BigQuery, Databricks) como fuente única de verdad y construye encima capacidades modulares: resolución de identidad, segmentación, activación.

El motor de todo esto es el Reverse ETL. El ETL tradicional mueve datos operativos hacia el warehouse para analizarlos mientras que el Reverse ETL hace el viaje inverso: toma los segmentos y modelos ya calculados (valor de vida del cliente, riesgo de abandono, propensión de compra) y los sincroniza hacia donde se ejecuta el negocio: CRM, plataformas publicitarias, herramientas de automatización.

La promesa es real: tus datos no salen de tu entorno gobernado, puedes cambiar cualquier pieza sin reconstruir todo lo demás y aprovechas la inversión que ya hiciste en modelado de datos.

Para organizaciones con un equipo de ingeniería de datos maduro y casos de uso que toleran sincronizaciones diarias o semanales, esta arquitectura sigue siendo una apuesta sólida. El problema es lo que no aparece en el caso de negocio inicial.

El coste que nadie calcula antes de firmar

Aquí está el matiz que rara vez aparece en la propuesta comercial de un CDP composable: cada capacidad vive en un proveedor distinto, conectada por API. Eso da control de ingeniería pero también tiene una consecuencia estructural que pocos calculan.

Cuando una campaña termina y genera resultados (aperturas, clics, conversiones), esa información tiene que recorrer toda la cadena de vuelta: de la plataforma de activación al Reverse ETL, del Reverse ETL al warehouse, reconstrucción de modelos en dbt, reentrenamiento del modelo predictivo. Solo entonces el sistema sabe algo de lo que acaba de pasar. Ese ciclo se mide en horas, no en segundos.

Para un envío de email semanal, esa latencia es tolerable. Para un agente que necesita actuar, observar el resultado y mejorar la siguiente decisión dentro de la misma sesión del cliente, esa latencia no es un detalle técnico, es un límite estructural.

El segundo coste que tampoco suele entrar en la conversación inicial es la superficie de privacidad. Cada sincronización del Reverse ETL hacia una plataforma externa crea una copia nueva de datos personales fuera de tu entorno. En un stack composable típico, un email o un número de teléfono puede existir simultáneamente en tres o más sistemas: el warehouse, la caché del Reverse ETL y cada plataforma de activación. Cada copia implica un acuerdo de tratamiento distinto, una solicitud de borrado que tarda días en propagarse y una auditoría que crece con cada proveedor que añades.

El gasto no escala de forma lineal, crece con el producto de filas de datos, número de conectores, frecuencia de sincronización y herramientas activadas. Con volúmenes altos, el coste de mantenimiento (cómputo de warehouse, tarifas de sincronización, plataforma de mensajería, resolución de identidad, dos o cinco ingenieros/as con dedicación única al pipeline) puede acercarse o superar al de una plataforma agéntica con activación nativa.

Esto no convierte lo composable en caro ni lo agéntico en barato, hace que la pregunta del coste se responda en tres años, no en con la primera factura.

Las 6 prácticas para comprimir ese coste antes de decidir nada

Independientemente de qué arquitectura elijas al final, hay decisiones de diseño que determinan cuánto cuesta operar a escala. Aplicarlas ahora ahorra mucho después.

1 Capa de eventos unificada desde el origen

Si cada canal llega al warehouse con su propia estructura, las transformaciones costosas se acumulan aguas abajo y el modelo de datos se convierte en deuda técnica. Normalizar los eventos de todos los canales (paid, email, web, app, CRM) con un esquema común desde la ingesta reduce el cómputo posterior y hace los modelos reutilizables.

2 Particionado por fecha y canal desde el diseño inicial

Las tablas bien particionadas desde el principio permiten que los modelos procesen solo los incrementales. Es una decisión de diseño que cuesta poco al principio y ahorra mucho a escala.

3 Sincronización incremental basada en cambios reales (CDC)

El mayor driver de coste variable en un CDP composable no es la licencia, es el producto de filas por frecuencia y por destinos. Reemplazar volcados completos periódicos por Change Data Capture puede reducir el volumen transferido entre 5x y 10x en organizaciones con datos estables.

4 Consolida destinos de activación

Sincronizar el mismo segmento a cuatro plataformas distintas multiplica el coste sin multiplicar el impacto. Cuando es posible, centraliza en un destino y redistribuye desde él.

5 Segmenta los SLAs de frescura por caso de uso

No todos los segmentos necesitan actualizarse cada hora. Separar formalmente los que requieren ciclos horarios de los que toleran ciclos diarios puede reducir el cómputo entre 3x y 5x sin impacto perceptible en resultados.

6 Documenta las reglas de negocio antes de activar cualquier agente

El coste de un agente está directamente correlacionado con la calidad del contexto que recibe. Un agente con contexto mal estructurado genera más iteraciones, consume más recursos y produce más hipótesis descartadas. Invertir en documentar objetivos, restricciones de marca, audiencias prohibidas y reglas de negocio antes de poner a los agentes a trabajar es la palanca de eficiencia más barata y la más ignorada. Algunas empresas han institucionalizado este trabajo en perfiles especializados que actúan como punto de control entre la estrategia y los agentes.

Qué cambia realmente con un CDP agéntico

Durante diez años, los CDP han prometido inteligencia proactiva. Y durante diez años, la realidad ha sido la misma: el marketer entra, construye la audiencia que ya tenía en mente, lanza la campaña que ya tenía planeada y sale. El CDP ejecuta ideas, pero nunca ha tenido una propia.

La diferencia no es de versión, es de qué hace la plataforma por defecto.

Un CDP agéntico ejecuta agentes de forma continua que exploran los datos, identifican oportunidades concretas y proponen, con borrador ya construido, la audiencia, el mensaje y el contenido para capturarlas. No espera a que alguien llegue con la hipótesis, sino que la genera.

"La nueva fuente de datos que añadimos nos ha ayudado a afinar el modelo de churn." "Hay segmentos de alto valor sin campañas activas. ¿Lo activamos?"

La diferencia frente al chat de IA* que ya han añadido casi todas las plataformas es la profundidad de la investigación. Un chat de IA responde bien preguntas tácticas concretas como "¿cuáles fueron mis productos más vendidos el mes pasado?", pero se queda corto en preguntas estratégicas abiertas porque solo ve los datos de su propia plataforma, está diseñado para responder rápido en lugar de explorar a fondo y pierde el contexto en investigaciones largas.

Un CDP agéntico mantiene agentes especializados trabajando en segundo plano durante horas. Unos generan hipótesis, otros las investigan, un mecanismo de priorización las ordena por alcance e impacto esperado y un verificador final descarta todo lo que los datos no respalden. El resultado no es una lista de 30 "oportunidades" al día sin orden ni criterio, sino un ranking accionable de lo que merece atención ahora mismo.

¿Cómo ve el agente toda la operación sin duplicar datos? El Composable Context Layer

Hay una pregunta que surge aquí con razón: si el agente necesita acceder a datos de cliente, campañas activas, creatividades y reglas de negocio, ¿no estamos creando otro repositorio centralizado con otra copia de todo?

La respuesta bien resuelta es que no. El patrón que lo hace posible se llama Composable Context Layer y aplica la misma filosofía del CDP composable a la inteligencia: en lugar de llevar todos los datos a donde vive la IA, se lleva la IA a donde ya viven los datos.

Los agentes se conectan directamente al data warehouse sin crear una copia consumen herramientas que la empresa ya tiene (Looker, Snowflake Cortex, Databricks Genie), acceden al contexto creativo donde ya vive (DAM, Figma, repositorios de contenido) y reciben la estrategia de negocio como documentos estructurados o vía protocolos abiertos como MCP.

En producción, este patrón devuelve contexto de cliente en torno a 60ms para payloads pequeños, latencia suficiente para personalizar en el momento sin esperar al siguiente batch, y permite definir hasta diez endpoints customizados por perfil, de modo que cada agente recibe solo el contexto que necesita para su caso de uso concreto con el estado de consentimiento ya incorporado.

Algunos vendors como Tealium o Hightouch implementan este patrón de forma nativa y, en ambos casos, los datos del warehouse no se copian, se exponen a través de una API gobernada.

Es una arquitectura que resuelve el problema de privacidad y gobernanza al mismo tiempo que habilita la inteligencia. Los datos no se mueven, la inteligencia va a donde están los datos.

Cómo el sistema mejora solo: memoria acumulativa por campaña

El segundo cambio estructural es la memoria acumulativa. Cada interacción de cliente, cada campaña lanzada, cada experimento y cada resultado se cataloga como evidencia reutilizable que alimenta la siguiente decisión. Esa memoria opera en varios niveles.

• A nivel de audiencia, el sistema aprende qué segmentos no convierten independientemente de la oferta, cuáles responden mejor a SMS frente a email o dónde en un journey una oferta cambia realmente el comportamiento.
• A nivel de campaña, recuerda qué rasgos de asunto generan aperturas entre clientes de alto valor o qué formatos funcionan en lanzamientos de producto frente a campañas evergreen.
• A nivel de iniciativa estratégica, cada objetivo que defines (aumentar frecuencia de compra, reducir churn de primeros compradores) acumula contexto de sus ejecuciones anteriores. Así, la siguiente recomendación no empieza desde cero.

La diferencia crítica respecto al ciclo composable es que esta memoria se actualiza de forma continua dentro del mismo entorno, sin el viaje de ida y vuelta entre proveedores. El resultado de ayer alimenta la decisión de hoy, en el mismo contexto, sin reentrenamiento manual.

Tú defines los vectores de trabajo y la métrica objetivo. Los agentes trabajan contra esa métrica, en el mismo contexto de activación. Cambia silos y reuniones de alineamiento por hipótesis y governance.

La pregunta que debe resolver el comité de dirección

No es una pregunta técnica, es una pregunta de modelo operativo.

¿Cuánto tarda tu organización en pasar de detectar una oportunidad a tener una campaña en producción? ¿Quién levanta las hipótesis? ¿Quién tiene como única función hacer challenge al status quo? ¿Cuánto cuesta el proceso completo: diseño de hipótesis, validación legal, ingesta, modelado y puesta en marcha?

Si la respuesta es semanas (un brief, un equipo de diseño, desarrollo u operaciones que ensambla la audiencia y el journey) el problema no es de talento ni de presupuesto de medios. Es arquitectónico. Y ningún volumen adicional de conectores de Reverse ETL va a resolver una limitación que vive en cómo está repartido el ciclo de aprendizaje entre proveedores.

Hazte 3 preguntas para saber dónde estás

Cadencia de activación

¿Tu negocio tolera sincronizaciones diarias o semanales, o necesitas que el sistema actúe y aprenda dentro de la misma sesión del cliente?

Madurez de IA

¿Tus casos de uso se limitan a modelos entrenados por lotes que toleran actualizaciones cada hora o cada día o necesitas decisión en tiempo real con aprendizaje continuo?

Capacidad de equipo

¿Tu equipo de datos puede mantener un stack multiproveedor de forma sostenida o esa carga operativa compite con prioridades de ingeniería más críticas para el negocio?

Las organizaciones que responden con confianza "por lotes es suficiente" y "tenemos el equipo para mantenerlo" tienen un caso legítimo para seguir en arquitectura composable, siempre que apliquen las prácticas de eficiencia descritas más arriba. Las que responden "necesitamos el ciclo cerrado en tiempo real" o "ya gastamos más en mantenimiento de conectores que en estrategia" están describiendo, sin saberlo todavía, el caso de negocio de un CDP agéntico.

Lo que un/a CMO debería exigir antes de firmar

Independientemente de qué proveedor esté en la mesa, hay 5 verificaciones que vale la pena hacer antes de comprometerse con cualquier arquitectura.

• Copia cero real. Que demuestren arquitectura de copia cero verdadera, no una copia secundaria disfrazada de integración. En el caso agéntico, que el Composable Context Layer opere sin replicar datos fuera de tu entorno gobernado.
• Cumplimiento de plataforma completa. Que las certificaciones (SOC 2 Tipo II, ISO 27001, GDPR, CCPA) cubran toda la plataforma, no solo el módulo de almacenamiento.
• Gobernanza verificable. Control de acceso por rol, filtros de datos protegidos, flujos de aprobación y registros de auditoría comprobables. En arquitecturas agénticas, verifica además que los guardarraíles del agente son configurables y auditables: qué audiencias no puede tocar, qué restricciones de marca respeta.
• Compatibilidad nativa. Integración certificada con tu warehouse existente, sin ingeniería personalizada.
• Tiempo de valor real. Casos de uso en producción medidos en semanas, no en trimestres. Y en el caso agéntico, evidencia de que la memoria acumulativa mejora las recomendaciones a lo largo del tiempo, no solo en el primer mes.

La decisión no es binaria pero sí es urgente

Un despliegue híbrido, un warehouse existente conectado a capacidades agénticas para los casos de uso que lo requieren, puede ser el punto de equilibrio correcto durante la transición. Eso es razonable.

Lo que no es razonable es seguir tratando esta decisión como un asunto técnico que se resuelve en una reunión de arquitectura de datos, mientras la competencia ya ejecuta campañas que se ajustan a sí mismas sin esperar al siguiente sprint.

Y conviene recordar que el resultado de estos proyectos depende menos de la tecnología elegida y más de si existe un patrocinador claro, un caso de negocio bien definido y una gestión del cambio que mantenga alineados a tecnología, negocio y cliente durante todo el proceso. Una arquitectura agéntica perfectamente elegida fracasa igual que una composable mal elegida si nadie ha resuelto antes quién decide, qué se mide y cómo se sostiene el compromiso de los equipos implicados.

Nunca es un proyecto de unos meses. Incluso en el mundo de los Reverse ETL, el proyecto siempre acarrea un BAU.

El mercado de CDP se está consolidando porque las organizaciones que ya cerraron el ciclo de aprendizaje completo dentro de una sola plataforma están tomando mejores decisiones con más velocidad que las que siguen reconstruyendo modelos cada vez que termina una campaña.

Si estás evaluando este cambio, la pregunta correcta no es qué plataforma tiene la lista de funciones más larga. Es qué socio puede ayudarte a hacer esa evaluación con honestidad, incluyendo los escenarios en los que la respuesta correcta no es la más cómoda de vender.

Para profundizar en este desafío, en este episodio contamos con Ignacio López, un profesional con más de 20 años de experiencia liderando procesos de transformación en compañías como Tous, y Miguel Carrasco, director comercial de retail y consumo en Paradigma Digital.

Lo curioso de Ignacio es que su perfil rompe moldes: estudió arquitectura e interiorismo corporativo, pero un giro del destino en el mundo de las startups lo llevó a asumir la gestión de operaciones y el área comercial, convirtiéndose en el puente entre las necesidades de negocio y el equipo técnico. De ahí dio el salto al mundo corporativo, donde ha consolidado un rol eminentemente gestor y humano.

¿Por qué sigue existiendo desconexión entre Negocio y TI?

A menudo se percibe una fricción constante entre ambos lados. Para Ignacio, el origen de este problema no es una declaración de guerra, sino una falta de alineación en los objetivos.

Las metas empresariales suelen fijarse desde la dirección sin un consenso previo con las áreas transversales. Cuando el objetivo baja de golpe con una fecha fija, la tecnología se ve obligada a reaccionar a rebufo.

No es que los equipos técnicos quieran frenar los proyectos, el negocio debe pedir y proponer, porque eso es lo que motiva a los equipos de desarollo, pero hay una línea muy clara entre pedir de forma realista y "soñar gratis".

Esta falta de comunicación e infravaloración de los tiempos técnicos genera consecuencias directas. La adaptación de herramientas tecnológicas nunca es tan sencilla como el drag and drop que prometen los proveedores. El legado tecnológico y el mapa de sistemas de las empresas siempre añaden capas de complejidad.

Cuando los proyectos se ejecutan con plazos irreales, aparece la desmotivación y la desafección en los equipos técnicos, lo que termina disparando la rotación y provocando una pérdida crítica de conocimiento en las compañías.

Cocinar proyectos de TI: receta frente a improvisación

Ignacio utiliza una analogía muy gastronómica para explicar la gestión de proyectos. Para él, dirigir en TI es como cocinar, donde conviven la repostería y la cocina clásica.
La repostería exige una receta milimétrica: si cambias un gramo, el dulce falla.

Esto equivale a los proyectos puramente de infraestructura, donde no hay margen para la flexibilidad. En cambio, la cocina clásica permite adaptar flujos y añadir un toque personal, lo que se asemeja a los proyectos funcionales que requiere el negocio.

Para que la receta de un equipo de proyectos funcione, Ignacio destaca ingredientes esenciales que deben mezclarse bajo un método propio adaptado a cada empresa:

• El equipo y un gobierno claro: sin una estructura y unos roles bien definidos, el talento se diluye.
• Visión de procesos y buena definición: la dirección de proyecto debe aportar su conocimiento histórico para co-diseñar la solución junto al negocio, retando sus peticiones cuando sea necesario.
• Presupuesto y tiempo: son el fuego y el horno. Sin ellos, es imposible cocinar nada.
• El principal error del lado de negocio suele ser infravalorar el esfuerzo técnico pensando que todo se soluciona con "añadir un botoncito".
• Por el lado tecnológico, el error es asumir de forma pasiva que el requerimiento del cliente interno viene siempre perfecto al 100%, en lugar de hacer un challenge inteligente para complementar la definición.

La IA hace nuestro día a día más humano

Respecto al impacto de la Inteligencia Artificial, la visión desde la trinchera tecnológica es firmemente positiva. Lejos de las corrientes catastrofistas que auguran la destrucción de empleo, la IA se perfila como el nuevo fuego o la nueva rueda de la evolución humana.

En la práctica diaria de un/a líder, la IA no cambia el rol estratégico, pero sí optimiza radicalmente la eficiencia de las tareas mecánicas (informes, KPIs, auditorías).

Al liberar tiempo de los procesos automatizables, los perfiles directivos pueden dedicarse a lo que de verdad importa: la gestión humana, la motivación y la resolución de conflictos. Curiosamente, la IA está logrando que la dirección de tecnología sea mucho más humana.

Sin embargo, hay terrenos donde la tecnología no llega. En una reunión, la IA no detecta la patada por debajo de la mesa, un resoplido de desinterés o un lenguaje corporal que te obliga a cambiar el rumbo de una presentación en tiempo real. Esa inteligencia emocional sigue siendo exclusiva de las personas.

Los/as líderes del futuro: perfiles híbridos y empatía

El sector tecnológico demanda cada vez más perfiles híbridos. No se busca necesariamente ingenieros/as puros/as para liderar la interlocución, sino personas capaces de traducir el lenguaje técnico al de negocio y viceversa, permitiendo que cada profesional brille en lo que realmente es bueno.

Para las personas que buscan liderar los equipos del mañana, el camino se cocina con paciencia y cuatro pilares fundamentales:

• Construir equipos heterogéneos (mezclando géneros, edades y perspectivas de juniors y seniors).
• Combinar especialistas con perfiles transversales sin forzarlos a cambiar su naturaleza.
• Evitar a toda costa los perfiles con aversión al cambio en un sector que es pura evolución.
• Construir desde la confianza ciega en las capacidades del equipo. Sin confianza, no hay liderazgo, solo un grupo de personas recibiendo órdenes.

Con los MCP, los LLMs pueden conectarse a nuestras BBDD, APIs, herramientas internas… pero cada llamada externa al mundo es latencia y latencias. Si a esta ecuación le añadimos los Virtual Threads de Java, esta orquestación de agentes empieza a buscar una forma eficiente para no saturar nuestros servidores.

En este post iremos desde la integración del MCP dentro de Java con Spring AI, pasando por los hilos virtuales y su forma de salvarnos la vida cuando miles de agentes se ejecutan de manera paralela. Os doy la bienvenida al mundo de la IA escalable con Java.

Por qué usar Virtual Threads con MCP

Querer (y necesitar) ir a la alta concurrencia en IA

Debemos saber qué pasa cuando un LLM utiliza una herramienta mediante un MCP, ya que el cómputo masivo de CPU es verdad que lo abstraemos a los propios modelos, pero sí que estamos ante un problema de I/O puro y duro. El agente suele estar esperando el 99% del tiempo: esperando que el LLM decida qué herramienta utilizar, esperando a la propia red o esperando al MCP para que le devuelva los datos del sistema.

Imaginemos esto pero elevado a miles de usuarios concurrentes usando pools de hilos tradicionales. El resultado también lo podemos imaginar: servidor sin memoria antes de que el LLM acabe de escribir su primer token. Por lo tanto, si realmente necesitas desplegar agentes de IA en producción, es cuando tienes que dar el salto a los hilos virtuales.

Una vez decidido, ¿por qué este combo?

El Model Context Protocol (MCP) es el nuevo estándar abierto para conectar clientes de IA con servidores de datos y herramientas. Al integrar Spring AI con soporte MCP sobre una JVM con hilos virtuales activos, obtenemos ventajas competitivas brutales:

• Bloqueo sin coste: los Virtual Threads (disponibles desde Java 21) son hilos ultra ligeros gestionados por la JVM, como podemos leer en este post de nuestro compañero Daniel Peña. Cuando un agente hace una llamada HTTP o gRPC bloqueante a un servidor MCP, la JVM "desmonta" ese hilo virtual y libera el hilo de la plataforma real para que siga atendiendo peticiones.
• Modelo imperativo y limpio: olvídate de encadenar flujos reactivos complejos tipo WebFlux solo para gestionar la asincronía de las APIs de IA. Puedes escribir código secuencial clásico, fácil de depurar y mantener.
• Escalabilidad masiva: pasar de soportar unos pocos de agentes simultáneos a miles en la misma máquina, reduciendo los costes de infraestructura cloud drásticamente (y la pela es la pela!).

Conceptos clave: Host, Server y Virtual Threads

La arquitectura de MCP combinada con Java moderno gira en torno a tres elementos:

• MCP Host (cliente): en nuestro caso, nuestra aplicación Spring Boot/Spring AI. Es nuestro Isco en el centro del campo, es nuestro cerebro que habla con el LLM y decide orquestar las llamadas.
• MCP Server: el microservicio o proceso independiente que expone las herramientas reales (por ejemplo: los conectores de las bases de datos, herramientas de sistema, APIs).
• Virtual Threads: el motor de ejecución subyacente en Java que permite que cada sesión de agente corra en su propio hilo dedicado sin penalización de rendimiento.

Teniendo claro qué es cada uno, ¿cómo configuramos este ecosistema? Te lo mostramos con un ejemplo práctico.

Preparar nuestro proyecto Java para IA y MCP

Una vez decidido que vamos a montar agentes de alta disponibilidad, iremos paso a paso configurando nuestro entorno con Spring Boot y Spring AI.
Primero, generamos nuestro proyecto (si no lo tenemos ya) utilizando, por ejemplo, Spring Initializr, asegurándonos de utilizar una versión de Java 21 o superior.

En nuestro build.grade (o pom.xml si utilizamos maven), añadimos las dependencias necesarias para Spring AI y el starter de soporte para MCP:

plugins {
    id 'java'
    id 'org.springframework.boot' version '4.0.6'
    id 'io.spring.dependency-management' version '1.1.7'
}

group = 'com.example'
version = '0.0.1-SNAPSHOT'

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(21)
    }
}

repositories {
    mavenCentral()
    maven { url 'https://repo.spring.io/milestone' }
}

ext {
    set('springAiVersion', "2.0.0-M4")
}

dependencies {
    implementation 'org.springframework.ai:spring-ai-starter-mcp-client'

    implementation 'org.springframework.ai:spring-ai-starter-model-ollama'

    implementation 'org.springframework.boot:spring-boot-starter-web'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
}

dependencyManagement {
    imports {
        mavenBom "org.springframework.ai:spring-ai-bom:${springAiVersion}"
    }
}

tasks.named('test') {
    useJUnitPlatform()
}

Para activar la magia de la que hemos hablado para la concurrencia masiva, debemos irnos a nuestro nuestro archivo de configuración application.properties y añadir la siguiente línea, que le indicará a Spring Boot que delegue ese trabajo pesado a los hilos virtuales:

spring.threads.virtual.enabled=true

Una vez configurado, vamos a crear un servicio de IA muy básico. Este componente actuará como MCP Host, conectándose a un servidor MCP local (por ejemplo, un script de Node o Python que consulta información corporativa) y resuelve las peticiones de los usuarios:

package com.example.ai.mcp;

import org.springframework.ai.chat.client.ChatClient;
import org.springframework.ai.tool.ToolCallback;
import org.springframework.stereotype.Service;
import java.util.List;

@Service
public class AgentService {

    private final ChatClient chatClient;

    // Spring AI autoconfigura el cliente MCP y expone sus herramientas como beans de tipo ToolCallback.
    public AgentService(ChatClient.Builder chatClientBuilder, List<ToolCallback> mcpTools) {
        this.chatClient = chatClientBuilder
                .defaultTools((Object) mcpTools.toArray(new ToolCallback[0])) // Vincula las herramientas del servidor MCP
                .build();
    }

    public String askAgent(final String userPrompt) {
        return this.chatClient.prompt()
                .user(userPrompt)
                .call()
                .content();
    }
}

En este código, el ChatClient recupera dinámicamente las herramientas (getTools()) que el servidor MCP tiene disponibles. Cuando invocamos askAgent, el LLM evalúa el prompt del usuario y, si necesita datos externos, ejecuta de manera transparente la herramienta del servidor MCP a través de una llamada de red bloqueante.

Gracias a que activamos los hilos virtuales, mientras la red resuelve esa petición de herramientas, el hilo queda completamente libre para procesar otras interacciones de IA.

El "Efecto Matrioska" del bloqueo en agentes de IA

En una aplicación web de toda la vida, por ejemplo, una API que consulta una base de datos, el hilo atiende la petición HTTP, bloquea mientras lee de la BD, recibe el dato y responde. Hay un único bloqueo de I/O.

En un agente de IA con un MCP externo, se produce lo que me gusta llamar el bloqueo en Matrioska, que basicamente es un bloqueo dentro de otro bloqueo. Cuando invocamos nuestro método askAgent, pasa lo siguiente en un único hilo:

1. Primer bloqueo (Envío al LLM): el cliente de Spring AI envía el prompt del usuario al LLM. El hilo se bloquea esperando la respuesta de la red.
2. El LLM decide: el modelo analiza el texto y dice: "No tengo este dato, necesito ejecutar la herramienta consultarFactura". Y no, no busques ese método en el código anterior, esa es la magia, el MCP le indica las tools que tiene disponibles y él es capaz de decidir que necesita esa.
3. Segundo bloqueo (llamada al MCP Server): Spring AI intercepta esa decisión del LLM y, a través del MCP, realiza una petición de red al servidor MCP externo donde reside la herramienta corporativa. El hilo se vuelve a bloquear esperando al servidor MCP.
4. Tercer bloqueo (vuelta al LLM): el servidor MCP responde, Spring AI recoge el JSON, y se lo vuelve a enviar al LLM para que procese la respuesta final. El hilo se bloquea por tercera vez.

Si utilizamos hilos de la plataforma tradicionales (java.lang.Thread nativos del S.O.), un solo usuario consultando al agente mantendría secuestrado un hilo físico durante varios segundos a través de múltiples llamadas de red anidadas.

Con los Virtual Threads, la JVM realiza magia: cada vez que se inicia uno de estos 3 bloqueos de red, el hilo virtual cede el hilo físico (Carrier Thread) instantáneamente. El hilo físico pasa a atender a otros usuarios, y el hilo virtual "vuelve a la vida" en cualquier otro hilo físico libre solo cuando los bytes de la red están listos.

“Lo creo pero no lo veo”. Destripando los hilos en los logs

No hay nada mejor que una demostración para ver si todo esto que os estoy contando es cierto. Para ello, vamos a modificar el servicio que hemos creado para imprimir el hilo actual antes de llamar al ChatClient, y así poder ver la concurrencia:

 package com.example.ai.mcp;
import org.springframework.ai.chat.client.ChatClient;
import org.springframework.ai.mcp.SyncMcpToolCallbackProvider;
import org.springframework.beans.factory.ObjectProvider;
import org.springframework.stereotype.Service;

@Service
public class AgentService {

    private final ChatClient chatClient;

    // Usamos ObjectProvider para que el cliente MCP sea opcional y no rompa al arrancar en local
    public AgentService(ChatClient.Builder chatClientBuilder, ObjectProvider<SyncMcpToolCallbackProvider> mcpToolCallbackProvider) {

        mcpToolCallbackProvider.ifAvailable(provider -> chatClientBuilder.defaultToolCallbacks(provider.getToolCallbacks()));

        this.chatClient = chatClientBuilder.build();
    }

    public String askAgent(final String userPrompt) {
        System.out.println("DEBUG HILOS -> " + Thread.currentThread());

        return this.chatClient.prompt()
                .user(userPrompt)
                .call()
                .content();
    }
}

Al levantar nuestra aplicación Spring Boot 4 y lanzar un par de peticiones, la consola nos arrojará algo como esto:

¿Cómo se lee esta traza?

• VirtualThread[#57...]: nos confirma que la petición ya no corre en un hilo de Tomcat, sino en un VirtualThread independiente creado para esa petición.
• ForkJoinPool-1-worker-2: es el hilo real del Sistema Operativo (Carrier Thread) que está transportando e interpretando ese hilo virtual en ese milisegundo exacto.

Si tuviéramos activadas las trazas del cliente MCP de Spring AI, veríamos que durante la llamada al servidor de herramientas, el identificador VirtualThread[#57] se pausa, liberando al worker-1 para que otra petición (como la del VirtualThread[#65]) pueda usar la CPU inmediatamente.

Simulando escenarios de alta concurrencia

Para ver el verdadero potencial, podemos exponer este servicio mediante un controlador REST muy sencillo. Si recibimos una gran cantidad de peticiones entrantes, podremos comprobar cómo el sistema responde de forma instantánea sin degradación del pool de conexiones:

package com.example.ai.mcp;

import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequestMapping("/api/v1/agent")
public class AgentController {

    private final AgentService agentService;

    public AgentController(AgentService agentService) {
        this.agentService = agentService;
    }

    @PostMapping("/ask")
    public String ask(@RequestBody String prompt) {
        // Spring Boot mapea esta petición automáticamente en un hilo virtual
        return agentService.askAgent(prompt);
    }
}

Si hiciéramos una prueba de carga simulando 500 usuarios preguntando al agente en el mismo segundo (donde cada uno requiere que el LLM llame a herramientas que tardan 1.5 segundos en responder), un servidor tradicional con un pool de 200 hilos colapsaría por falta de recursos de ejecución.

Con este enfoque, la JVM creará 500 hilos virtuales ligeros que nacerán, esperarán el I/O del protocolo MCP sin penalización y morirán limpiamente tras entregar la respuesta. Todo en orden, todo correcto.

Algunos errores comunes y cómo podemos evitarlos

• Confundir velocidad de CPU con concurrencia

Los Virtual Threads no hacen que nuestros algoritmos de IA locales o el parseo de JSON sean más rápidos. El único poder (y no es poco) es optimizar los tiempos de espera de las entradas y salidas. Si nuestra tarea requiere procesar matrices pesadas en local, un hilo tradicional o un pool dedicado sigue siendo la opción adecuada.

• Olvidar los límites de los sistemas externos

Que nuestra aplicación pueda soportar miles de conexiones no significa que nuestra base de datos o el servidor MCP remoto que usamos pueda soportar 10.000 conexiones concurrentes. Debemos ajustar siempre los timeouts y los límites de los pools de conexiones de nuestros clientes HTTP/gRPC.

• No monitorizar la JVM

Al trabajar con herramientas de IA que disparan miles de hilos virtuales, es vital usar herramientas de monitoreo como JDK Flight Recorder (JFR) por ejemplo, para trackear que no se estén produciendo bloqueos indeseados en el planificador de la JVM.

Conclusión

Ya tenemos entre nuestras manos las piezas clave para construir la próxima generación de arquitecturas de IAl empresarial utilizando los estándares más actuales del sector. Unir la flexibilidad del MCP para desacoplar las herramientas de negocio, con la robustez y ligereza de los Virtual Threads en Java, nos permite derribar definitivamente el mito de que Java es un lenguaje pesado o lento para el desarrollo de ecosistemas ágiles de IA (¡larga vida a Java!).

Si venías del desarrollo web clásico, el cambio de mentalidad al diseñar agentes autónomos conectados por red es radical. Lo importante es experimentar, medir el comportamiento de la infraestructura bajo estrés y ajustar los flujos de herramientas. El camino hacia agentes de producción estables y masivos ya no es una utopía inalcanzable y con las próximas actualizaciones estoy seguro de que se irá avanzando aún más en este punto.

Referencias

• Model Context Protocol (MCP) Official Documentation by Anthropic
• Spring AI Project Official Reference and MCP Integration Guide
• JEP 444: Virtual Threads Specification - OpenJDK
• Spring Boot Reference Guide: Production-ready Features & Virtual Threads
• Anthropic MCP GitHub Repository and Ecosystem Tools

También es fácil caer en el error de pensar que utilizarla nos lleva a ser más baratos, eficaces y rápidos.

En este escenario de saturación tecnológica, nuestra metodología no se diluye frente a la IA; se fortalece. Construimos sistemas donde la IA potencia la ejecución, pero la soberanía operativa y la visión estratégica siguen siendo humanas.

Hace ocho años, Paradigma ya advertía que tu empresa no necesita tribus y squads. Aquella tesis sigue vigente: confundir la forma con el fondo es el camino más rápido a la irrelevancia. Los frameworks deben evolucionar a partir de necesidades reales, no de modas metodológicas y este es el framework que utilizamos aquí, que está funcionando en junio de 2026 y del que no debemos enamorarnos.

De dónde partimos

La madurez tecnológica en Paradigma se articula sobre tres pilares de valor: personas, procesos y tecnología, asegurando que cada inversión en IA se traduzca en una ventaja competitiva tangible.

1. El eje de personas recoge todos los planes de formación práctica que realizamos a los equipos y que nos sirven para dar soluciones tangibles a los problemas . Estas deformaciones “Breaking AI” sirven de repositorio de materiales, videos y de recogida de casos.
2. El eje de procesos se basa en una solución, framework, proyecto o cambio en la forma de trabajar.
3. El eje de tecnología se apoya en los desarrollos que activamos sobre tecnologías existentes que nos permiten acceder a información de forma tangible.

El principal elemento que hemos aprendido es que, para consolidar procesos, sistemas o tecnologías es necesario construir sobre procesos establecidos en lugar de sobre framework externos o flujos completos.

¿Y dónde está el valor diferencial? En la integración. Si el equipo de CRO habla y construye bajo los mismos estándares de eficiencia que Desarrollo o Agile, eliminamos los silos y aceleramos el time-to-market.

Aterrizándolo en los equipos de CRO

El framework de CRO ha madurado hasta convertirse en una herramienta de precisión. Lejos de generalidades, nuestra propuesta se asienta en tres ejes que garantizan la escalabilidad: estructura, modularidad y persistencia.

¿A qué nos referimos con la estructura, modularidad y persistencia?

• La estructura garantiza la interoperabilidad con equipos internos y externos.
• La modularidad permite que cada solución aporte valor inmediato de forma independiente o como parte de un ecosistema conectado.
• La persistencia asegura que el input y output sean estables, eliminando la incertidumbre y garantizando que las decisiones se tomen sobre una base sólida de confianza.

Resumiendo: un enfoque de "piezas de Lego" donde cada componente es autónomo y genera valor por sí mismo, compatibles entre sí y estandarizados para garantizar consistencia.

Ejemplo sobre el análisis

En Paradigma no utilizamos gemas, skills o soluciones genéricas: los "skills" o gemas pueden parecer eficaces, pero son cajas negras propensas a alucinaciones, bloqueos por sistemas anti-bot y resultados inconsistentes.

¿Cómo puede una empresa basar su estrategia en un resultado que cambia según el contexto del prompt o la carga de tokens del día? La falta de control técnico es el enemigo de la rentabilidad.

Nuestra solución consiste en sustituir el azar por el control técnico. Utilizamos plugins propios que operan directamente sobre el DOM, componentes y tiempos de carga.
Este enfoque garantiza velocidad, consistencia estructural y una trazabilidad absoluta de los recursos consumidos. No nos quedamos solo en el análisis, pasamos a la auditoría técnica de alto nivel. Evitas arrastrar un sesgo apretando un botón.

¿Por qué trabajar con el DOM en lugar de con el chat?

Marsal McLuhan, una de las referencias en modelos de comunicación, decía que el medio es el mensaje. Estudios recientes muestran que, más allá del mensaje, el medio es el sesgo y, en procesos de valor, la pérdida de información entre iniciativas y soluciones es algo a destacar.

No es lo mismo hacer un prompt con texto que hacer una consulta con JSON, hacerla sobre el DOM o pegando una imagen. Diferente contexto o sesgo.

Un ejemplo sobre los insights y el research

Los experimentos de MeasureIQ confirman que los usuarios sintéticos son excelentes para la amplitud, pero fallan en la profundidad. Confiar ciegamente en ellos sin criterio humano es diluir la voz del cliente.
Yo no creo que deban sustituir nunca al usuario, creo que cuando no hay opción de preguntar a los usuarios, ayudan a traer un punto de vista adicional.

De igual manera creo que pervertimos el concepto de formas increíbles. Yo no puedo describir a la perfección un usuario sintético a la IA, no puedo darle el sabor, contexto, penetración entre mi base de clientes, representatividad entre el volumen de mis compras o wording.

Yo puedo diseñar un proceso de ingesta de información para que la IA levante los usuarios con su contexto (y luego me los describa).

Generando los usuarios sintéticos

Qué usuarios, en qué volumen, con qué interés, qué transacciones o fricciones es un contexto difícil de contar y fácil de automatizar.

El proceso que seguimos para los usuarios sintéticos parte de una ingesta de diferentes fuentes internas y externas de datos:

• Procesamiento de lenguaje natural (NLP) sobre verbatims anonimizados.
• Enriquecidos con datos sociodemográficos de cliente.
• Completados con datos transaccionales.
• Ampliados con NPS y expandidos con literales de reviews de Google My Business, Truspilot, Glassdoor cuando procede…

El resultado: la IA revela patrones de comportamiento que la observación manual ignora, generando una base de conocimientos robusta sobre la que aplicar nuestro objetivo, a la vez que tiene el contexto de volumetrías.

La IA tiene muy claros unos perfiles que nosotros no conocemos.

Entendiendo los usuarios sintéticos

Lo siguiente que hacemos es descargar el modelado de los usuarios sintéticos sobre plantillas de protopersonas. De esta forma podemos entender, comunicar y transmitir el punto de vista aplicado a cada análisis.

Nos sirve como ancla para aterrizar y crear racord y, sobre todo, para poder revisar en profundidad si los sesgos, contexto o expectativas se cumplen.

Modulando la respuesta

La modularidad de nuestras plantillas garantiza que los insights sean transversales. No trabajamos para un departamento, trabajamos para la consistencia del ecosistema digital, asegurando que cada optimización refuerce el valor de marca.

Otras soluciones con IA para equipos de CRO

Cada fase de nuestra metodología, desde el diseño de escenarios y el análisis de rendimiento en el DOM hasta la validación de prototipos y generación de snippets, está diseñada bajo un patrón de excelencia técnica:

1. Todas las soluciones tienen que estar pensadas para poder conectarse con otros equipos (sean o no de Growth).
2. Todas las soluciones han de dar valor de forma autónoma y poder integrarse en otros procesos.
3. Todas las soluciones han de limitar el error y la incertidumbre.

De forma que en la siguiente versión, cuando sigamos mejorando el proceso de CRO, todo evolucione de forma consistente y coherente.