El 23 de septiembre de 2026, Diametral dedicó su 19.º LabTechDay a los agentes de IA. Por primera vez, nuestros equipos de París, Lyon, Bruselas, São Paulo y Bogotá trabajaron el mismo día sobre el mismo programa. En la agenda: las decisiones de arquitectura, los marcos de gobernanza y las lecciones de campo que distinguen a un agente en producción de una prueba de concepto prometedora.
Un agente es un sistema que persigue un objetivo gracias a un modelo, instrucciones, herramientas, datos y un ciclo de control. Los diseñamos, construimos y operamos para nuestros clientes. Esta jornada nos permitió consolidar nuestros métodos y alinear a todos nuestros engines en torno a una misma doctrina.
El LabTechDay, nuestro laboratorio de expertise
El LabTechDay es un formato interno recurrente: una jornada completa en la que nuestros expertos contrastan sus prácticas de proyecto, ponen a prueba enfoques y producen activos reutilizables con nuestros clientes. Cada edición está a cargo de un engine; esta estuvo a cargo del engine Applied AI & Data Science.
Esta 19.ª edición se realizó a escala del Grupo: todas nuestras oficinas, con un programa común. Se desarrolló en tres etapas:
- Establecer el marco: la evolución de la IA predictiva a la IA generativa y luego agéntica, la anatomía de un agente (modelo, harness, herramientas, memoria, salvaguardas) y la escala de autonomía, desde el simple generador hasta el agente autónomo.
- Diseñar y construir: dos workshops en paralelo, uno dedicado al diseño y otro a la ingeniería.
- Contrastar con la realidad: una plenaria global con lecciones de proyectos cuantificadas, tanto éxitos como límites.
Salimos con un vocabulario común para todos nuestros consultores, arquitecturas de referencia y un Agent Solution Canvas ya utilizable en la fase de definición con nuestros clientes.
Dos streams, todos los engines: diseñar y luego construir
Un agente confiable depende tanto de su diseño como de su ingeniería. Por eso movilizamos a todos nuestros engines en dos streams complementarios, que se reunieron al final del día en torno al mismo caso.
Stream A: Design. Diseñar una solución agéntica.
- Pregunta: ¿Se necesita un agente y en qué condiciones?
- Engines: Estrategia, Product Delivery, Governance & Quality, Decision Analytics, Acculturation & Change
- Formato: Definición de un caso de cliente realista y posterior revisión por un board de cinco roles
- Entregable: Un Agent Solution Canvas de una página
Antes de construir, calificamos la necesidad. Agente, workflow, copiloto o aplicación tradicional: aplicamos tres pruebas. ¿Se puede dibujar el diagrama de flujo de antemano? ¿El siguiente paso depende de lo que encontró el anterior? ¿Quién ejecuta, la persona o el sistema? Cuando el recorrido es predecible, recomendamos un workflow: más económico, más fácil de probar, más predecible. El agente se justifica cuando el camino se descubre sobre la marcha.
Los equipos aplicaron esta grilla a un caso realista: un agente que produce un primer borrador de propuesta comercial a partir de una solicitud de propuesta (RFP), notas de descubrimiento y referencias anteriores. Lo formalizaron en nuestro Agent Solution Canvas: 14 decisiones en 4 fases (Encuadrar, Otorgar, Controlar, Comprometerse), cada una con un criterio de validación. Nivel de autonomía, radio de impacto de cada herramienta, fronteras de confianza, derechos de decisión humanos, hipótesis de valor cuantificada, primer alcance de puesta en producción. Luego, cada canvas se defendió ante un board de cinco roles: sponsor del cliente, arquitecto empresarial, responsable de seguridad y gobernanza, delivery lead y usuario final.
Stream B: Build. Construir un agente desde cero.
- Pregunta: ¿Cómo construir un agente confiable y gobernable?
- Engines: Applied AI & Data Science, Architecture & Engineering
- Formato: Construcción de un agente desde cero: modelo, herramientas, ciclo de control, salvaguardas
- Entregable: Un harness de agente operativo
Nuestros perfiles técnicos ensamblaron todo lo que rodea al modelo: la invocación de herramientas, el ciclo decidir-actuar-observar, la memoria, los permisos, la observabilidad y los presupuestos de ejecución. Nuestro principio de arquitectura: un núcleo probabilístico dentro de una coraza determinista. El modelo aporta el criterio; el código aporta las garantías.
Ambos streams coinciden en un punto: un control se diseña en la arquitectura, no en el prompt. “No puede enviar correos externos porque no tiene herramienta de envío” es un control. “Le pedimos que no lo haga” no lo es.
Lecciones de campo: lo que funciona en producción y lo que queda por dominar
La plenaria reunió a todos los países en torno a dos casos implementados con nuestros clientes, presentados con sus métricas y sus límites.
Lujo y belleza: un agente asesor de productos para una gran casa
Diseñamos e implementamos un agente asesor sobre el catálogo de perfumes y belleza de una casa de lujo. La necesidad: responder a una pregunta como “¿qué alternativa hay a mi labial y cómo aplicarlo según la marca?”, cuando la respuesta está dispersa en varios sistemas.
- Alcance: más de 4.000 productos, más de 200.000 precios cruzados por mercado, país y tamaño, 6 fuentes de datos.
- Arquitectura: un agente ReAct, 18 herramientas expuestas a través de 4 servidores MCP, text-to-SQL y RAG, desplegado en Kubernetes, trazado y medido en cada ejecución. Cada nuevo caso de uso (servicio al cliente, tienda) se declara por configuración, sin reconstruir la base.
- Resultados en una campaña de no regresión de 100 casos: 76 % de recall de productos, 6,9 s de latencia mediana, 100 % de precisión en herramientas (ninguna llamada fuera de alcance).
- Salvaguardas: cada respuesta es trazable hasta un dato de referencia. Las negativas (consejo médico, estrategia de marca) se prueban y versionan igual que las respuestas esperadas.
También compartimos el límite que encontramos. En las preguntas más abiertas, ningún responsable de negocio había definido de antemano el objetivo de calidad. Nuestra recomendación: que los equipos que impulsan el caso de uso definan qué es una “buena respuesta” desde el inicio del proyecto. Eso es lo que hace medibles incluso las preguntas más subjetivas.
Delivery: la Hybrid Squad, dos humanos y n agentes
La adopción de agentes de código despegó; la creación de valor, mucho menos. Según BCG, el 5 % de las organizaciones captura la mayor parte del valor de la IA, y la brecha es organizacional, no tecnológica.
Nuestra respuesta es la Hybrid Squad “2H + nA”: un Product Owner y un Data Architect responsables, agentes que ejecutan bajo un contrato versionado y cinco puertas de validación humana entre un agente y la producción. Tres principios la estructuran: las personas siguen siendo responsables, los agentes están acotados y la autonomía se gana con evidencia. Una demostración en vivo ilustró el modelo. Este trabajo será objeto de un libro, The Future of AI-Powered Delivery.
Saber decir no al agent washing
No toda automatización justifica un agente. Un reporte mensual del pipeline comercial sigue una secuencia fija: allí recomendamos un workflow, con un modelo limitado a la etapa de síntesis. Calificar honestamente la necesidad es parte de nuestra expertise.
Nuestro enfoque: Diametral Process aplicado a los agentes
Un agente que se sostiene en producción moviliza todas nuestras áreas de expertise, desde la estrategia hasta la operación. Eso es lo que estructura Diametral Process, nuestra metodología para construir las empresas AI-native:
Design: Pertinencia del agente, hipótesis de valor cuantificada, alcance, nivel de autonomía
Build: Arquitectura, herramientas y permisos, salvaguardas, evaluaciones en ambos sentidos (actuar y negarse)
Scale: Extensión por configuración, derechos de decisión humanos, adopción por parte de los equipos
Run: Observabilidad, no regresión continua, responsable designado del lado del cliente
Nuestra convicción: la autonomía se delega; la responsabilidad, nunca. Acompañamos a nuestros clientes para elegir el nivel adecuado de agencia, construirlo y operarlo en el tiempo.
