How Mistral Managed Agents Work in Production

On November 5, Mistral added Managed Agents to Mistral AI Studio, built with a new Python Agents SDK. Mistral runs the agent loop, keeps each session's history, and waits for approvals, the way Anthropic's Claude Managed Agents and OpenAI's Agents API do. It adds hooks, subagents, sandboxes, and three ways to run the same agent, including on Mistral's infrastructure. It's in public preview.

What decides whether it fits a production agent is in the details. You need to know which parts Mistral runs no matter how you deploy, how long a session and an approval can last, and what a crash or a redeploy does to a running turn. Those details are spread across Mistral's docs, so this post collects them in one place.

What Managed Agents Is

An agent is a Python object. Tools are typed Python functions, and a permission policy decides which calls run, which ask a person first, and which are refused:

from mistralai import agents
@agents.toolasync def get_alert(alert_id: str) -> dict:    """Read a transaction monitoring alert."""    ...
@agents.toolasync def open_case(alert_id: str, summary: str) -> str:    """Open a case file for an alert."""    ...
reviewer = agents.Agent(    model="mistral-large-4",    name="payment-reviewer",    instructions="Review payment alerts and open a case when one looks suspicious.",    tools=[get_alert, open_case],    permission_policy=agents.PermissionPolicy(        default="deny",        rules=[            agents.PermissionRule(tools=["client.get_alert"], decision="allow"),            agents.PermissionRule(tools=["client.open_case"], decision="ask"),        ],    ),)

Hooks run before and after each turn, model call, and tool call. They can rewrite inputs or outputs, skip a call, retry the model with feedback, or reject a response, and they keep state across turns. Subagents run in the background and report back to the agent that started them, which replaces the handoffs of Mistral's older Agents API.

One design choice stands out. By default the model doesn't call your tools one at a time. It writes TypeScript in a built-in run_typescript tool and calls them from that code, so it can chain several calls in one step. You can switch a tool to direct calls when you need to.

For commands, an agent gets a sandbox. MistralSandbox gives each session its own Linux container on Mistral's cloud, with no network access by default. Local Docker and a lighter sandbox also exist, though only MistralSandbox isolates commands when Mistral hosts the agent.

Where It Runs, and What Mistral Keeps

The same agent runs three ways. The difference is where the loop and your tools run, and where the session lives:

The middle column is the one to read closely. With agents serve, your worker runs the loop and the tools inside your network, but Mistral's docs say its "control plane still stores the sessions and routes each one to a worker, and Mistral serves the model calls." The agent's configuration goes to Mistral by default too. Self-hosting moves the work, while the state stays with Mistral.

Running the whole Studio platform yourself is a separate Enterprise offering with its own gated docs. Mistral says Managed Agents reaches private cloud and on-premises deployments at the end of November.

What Survives a Crash, a Deploy, or a Long Wait

Underneath, deployed sessions run on Temporal, so every finished model call and tool call is recorded and the loop replays from that record. That's why Mistral asks you to use agents.now(), agents.uuid4(), and agents.sleep() instead of the standard library inside the loop: a replay has to make the same choices.

Crashes. When a worker dies mid-turn, the turn "usually resumes from its last finished step once a worker is back. It can also fail, or stay Running until its time limit." The interrupted model call runs again. The interrupted tool call doesn't, but about a minute later the model gets an error for it and may call the tool again. Mistral's docs say plainly that a tool with side effects can run twice, so every such tool needs an idempotency key.

Deploys. agents deploy builds a pushed commit from a GitHub repository. Each new commit becomes a new agent with a new id, and open sessions run their next message on the new code. A turn that's running during a redeploy "can fail, or stay Running", so the docs suggest redeploying when nothing is running. Rolling back means deploying the earlier commit.

Session limits. A session ends after 24 hours by default, or after 4 hours idle. Deployed on Mistral, the maximum is a week. With agents serve, it's a year. A session that hits a limit can't resume.

Approvals. An approval waits one hour by default. If nobody answers, the call doesn't run and the turn continues. An environment variable raises the timeout, and the wait counts toward the session's idle limit. Approvals can be answered from your code or by a person from any process or client that opens the session, and when two people answer at once, one answer counts and both see which.

Data, Models, and Price

Data. Mistral's zero data retention doesn't apply to Agents, Conversations, or traces sent to Studio. Agents aren't available on Mistral's EU or US regional endpoints, and the docs note that "regional inference does not make the Mistral control plane regional." Mistral's sandboxes run in the Netherlands by default. Traces include prompt and completion content after pattern-based redaction, which the docs warn can miss secrets, and viewing them in Studio Observability needs an Enterprise plan.

Models. Agents default to Mistral's models, such as Mistral Large 4. Mistral also hosts GLM 5.3 and DeepSeek V4.1 Flash, and the agent reference lists "openai" and "anthropic" as providers, though the docs don't explain how to set them up. Mistral reports Large 4 at 41% on Terminal-Bench 4.0.

Price. Model tokens bill at Mistral's API prices. Mistral hasn't published a price for the agent runtime, managed deployments, or MistralSandbox containers. Managed deployments need a pay-as-you-go or Enterprise plan, which Mistral's workflow docs cap at 3 and 10 running deployments.

Source. The Agents SDK on PyPI is Apache 2.0, but it depends on Mistral's agent harness, a compiled package licensed as proprietary. There's no public source repository for the SDK, and the control plane is closed.

Coming From the Agents API

Managed Agents is Mistral's third agent product in about two years, after Le Chat agents in 2024 and the Agents API in 2025. The Agents API (client.beta.agents and client.beta.conversations) is "about to be deprecated", with no date yet.

Moving over changes more than the client calls. The Agents API's built-in web search, document library, and image generation become tools you write that call the Conversations API. The code interpreter becomes a sandbox. Handoffs, where one agent took over the conversation, become subagents that report back. Version pinning becomes deploying the commit you want.

Where Managed Agents Fits

Managed Agents has real strengths, and most of them come from treating the agent as code.

• A loop you can program. Hooks at every step can rewrite, retry, skip, or reject, and guardrails are hooks that run first. That's closer to a framework like Mastra than to a hosted API, with Mistral keeping the sessions durable.
• Fewer round trips on tool-heavy steps. Because the model calls tools from TypeScript it writes, one step can chain several calls instead of spending a model call on each.
• A front end you don't build. A deployed agent opens in Vibe Code Web at chat.mistral.ai/managed-agents/<name>, and connectors from Mistral's catalog act as the user who runs the session. For an internal agent at a company already on Vibe, that skips the UI and the sign-in work.
• One vendor and one contract. Companies that already buy Mistral's models get the agent runtime from the same European vendor, with on-premises deployments due at the end of November.
• Quick experiments. In-process mode needs no setup at all, as long as the session can die with your program.

Where It Gets Hard

The preview's defaults decide a few common cases, and they're worth checking before you build.

An approval over a weekend. An approval waits one hour by default, and while it waits, the session counts as idle. On a Mistral-managed deployment, the idle limit goes up to 24 hours at most, so a request sent on Friday evening can't wait for Monday. With agents serve, both limits go up to a year, but then you run the workers.

A conversation that lasts a month. A deployed session ends after a week at most, and it can't resume after that. The docs describe no memory that carries across sessions, so an agent per customer or per account has to start new sessions and bring its own context forward.

A fix in the middle of a conversation. Changing an agent means pushing a commit, and every open session runs its next message on the new code. A turn that's running during the redeploy can fail. The docs describe no way to change the prompt or tools of one running session on its own.

Data that has to stay in the EU. Sessions, agent configs, and traces live in Mistral's control plane, which isn't regional, and zero data retention excludes agents. Until the on-premises version ships, a strict EU-only requirement rules out the hosted control plane, even with your own workers.

Hard agentic work. Mistral reports Large 4 at 41% on Terminal-Bench 4.0, where Claude Code with Claude Opus 5.5 scores about 65%. Managed Agents lists OpenAI and Anthropic as providers, but its docs only show Mistral's models, so closing that gap is left to you.

A budget. With no published price for the runtime or sandboxes, a forecast covers tokens only. Pay-as-you-go accounts can run three managed deployments at once.

How Omnara Compares

Omnara is an open-source managed agent platform, and it has the same shape as Managed Agents. Each finished step is saved as it happens, and after a crash another worker continues the agent from its last saved step. A tool call that a crash cut off isn't rerun. It comes back to the agent as interrupted, with its outcome unknown, so the agent can check before trying again.

The cases above work differently:

• The weekend approval. Approvals wait in Postgres as long as a person needs and hold no worker. Nothing about the agent times out while it waits, and someone can answer through the API, the dashboard, or Slack.
• The month-long conversation. An agent keeps one conversation until you archive it, and memory stores carry files across conversations.
• The fix mid-conversation. You change one running agent's model, tools, permissions, or instructions through the API, and it applies at that agent's next model call. Deploying Omnara or your own app never loses an agent's progress, and custom tools run in your backend in any language.
• The EU requirement. Omnara is open source under Apache 2.0, including the agent loop, the session history, and the API. Self-hosted in an EU region, nothing goes to Omnara, and with a model you host, prompts never leave your infrastructure. Omnara's team can also deploy and manage it in your own cloud (BYOC) or on premises.
• Hard work. Omnara works with models from OpenAI, Anthropic, OpenRouter, Amazon Bedrock, or any compatible endpoint, on your own keys, and each subagent can use a different one. A cheap Mistral model through OpenRouter can triage while a frontier model handles the hard steps. On Terminal-Bench 4.0, Omnara's own loop matched the pass rates of Claude Code and Codex on the same models, and its 69.6% with Claude Opus 5.5 is the top score (traces).
• The budget. Omnara Cloud has no platform fee, and your own model keys and machines cost nothing. Models bought through Omnara cost the provider's token rates, and its machines are billed by usage. Both are paid with credits that carry a 5% service fee covering provider costs.

Which One to Use

Managed Agents fits a Python team that builds on Mistral's models, wants hooks in code, and is happy for Mistral to hold the sessions within the preview's limits. It fits best for internal agents at companies already on Vibe or a Mistral Enterprise contract, especially once the on-premises version ships.

For agents in production that people depend on, choose Omnara. The whole platform is open source and can run on your own infrastructure, on any model, with published pricing. Its conversations and approvals last as long as the work does, and you can fix one running agent without a deploy.