Mathis Joffre, Co-fundador e Líder de Engenharia da Blaxel – Série de Entrevistas

Mathis Joffre, Co-fundador e Líder de Engenharia da Blaxel, é um engenheiro de infraestrutura experiente que anteriormente ajudou a escalar uma das maiores plataformas de nuvem da Europa na OVHcloud. Na Blaxel, ele lidera o desenvolvimento de sistemas escaláveis e de baixa latência projetados para agentes de IA e é um contribuinte importante para as ferramentas de código aberto da empresa que suportam a implantação orientada ao desempenho.

Blaxel é uma plataforma de computação projetada especificamente para agentes de IA autônomos, permitindo que os desenvolvedores construam, testem e executem fluxos de trabalho de agentes sem gerenciar infraestrutura. Sua arquitetura inclui microVMs ultra-rápidos, execução de trabalhos em lote e um gateway global para roteamento e fallback. Blaxel prioriza sandboxing seguro, observabilidade em tempo real e escalabilidade sem interrupções para suportar implantações de agentes de produção.

Você passou três anos trabalhando com R&D de infraestrutura de IA e dados na OVHcloud – qual foi o momento ou insight chave que o inspirou a construir a Blaxel como uma nuvem projetada especificamente para agentes de IA?

Eu percebi, enquanto trabalhava no AI Endpoints – um dos produtos de IA de ponta da OVHcloud – como a próxima geração de arquiteturas de nuvem e casos de uso de IA se tornará complexa. Estamos passando de chatbots tradicionais para sistemas completamente autônomos. Essa revolução agente não é apenas sobre aplicações mais inteligentes; é uma reavaliação de tudo, desde a pilha de software até a arquitetura de centro de dados. Essa percepção é o que me levou a construir a Blaxel.

Olhando para o seu caminho de engenharia inicial – desde a construção de ferramentas de rede na Orange Business até a definição de pilhas na OVHcloud – como essa experiência informou a arquitetura e a filosofia da Blaxel?

Eu diria: mantenha-se firme. Embora essa revolução possa parecer hipotética ou superestimada, a única maneira de torná-la real é se concentrar em casos de uso concretos e resolvê-los bem. Essa mentalidade moldou a Blaxel desde o início – construímos em torno das necessidades reais dos nossos clientes, desde a geração de código até a análise de vídeo. Em vez de perseguir tendências, queríamos entregar uma plataforma projetada especificamente que dê aos agentes exatamente o que eles precisam para executar de forma eficaz.

Pode nos guiar pelo papel do Protocolo de Contexto de Modelo (MCP) e gateways de modelo multi-região? Como isso melhora a tolerância a falhas e a escalabilidade para os agentes?

Os agentes são todos sobre contexto – sua capacidade de acessar informações relevantes é fundamental para agir de forma eficaz. O MCP serve como nossa interface principal para integrar agentes com nossa infraestrutura porque aborda esse desafio. Assim como os desenvolvedores usam APIs REST para conectar aplicativos no mundo SaaS, agora eles usarão o Protocolo de Contexto de Modelo para fornecer contexto específico e processável para seus agentes.

Mas o contexto sozinho não é suficiente – os agentes também dependem de LLMs, como os fornecidos pela OpenAI ou Anthropic. Dada a demanda crescente, os servidores desses provedores podem ocasionalmente ficar sobrecarregados com tráfego. É aí que os gateways de modelo multi-região entram em cena.

Os gateways de modelo permitem que o tráfego seja redirecionado dinamicamente para o endpoint LLM mais próximo (em termos de latência), seja da OpenAI, Anthropic ou outro provedor. Isso não apenas melhora os tempos de resposta, mas também garante a tolerância a falhas (falhando sobre para provedores alternativos) e escalabilidade (distribuindo a carga em várias regiões e modelos).

A Blaxel suporta ferramentas de desenvolvedor que os próprios agentes podem chamar – o que motivou o design de APIs consumíveis por agentes em vez de humanos? Como você vê isso evoluindo?

Para mim, o lançamento do Operator pela OpenAI foi esclarecedor – fez-me perceber que o futuro envolve agentes consumindo infraestrutura diretamente. Os agentes começaram analisando dados históricos e respondendo perguntas. Em seguida, passaram a gerar código. O próximo passo lógico é que eles deployem esse código de forma autônoma.

É por isso que acreditamos que os agentes precisam de sua própria nuvem – projetada em torno da ideia de que o futuro das operações de TI será impulsionado por agentes autônomos.

Refletindo sobre os provedores de nuvem existentes e plataformas de hospedagem de agentes (como Modal, RunPod, Replicate, etc.), onde você vê as lacunas mais comuns ao implantar agentes em escala?

A maioria das plataformas de hoje não foi projetada para agentes autônomos persistentes e com estado – elas foram projetadas para trabalhos sem estado ou APIs de inferência. Então, você acaba costurando computação, memória, armazenamento e rede de maneiras que não foram destinadas a suportar processos de longa duração com memória, loops de feedback e I/O complexos. O resultado é sistemas frágeis ou alta sobrecarga operacional. Essa é a lacuna: precisamos de infraestrutura onde os agentes sejam cidadãos de primeira classe, não uma afterthought.

Quais são os anti-padrões mais comuns que você vê – e o que os construtores tropeçam ao implantar agentes autônomos em produção versus teste/desenvolvimento?

O erro mais comum é tratar os agentes como funções – invocadas, executadas e então esquecidas. Em produção, os agentes precisam persistir contexto, gerenciar ferramentas e às vezes reagir a sinais externos em tempo real. As pessoas também subestimam o quão desordenados os ambientes do mundo real são: APIs instáveis, dados inconsistentes, transições de estado inesperadas. Os construtores frequentemente testam em condições ideais, mas a realidade da produção exige estratégias de observabilidade, sandboxing e recuperação robustas.

Sua estrada inclui recursos como fork de snapshot, failover automático e otimização de computação mais profunda. Qual você considera mais transformador para sistemas de agentes em primeiro lugar?

Fork de snapshot, sem dúvida. Isso desbloqueia padrões de depuração, experimentação e raciocínio paralelo que simplesmente não são possíveis em ambientes de nuvem convencionais. Imagine um agente alcançando um ponto de decisão – ele bifurca sua sandbox em várias ramificações, explora diferentes resultados em paralelo e então escolhe o melhor caminho à frente. Esse tipo de lógica de ramificação é nativo para fluxos de trabalho de agentes, mas completamente estranho para tempos de execução de nuvem tradicionais. Isso muda fundamentalmente a forma como pensamos sobre autonomia e fluxo de controle.

A Gartner prevê que 75% dos aplicativos usarão agentes de IA até 2028 – como você antecipa que a Blaxel evoluirá à medida que os agentes de IA se tornam ubíquos em várias indústrias?

À medida que os agentes se tornam mainstream, esperamos que a Blaxel evolua de ser “infraestrutura para agentes de IA” para ser “a camada de operação” em que eles dependem – lidando com ciclo de vida, coordenação e até interações de marketplace. Você não apenas implantará agentes na Blaxel – você os comporá, monitorará e terá agentes que gerenciam outros agentes. Já estamos vendo casos de uso emergir em finanças, segurança e automação de empresas que apontam nessa direção.

Você vislumbra um futuro onde os agentes não apenas executam aplicações – mas gerenciam e reconfiguram infraestrutura de forma autônoma? Quais são as implicações culturais e de segurança dessa mudança?

Sim, e é ao mesmo tempo emocionante e inquietante. Tecnicamente, faz sentido – os agentes podem monitorar a saúde do sistema, aplicar patches, otimizar cargas de trabalho. Mas culturalmente, isso desafia a forma como pensamos sobre controle e confiança nas operações. Do ponto de vista de segurança, significa repensar modelos de permissão: não apenas quem pode agir, mas o que um agente é permitido se tornar. Vamos precisar de novas abstrações para autonomia verificável e auto-aperfeiçoamento restrito.

Qual é o maior mal-entendido sobre o que torna a infraestrutura nativa de agente única?

Que é apenas sobre mais GPUs ou tempos de execução mais longos. A infraestrutura nativa de agente é sobre affordances comportamentais – dando aos agentes a capacidade de lembrar, explorar, adaptar e recuperar. Isso requer mudanças em toda a pilha: armazenamento que rastreia o estado em evolução, modelos de execução que suportam concorrência e ramificação, observabilidade ajustada para raciocínio, não apenas latência. É uma mudança de mentalidade, não apenas um aumento de recursos.

Qual é o arrependimento técnico ou limitação de sua época na OVHcloud que você está mais feliz em corrigir na Blaxel?

Na OVHcloud, muito do que construímos foi limitado por abstrações legadas – VMs, contêineres, redes – otimizados para cargas de trabalho impulsionadas por humanos. Não pudemos facilmente romper com esses paradigmas. Com a Blaxel, estamos começando do zero. Não há necessidade de fingir que um agente é um trabalho em lote ou um microserviço. Podemos construir primitivos como memória, ferramentas e metas diretamente no tempo de execução – e isso desbloqueia um novo espaço de design.

Obrigado pela grande entrevista, leitores que desejam aprender mais devem visitar Blaxel.