Mistral amplió Studio el 5 de noviembre de 2026 con agentes gestionados, aplicaciones y nuevas funciones para procesos y evaluación. Para un equipo que necesita mantener un agente en marcha mientras espera una aprobación o se recupera de un fallo, la novedad principal es Managed Agents. Tanto el servicio como su SDK están en vista previa pública: la documentación advierte de posibles cambios de API, comportamiento y límites.

El anuncio general habla de despliegues en distintas infraestructuras. Antes de trasladar esa promesa a una integración concreta, conviene mirar dónde ejecuta cada componente y dónde guarda el historial. No es otro lanzamiento de los pesos de Large 4, que ya analizamos al explicar sus condiciones de licencia y despliegue.

Tres modos que guardan los datos en lugares distintos

Según la documentación de Managed Agents, el SDK mistralai-agents permite definir el modelo, las instrucciones, las herramientas y el entorno, y llevar ese agente a tres modos de ejecución:

  • Dentro del proceso de desarrollo: el bucle del agente y sus herramientas se ejecutan en el programa Python; la sesión vive en memoria y se detiene con el proceso.
  • Autoalojado con agents serve: el motor y las herramientas se ejecutan en los servidores propios, pero Mistral almacena la sesión.
  • Gestionado con agents deploy: Mistral ejecuta el motor y las herramientas y almacena la sesión.

Por tanto, autoalojar el trabajador no significa que todo el sistema o sus registros permanezcan dentro de la red propia. La documentación también permite usar el modelo detrás de una pasarela propia; eso no cambia automáticamente dónde se conserva la sesión. Hay que evaluar cada componente y sus datos antes de conectar información sensible.

Recuperar el trabajo no equivale a evitar cualquier duplicado

En los modos desplegados, Mistral documenta ejecución en segundo plano y recuperación desde la última llamada al modelo o herramienta que terminó. También permite configurar aprobaciones y consultar trazas con un registro por llamada.

La durabilidad tiene límites: por defecto, una sesión termina tras 24 horas, o tras cuatro horas de inactividad cuando no hay un turno ejecutándose o este solo espera al usuario. Esos límites se pueden ampliar; la espera de una aprobación tiene un plazo predeterminado de una hora. «Puede trabajar durante días» no debe interpretarse como una sesión ilimitada sin configuración.

Como ejemplo hipotético, no ejecutado, un agente de soporte podría leer un incidente, proponer un reembolso y esperar autorización. El sistema de pagos necesitaría su propia protección contra duplicados y una forma de consultar resultados inciertos. Guardar la sesión del agente no demuestra que un efecto externo se ejecute exactamente una vez. Nuestra guía de aprobaciones versionadas desarrolla esa separación entre autorizar una propuesta y controlar sus reintentos.

Studio reúne funciones con estados diferentes

Las notas del 5 de noviembre sitúan el constructor de workflows, la nueva CLI de aplicaciones y las evaluaciones con SDK en vista previa pública. Los conectores HTTP están en vista previa privada. El anuncio conjunto no convierte todas las funciones en disponibilidad general.

Estos conectores HTTP importan una especificación OpenAPI y convierten operaciones compatibles en herramientas, sin exigir construir un servidor MCP. Admiten OpenAPI 3.0, 3.1 y 3.2, no Swagger 2.0; además, los permisos de OAuth deben corresponder a las operaciones que se quieren importar. Generar herramientas no concede permiso para ejecutarlas.

Para decidir un piloto, la pregunta útil es qué proceso necesita recuperación, qué acciones requieren aprobación y qué información puede almacenarse en Mistral. Puntoes no ha desplegado estos servicios ni medido su fiabilidad o sus costes; esta noticia contrasta el anuncio con sus condiciones técnicas actuales.

Fuentes

Sigue explorando