Mistral Managed Agents public preview: run modes and recovery limits

What is in public preview, and where should it run?

Mistral’s current release notes label Managed Agents a November 5, 2026 public preview. The linked Agents overview independently confirms public preview for both Managed Agents and the Agents SDK. APIs, behavior and limits can change, and an update may require code changes. This is not a stable-release or universal account-access guarantee.

An agent uses model responses to choose its next step and call tools. The harness is the program running that loop. In-process mode keeps the loop, tools and session in your program, making it useful for development, tests and short scripts. Sessions normally end with that process; using the same SDK does not move them to the cloud automatically.

Choose agents serve to run a worker on your own machine or cluster when tools need to be near internal systems. Choose agents deploy when you want Mistral to run the worker. Mistral’s control plane stores sessions in both deployment modes. Self-hosting does not mean that model execution and session records stay entirely on your machine.

How do permissions and the deployed code line up?

Official onboarding requires a GitHub repository for the project and a GitHub connection in Mistral Studio. The user behind the API key also needs a workspace role with Workflows access, such as Developer or Workspace Contributor, assigned by a workspace administrator. The public-preview label does not replace that permission.

Review and commit the project, then push the intended branch. agents deploy builds the pushed commit, not uncommitted files on your computer. It refuses unpushed commits or a branch without an upstream. Check the repository, revision and Dockerfile shown by the CLI; finishing a local edit does not establish a deployed change.

An agent name is unique within a workspace. A later deployment with the same name replaces that agent. Check the name and existing work before updating it; copying an example should not overwrite an agent handling active work. After deployment, inspect agents list and separately check a session’s actual output. This article did not install the SDK or deploy an agent.

Why can an external action repeat after a crash?

A deployed session records completed model and tool calls. After a worker stops, a turn usually continues from its last finished step when a worker is available. It can also fail or remain Running until its time limit. Durability is not a guarantee of recovery.

Work that was running without a recorded result has an unknown outcome. The documentation says a model call is made again. Recovery does not directly rerun the interrupted tool call; about a minute later, the model receives an error and may call the tool again. An email, refund or order-creation action can therefore happen twice.

Give such tools an idempotency key derived from the original request identity: the same request returns its original result instead of acting again. Where a service offers no key, the tool needs durable state and concurrency controls to prevent duplicates. A separate “has this happened?” check cannot stop two simultaneous calls from both proceeding. Reconcile the original operation before continuing its session; repeatedly creating new tasks is not recovery.

What do the lifetime, idle and approval limits mean?

Deployed sessions default to ending after 24 hours in total or four hours idle, whichever comes first. Total lifetime starts at the session’s first run. A session is idle when no turn is working or when a turn only waits for a user, app or approval response. It is not idle while one of its subagents works for it.

Configured ceilings differ by mode. Mistral-managed agents deploy supports at most 24 hours idle and one week in total; self-hosted agents serve allows both limits to be configured up to one year. These are configuration ceilings, not promised successful runtimes.

A wait for human input has a separate one-hour default limit; an approval left until the next morning may no longer continue. The execution timeout must exceed the total lifetime limit by more than five minutes, and existing sessions keep the execution timeout they started with. MistralSandbox has its own 24-hour default lifetime: check its ttl_seconds for longer sessions. Raising one limit does not raise the others.

At a session limit, a running turn returns Interrupted and its subagents stop. The documented termination causes include lifetime_limit and idle_limit. A session ended by a limit cannot resume. Reconcile any original external actions before starting a new session, and do not interpret every Interrupted result as a service incident.

How do you find the original work or actually stop it?

To let your app exit while work continues, follow the documented background-running approach and retain the session and turn IDs for later result retrieval. Load the deployed agent by name with Agent.load_from, then bind the original session with agent.session(stored_id). Creating that handle sends no request; a nonexistent ID is discovered on the first request.

Use turn.interrupt() to stop the current turn while keeping its session. Use session.cancel() to end the session and its subagents. For a deployed agent, that call returns when the agent accepts cancellation. Its return alone does not establish that every external action has been reversed. Check session status, termination cause and tool outcomes afterward.

Dropping a handle, closing the client or returning from the method that started a call does not end a deployed session. The session and sandbox can stay open until cancellation or a limit. Handle “the result is available” separately from “the session is no longer needed” so resources are not left behind.

What else should you check before first use?

The overview, run-mode, deployment and session pages reviewed here do not establish uniform plan eligibility, hosting rates or a complete region list for this Managed Agents preview. Confirm them for your workspace through official billing and contractual information before adoption. Public preview does not mean free hosting, and another product’s allowance cannot be assumed to apply.

Deployed modes enable Studio traces by default, including prompt and completion content. Before submitting internal material, check recording scope, retention arrangements and tool permissions. Provide only the tools, connectors and environment the agent needs, and check whether the network where the tool actually runs can reach the authorized service.

These checks concern product access, process location, data boundaries and task state. Investigate networking when evidence points to DNS, TLS or timeouts. A different proxy exit cannot add workspace eligibility or hosting allowance, or bypass regional and access rules.