Mathis Joffre, cofundador y director de ingeniería de Blaxel – Serie de entrevistas

Mathis JoffreCofundador y responsable de ingeniería de Blaxel, es un experimentado ingeniero de infraestructura que anteriormente contribuyó a escalar una de las plataformas de nube más grandes de Europa, OVHcloud. En Blaxel, lidera el desarrollo de sistemas escalables de baja latencia, diseñados para agentes de IA, y es un colaborador clave en las herramientas de código abierto de la compañía que facilitan la implementación optimizada para el rendimiento.

Blaxel Es una plataforma informática diseñada específicamente para agentes de IA autónomos, que permite a los desarrolladores crear, probar y ejecutar flujos de trabajo de agentes sin necesidad de gestionar la infraestructura. Su arquitectura incluye micromáquinas virtuales (microVM) ultrarrápidas, ejecución de trabajos por lotes y una puerta de enlace global para enrutamiento y respaldo. Blaxel prioriza el sandboxing seguro, la observabilidad en tiempo real y la escalabilidad fluida para soportar implementaciones de agentes de nivel de producción.

Trabajó durante tres años en I+D de infraestructura de datos e inteligencia artificial en OVHcloud. ¿Cuál fue el momento clave o la idea que lo inspiró a crear Blaxel como una nube diseñada específicamente para agentes de IA?

Mientras trabajaba en AI Endpoints (uno de los productos de IA estrella de OVHcloud), me di cuenta de lo compleja que será la próxima generación de arquitecturas en la nube y los casos de uso de la IA. Estamos pasando de los chatbots tradicionales a sistemas totalmente autónomos. Esta revolución de la agencia no se limita a aplicaciones más inteligentes; también nos obliga a replantearnos todo, desde la pila de software hasta la arquitectura del centro de datos. Esta constatación fue lo que me impulsó a crear Blaxel.

Mirando hacia atrás en su trayectoria inicial como ingeniero (desde la creación de herramientas de red en Orange Business hasta la definición de stacks en OVHcloud), ¿cómo ha influido esa experiencia en la arquitectura y la filosofía de Blaxel?

Yo diría: manténganse firmes. Aunque esta revolución pueda parecer hipotética o exagerada, la única manera de hacerla realidad es centrarse en casos de uso concretos y resolverlos bien. Esa mentalidad moldeó a Blaxel desde el principio: la construimos en torno a las necesidades reales de nuestros clientes, desde la generación de código hasta el análisis de video. En lugar de seguir tendencias, queríamos ofrecer una plataforma diseñada específicamente para que los agentes tengan justo lo que necesitan para trabajar con eficacia.

¿Puede explicarnos la función del Protocolo de Contexto de Modelo (MCP) y las puertas de enlace de modelos multirregionales? ¿Cómo mejoran esto la tolerancia a fallos y la escalabilidad de los agentes?

Los agentes se basan en el contexto: su capacidad para acceder a información relevante es clave para actuar con eficacia. MCP sirve como nuestra interfaz principal para integrar agentes con nuestra infraestructura, ya que aborda este desafío. Al igual que los desarrolladores usan las API REST para conectar aplicaciones en el mundo SaaS, ahora usarán el Protocolo de Contexto de Modelo para proporcionar un contexto específico y procesable a sus agentes.

Pero el contexto por sí solo no basta; los agentes también dependen de LLM, como los que ofrecen OpenAI o Anthropic. Dada la creciente demanda, los servidores de estos proveedores pueden verse saturados ocasionalmente por el tráfico. Aquí es donde entran en juego las puertas de enlace de modelos multirregionales.

Las puertas de enlace de modelos permiten redirigir el tráfico dinámicamente al punto final LLM más cercano disponible (en términos de latencia), ya sea OpenAI, Anthropic u otro proveedor. Esto no solo mejora los tiempos de respuesta, sino que también garantiza la tolerancia a fallos (mediante la conmutación por error a proveedores alternativos) y la escalabilidad (al distribuir la carga entre múltiples regiones y modelos).

Blaxel admite herramientas para desarrolladores que los propios agentes pueden usar. ¿Qué motivó el diseño de APIs que los agentes puedan usar en lugar de los humanos? ¿Cómo prevés que esto evolucione?

Para mí, el lanzamiento de OpenAI de Operador Fue revelador; me hizo darme cuenta de que el futuro implica que los agentes consuman infraestructura directamente. Los agentes comenzaron analizando datos históricos y respondiendo preguntas. Luego, pasaron a generar código. El siguiente paso lógico es que implementen ese código de forma autónoma.

Por eso creemos que los agentes necesitan su propia nube, diseñada específicamente en torno a la idea de que el futuro de las operaciones de TI estará impulsado por agentes autónomos.

Al reflexionar sobre los proveedores de nube y las plataformas de alojamiento de agentes existentes (como Modal, RunPod, Replicate, etc.), ¿dónde ve las brechas más comunes al implementar agentes a escala?

La mayoría de las plataformas actuales no fueron diseñadas para agentes persistentes, con estado y autónomos, sino para trabajos sin estado o API de inferencia. Por lo tanto, se termina integrando computación, memoria, almacenamiento y redes de maneras que no fueron diseñadas para soportar procesos de larga duración con memoria, bucles de retroalimentación y E/S complejas. El resultado son sistemas frágiles o una alta sobrecarga operativa. Esa es la brecha: necesitamos una infraestructura donde los agentes sean ciudadanos de primera clase, no una ocurrencia tardía.

¿Cuáles son los antipatrones más comunes que observa y con qué tropiezan los desarrolladores al implementar agentes autónomos en producción en comparación con desarrollo y pruebas?

El error más común es tratar a los agentes como funciones: se invocan, se ejecutan y luego se olvidan. En producción, los agentes necesitan conservar el contexto, gestionar herramientas y, en ocasiones, reaccionar a señales externas en tiempo real. También se subestima la complejidad de los entornos reales: API inestables, datos inconsistentes y transiciones de estado inesperadas. Los desarrolladores suelen realizar pruebas en condiciones ideales, pero la realidad de la producción exige una observabilidad robusta, un entorno de pruebas y estrategias de recuperación.

Su hoja de ruta incluye funciones como la bifurcación de instantáneas, la conmutación por error automática y una optimización computacional más profunda. ¿Cuáles considera más transformadoras para los sistemas que priorizan a los agentes?

La bifurcación de instantáneas, sin duda. Facilita la depuración, la experimentación y patrones de razonamiento paralelo que simplemente no son posibles en entornos de nube convencionales. Imagine un agente que llega a un punto de decisión: bifurca su entorno de pruebas en múltiples ramas, explora diferentes resultados en paralelo y luego elige la mejor ruta a seguir. Este tipo de lógica de bifurcación es inherente a los flujos de trabajo de los agentes, pero completamente ajeno a los entornos de ejecución de nube tradicionales. Cambia fundamentalmente nuestra concepción de la autonomía y el flujo de control.

Gartner predice que el 75% de las aplicaciones utilizarán agentes de IA para 2028: ¿cómo anticipa que Blaxel evolucionará a medida que los agentes de IA se vuelven omnipresentes en todas las industrias?

A medida que los agentes se generalicen, prevemos que Blaxel evolucione de ser una "infraestructura para agentes de IA" a ser la "capa operativa" de la que dependen, gestionando el ciclo de vida, la coordinación e incluso las interacciones en el mercado. No solo se implementarán agentes en Blaxel, sino que se formarán, supervisarán y tendrán agentes que gestionen a otros agentes. Ya estamos viendo casos de uso emergentes en finanzas, seguridad y automatización empresarial que apuntan en esa dirección.

¿Se imagina un futuro donde los agentes no solo ejecuten aplicaciones, sino que también gestionen y reconfiguren la infraestructura de forma autónoma? ¿Cuáles son las implicaciones culturales y de seguridad de este cambio?

Sí, y es emocionante y desconcertante a la vez. Técnicamente, tiene sentido: los agentes pueden supervisar el estado del sistema, aplicar parches y optimizar las cargas de trabajo. Pero, culturalmente, desafía nuestra concepción del control y la confianza en las operaciones. En términos de seguridad, implica replantear los modelos de permisos: no solo quién puede actuar, sino... En qué se le permite convertirse a un agenteNecesitaremos nuevas abstracciones para una autonomía verificable y una autosuperación limitada.

¿Cuál es el concepto erróneo más grande sobre lo que hace que la infraestructura nativa del agente sea única?

Se trata simplemente de más GPU o tiempos de ejecución más largos. La infraestructura nativa del agente se centra en las posibilidades de comportamiento: otorgarles la capacidad de recordar, explorar, adaptarse y recuperarse. Esto requiere cambios en toda la pila: almacenamiento que monitoree la evolución del estado, modelos de ejecución que admitan concurrencia y ramificación, y observabilidad optimizada para el razonamiento, no solo para la latencia. Es un cambio de mentalidad, no solo un aumento de recursos.

¿Qué arrepentimiento o limitación técnica de tu tiempo en OVHcloud estás más contento de haber solucionado en Blaxel?

En OVHcloud, gran parte de lo que construíamos estaba limitado por abstracciones heredadas (máquinas virtuales, contenedores, redes) optimizadas para cargas de trabajo gestionadas por personas. No podíamos romper fácilmente con esos paradigmas. Con Blaxel, empezamos desde cero. Ya no es necesario simular que un agente es un trabajo por lotes o un microservicio. Podemos integrar primitivas como memoria, herramientas y objetivos directamente en el entorno de ejecución, lo que abre un espacio de diseño completamente nuevo.

Gracias por la gran entrevista, los lectores que deseen obtener más información deben visitar Blaxel.