Mistral Managed Agents is a public preview that lets one Python agent run in three places: in your own process, on your servers with agents serve, or on Mistral with agents deploy. The choice decides where sessions are stored and who runs your tools, so make it deliberately before an agent touches production data.
What Mistral released
Managed Agents was announced by Mistral on 5 November 2026 in the Mistral release notes, alongside an expansion of Mistral Studio that adds managed agents, workflows and hosted apps. Agents are built with the new Agents SDK (mistralai-agents), and the Managed Agents overview states plainly that the API, behaviour and limits can change during the preview.
The same release notes list a set of Studio features that sit around the agents, all in public preview unless marked otherwise:
- Tracing for managed agents: agent, model and tool spans go to Studio by default, and redaction runs on the worker before spans leave it.
- Offline and online evaluations: the
mistralai-evaluationsSDK scores changes against your own datasets, and online evaluations score live sessions to catch regressions. - Datasets from telemetry: a trace span can become a dataset record in one click.
- Webhooks and triggers: events in your tools can start agents and workflows instead of a schedule.
- HTTP API connectors (private preview): register a web API by describing its operations, without building an MCP server.
The Studio announcement also mentions a Mistral MCP server for building with Mistral Vibe or other coding agents, and deployment of Studio itself to cloud, your own VPC, on-premises or a mix.
What changed from the older Agents API
Mistral's earlier agents were a hosted API, client.beta.agents, built around agents and conversations. The new SDK splits an agent into parts you can place separately. The overview names them: the model, which can run on Mistral's API or behind your own gateway; the harness, which runs the agent loop; the session, which records every message, tool call and result; and the environment, a sandbox for shell commands and file edits that an agent does not get unless you give it one.
Turns are durable. After a crash, a turn continues from its last finished model or tool call rather than starting again, and sessions are stateful, so follow-up messages see earlier work. You can add messages to a running turn or interrupt it, and split work across subagents. Mistral points existing users to a migration guide for the older API.
Where each run mode keeps your data
This is the part to settle first, because the modes are not equal on data handling:
- Local:
agents.Agent(...)in your code oragents chat. The session lives in your process. Good for development and tests. - Self-hosted:
agents serveon your own servers. Your infrastructure runs the harness and tools, but the overview says Mistral stores the session. - Mistral-managed:
agents deploy. Mistral runs the harness and your tools, and you host nothing.
Our reading: "self-hosted" here does not mean the transcript stays on your side. If a contract or regulator says agent transcripts must stay inside your estate, self-hosting the harness alone does not meet that, and you need to confirm with Mistral how session storage works for a private deployment. The same check applies to traces, which go to Studio by default. Write the redaction rules before the first real session, not after. Our guide to keeping personal data out of AI agent logs covers what to strip.
Limits that shape agent design
Two defaults in the preview will catch long-running agents:
- Session length: a session ends after 24 hours, or after 4 hours idle, though Mistral says both limits can be raised. An agent that waits on a customer reply overnight needs either a raised limit or a design that starts a fresh session and reloads state. Our post on running AI agent tasks that take days describes the second pattern.
- Approvals: tool calls you mark as needing approval can be answered by your code or by a person, and the turn waits one hour by default, even while your app is closed. Decide what happens when nobody answers in time, and who gets paged before the window closes. If approvers sit in another time zone, the default is too short.
Also note the cost side: the October release notes say Managed Deployments require a paid plan during the preview. Mistral had not published separate Managed Agents pricing on its pricing page when we checked, so budget the model tokens and confirm hosting charges with Mistral before committing.
What it means for teams building agents
For teams already on Mistral models, the main gain is that one codebase moves from a laptop to production without a rewrite, with durable turns, approvals and tracing built in instead of assembled from separate tools. Building your own harness that resumes after a crash and holds a pending approval while the app is down takes real engineering time, and this removes it.
A sensible rollout:
- Build and test locally, with no environment attached, so the agent cannot run shell commands until you decide it should.
- Mark every write action as needing approval at first, and loosen this only once traces show the agent behaves. See human in the loop without friction for how to keep approvals from becoming a bottleneck.
- Turn traces into an offline evaluation dataset before each prompt, model or tool change, and enable online evaluations once you have a baseline.
- Move to
agents serveoragents deployonly after the data question above has a written answer.
If you are comparing hosted agent runtimes, our note on Claude Managed Agents and dynamic workflows covers the same decision on Anthropic's side.
When not to switch yet
- Regulated production workloads: the preview can change its API and limits, and session storage sits with Mistral even when you self-host the harness.
- Multi-provider agents: the only model the overview names is
mistral-large-4, and while the model can sit behind your own gateway, the documentation does not say whether models from other labs are supported. If your agent mixes providers, keep your current harness until Mistral confirms this. - Stable agents on the older API: if a
client.beta.agentsintegration works and needs none of the new features, follow the migration guide on your own schedule rather than mid-quarter.
Frequently asked questions
Is Mistral Managed Agents generally available?
No. Mistral lists Managed Agents and the Agents SDK as a public preview in its 5 November 2026 release notes, and the documentation says the API, behaviour and limits can change during the preview. That makes it suitable for building and piloting, but plan for breaking changes and avoid tying a regulated production workflow to it until Mistral announces general availability and publishes stable limits.
Does self-hosting with agents serve keep sessions on my servers?
Not according to the current documentation. With agents serve, your servers run the harness and your tools, but Mistral states that it stores the session. Only local mode keeps the session in your own process. If transcripts must stay inside your estate for contractual or regulatory reasons, confirm the storage arrangement with Mistral before you choose a production mode.
How long can a Mistral managed agent session run?
By default a session ends after 24 hours, or after 4 hours without activity, and Mistral says both limits can be raised. For work that waits on people, such as customer replies or overnight approvals, either ask for higher limits or design the agent to save its state, end the session and resume in a new one when the next event arrives.
What happens to a tool call waiting for approval?
The turn pauses and waits for your code or a person to approve or reject the call. By default it waits one hour, and it keeps waiting even if your application is closed. Plan for the case where nobody answers: decide whether the call is rejected, retried or escalated, and make sure the right approver is alerted early enough to respond in time.
Do I need to rewrite agents built on the older Agents API?
The older API is client.beta.agents, and Mistral provides a migration guide to the new Agents SDK. The new model separates the harness, session and environment, so expect to restructure how state and tools are wired rather than rename a few calls. If your current agent is stable and needs none of the new features, migrate on a planned schedule after testing.
