Mistral Studio’s new agents can resume work. Where they run still matters.

Mistral expanded Studio on November 5 with managed agents and apps, alongside workflow and evaluation tools. The release notes label Managed Agents as a public preview: Python agents can run in the background, keep session state and resume from a completed step after a crash. That addresses a practical problem with long tasks—work outliving the process that started it.

For a team automating document checks or internal requests, the attraction is less infrastructure to assemble around a model. The deployment choice still determines where tools execute and where state is kept. Running a worker on your own machine is not, by itself, proof that the whole system is isolated there.

An agent chooses a step; a workflow owns the procedure

Mistral’s announcement groups three building blocks together. Agents investigate and act using tools; workflows coordinate the process, including approvals; apps give people an interface. The release also adds a workflow builder and reusable app components, rather than presenting every business process as a conversation.

The developer comparison makes the distinction more precise: an agent’s model chooses its next step from its instructions, context and tools, while workflow code defines the rules of execution. A single project can use both, with an app for people to review results.

Consider an illustrative document-intake service. A workflow can apply fixed routing rules, an agent can investigate an ambiguous submission, and a person can review the proposed result. That is a design example, not a demonstrated Studio deployment or a measured productivity gain.

Three execution paths do not apply equally to every component

The current Studio overview lists agents and workflows on Mistral Cloud or customer infrastructure, while apps run on Mistral Cloud. That narrower component-level statement is more useful for planning than assuming every feature shares the same hosting options.

For agents serve, the developer runs a long-lived worker on their machine or cluster. That worker executes the agent loop and its tools, while Mistral stores the session and queues the turn. The documentation also says turns are traced to Studio by default.

Editorial visualization

A deployment review therefore needs separate answers for tool execution, model inference, session storage and traces. A label such as self-hosted worker answers only part of that question. Teams with data-location requirements should verify the complete arrangement for the product and contract they intend to use.

Resuming a task does not guarantee a side effect happens once

Mistral’s self-hosting guide says a stopped worker can usually resume from its last completed step. It also warns that, although the SDK does not repeat an in-flight tool call itself, the model may call that tool again. Tools should be idempotent—designed so repeating a request does not create an unintended duplicate effect.

For the document-intake example, that means giving a submission a stable identity and checking whether its destination record already exists before creating another. A recovered conversation is helpful; preventing duplicate external records is still an application responsibility.

Editorial visualization

Approval is another configured part of the process: an agent permission policy can pause a tool call for approval, and a workflow can wait for a person’s decision before continuing. Managed hosting does not specify which actions the team should authorize. That boundary belongs in the application’s policy and tests.

Mistral also lists observability and evaluations as Enterprise-tier features. Its announcement includes internal examples and time-saving claims, but UpThat has not independently reproduced those results or tested crash recovery. The documented capabilities establish what developers can evaluate, not a universal reliability result.

A useful pilot would deliberately stop a worker, resume an unfinished task, reject one proposed action and retry a request that would otherwise create a duplicate. Those cases reveal whether the surrounding system preserves the team’s rules when the easy path ends.