Mistral expands Studio with AI agents and business applications

Mistral announced an expansion of Studio, its platform for building business AI applications, on November 5. The update introduces managed agents, tools for internal applications and additions to process automation. They share infrastructure for accessing company systems, running tasks and examining the operations performed by AI.

Access stages differ between components. The release register lists Managed Agents, the workflow builder, Apps tools, offline evaluations and the search index as public previews. HTTP connectors are in private preview. The announcement therefore combines features undergoing public testing with restricted-access features, each with its own usage conditions, within a platform that already existed before this update.

Agents that retain the history of a task

With Managed Agents, developers specify the model, instructions, tools and access boundaries. Each session records messages, tool calls and results. Execution deployed through Studio can continue in the background and resume after an interruption from the last completed step. Selected operations can require a person's approval, and an application can intervene in an active session. The same code can be used during development, on company infrastructure or in a configuration managed by Mistral.

Workflows organize processes whose stages include AI calls, external services and human decisions. The platform retains execution history, handles retries and allows a process to wait for a response before continuing. In the documented hybrid configuration, code and workers run in the customer's environment, while Mistral hosts the orchestrator. Enterprise customers also have the option of running the Studio environment in a private cloud or on their own infrastructure. Workflows remains in public preview.

The builder in Vibe Code Web lets users describe a process in ordinary language. The agent produces code, tests it and can deploy it as a managed workflow. A graph of the stages appears beside the conversation, while the code remains available for inspection and editing. The resulting workflow is stored in a Git repository and can subsequently be taken over for local development. The connection to Studio uses the Mistral MCP server, whose tools are available directly in Vibe Code Web sessions.

Internal applications with interfaces and access controls

Apps groups an application's resources into one project: a web interface, an API, a database, agents and workflows. Studio supplies hosting, authentication and access controls. An interface is optional; automation running entirely in the background can be organized directly as a workflow. Components can be added or removed as the project develops. This structure relates to business application development that brings user access and process execution together in the same product.

Access to app creation depends on the organization's plan. The documentation specifies three apps for organizations with pay-as-you-go enabled and ten for Enterprise. Free plans and Pro or Team plans without that option have a limit of zero. Apps across all of an organization's workspaces count toward the limit. Each app can have up to three frontend and backend components combined; its workflow worker does not count toward this threshold.

API connections and credential management

HTTP connectors turn an API's operations into tools available to agents and workflows by importing an OpenAPI specification. Versions 3.0, 3.1 and 3.2 are supported, with API key authentication, OAuth or no authentication, according to the connected service's requirements. The interface identifies convertible operations and import problems. Individual tools can be enabled or disabled. The feature is announced in private preview, so the existence of documentation does not mean access is available to every Studio account.

Secrets Manager keeps keys, tokens and other credentials separate from code. Secrets belong to a workspace, and roles control their administration. Values are masked in the console after creation; authorized workloads read them through the API, with access recorded. A new value creates a new version. Workloads already running retain their initial value until they restart, when the reference is resolved again. This service is also documented as being in public preview.

Company data and the execution environment

Search Index adds managed storage for document passages consulted by agents and workflows. An organization chooses the embedding model and the fields used for searching or filtering. Retrieval can combine vector search, keywords and structured filters, for example by product or publication date. Search Toolkit handles passage preparation and retrieval, while the index provides hosted storage. Access is tied to the workspace and the permissions assigned to the index.

The documentation separates the choice of execution infrastructure from the choice of where the AI model runs. In self-hosted mode, the company operates workers and Mistral orchestrates them. In managed mode, the provider builds, runs and recovers the application. Running the entire Studio platform on company infrastructure is a separate option from hosting one's own workers. The distinction specifies which part of the system remains under customer administration and which part the platform supplies.

Evaluations and visibility into operations

Offline evaluations use a set of cases, a function that performs the task and evaluators that score its output. Results can be tracked locally or organized in Studio by projects, evaluations and runs. Version comparisons and examination of individual cases are available. The documentation reserves observability and offline evaluations for Enterprise organizations and labels evaluations as public preview. Scores belong to the tests and criteria defined by the organization; the platform stores them alongside results and execution metadata.

Studio test datasets are mutable, and each run reads the records present when it starts. Subsequent edits affect future runs. The documentation calls for keeping content unchanged between tests for comparisons over time and recommends representative cases, including difficult situations. A run exceeding 10,000 records is rejected before it starts. If the list changes while it is being read, evaluation stops before execution to avoid using an inconsistent dataset.

Distributed tracing exposes the sequence of operations, inputs, outputs, latency, token counts and the status of each stage. The system uses OpenTelemetry, and the documentation specifies a 30-day retention period for these records. Inspecting them makes it possible to locate the particular call where an error or delay occurred, rather than displaying only the application's final response.

For exporting this data, Mistral applies redaction by default on the machine producing the records. The standard policy looks for known patterns of credentials and personal data; strict mode additionally masks entire values associated with sensitive fields. Custom policies are available in the SDK. In an OpenTelemetry pipeline operated separately by the company, redaction must be configured within that pipeline. These controls specify which information is sent for observability and how it is treated before export.