Mistral made agents durable across crashes. Make resumability visible

THE SIGNAL IN ONE SENTENCE

A long-running AI agent has a special talent for turning a small uncertainty into a large invoice. Imagine an agent preparing a refund. It calls the payment service. The service sends the money. Before the response is recorded, the worker crashes. The agent wakes up at its last finished checkpoint and tries the tool call again. Congratulations. The customer has now received two refunds, the finance team has received one mystery and somebody has learned that “durable” does not mean “exactly once.” That is the practical edge inside Mistral's November 5 release of Managed Agents and the Agents SDK. Mistral says developers can define an agent once in Python, including its model, instructions, tools and environment, then run that same definition inside an application, on self-hosted infrastructure or as a Mistral-managed worker. The managed and self-hosted modes add durable sessions, background execution, approval waits, per-session environments and tracing. The headline feature is continuity. A deployed task can run for hours or days, continue after the application that started it exits and resume from its last finished model call or tool call after a worker failure. That solves a real infrastructure problem. An agent that researches suppliers, updates a software repository, reconciles records or prepares a compliance package may need hundreds of steps. Keeping one process alive for the entire job is brittle. Storing every completed step separately lets another worker pick up the session instead of starting from the beginning. Mistral's documentation calls the product a public preview. It says the API, behavior and limits can change, and updates may require code changes. That label matters because durability is not a cosmetic feature. It becomes part of the application's failure model. The docs describe a session as a record of messages, model calls, tool calls and results. Deployed sessions are stored by Mistral instead of inside the worker process. Each finished model call, tool call and sandbox operation becomes a checkpoint. If a worker dies, another process can resume from the last completed checkpoint. The awkward phrase is “last completed.” Work that was in progress when the worker stopped can have an unknown outcome. A remote service may have accepted a payment, sent an email, booked a shipment, changed a permission or created a ticket even though the agent never received or recorded the response. When the session resumes, repeating that action may be correct, harmless or catastrophic. The runtime cannot infer which one from vibes. Mistral's own run-mode documentation recommends idempotency keys for tools with external effects. An idempotency key gives the called service a stable identifier for the intended action. If the same request arrives again, the service returns the first result instead of doing the work twice. That is the right engineering pattern, but it needs to become visible to operators. The Plain Signal's practical answer is a resumability ledger. The ledger is not another chat transcript. It is a compact operational record attached to every durable session. It should tell a reviewer where the session was, what the agent intended, which external effects may already have happened, what evidence exists and why the next action is safe. Start with identity. Record the deployment, agent version, session identifier, turn identifier and current step. Include the model, harness, tool package, policy, prompt and environment versions. “The agent resumed” is not enough if the worker woke up with different code, a different model or a new permission policy. Then record the checkpoint. Name the last model call, tool call or sandbox operation that the runtime confirmed. Preserve its inputs, output reference, timestamp and completion state. The raw result can remain in controlled storage, but the ledger should link to it and show whether the next step depends on it. Now capture the uncertain zone. If a crash happened during a tool call, record the intended effect, destination service, request identifier, time sent and every available receipt. A missing response is not evidence that nothing happened. Mark the outcome as unknown until the external system is checked. For every side-effecting tool, assign an idempotency key before the call leaves the agent. Derive it from the business action, not from a random retry. A refund for order 847 should carry the same key every time that specific refund is attempted. A new refund should carry a different key. If the service does not accept idempotency keys, place a uniqueness record in a durable store before acting. The record must reject a duplicate atomically. A friendly “did we do this already?” query is not enough because two workers can ask the question at the same time and both hear no. The ledger should also separate reversible and irreversible actions. Reading a public page can usually be repeated. Writing a local draft can often be replaced. Sending a payment, deleting data, publishing a release or changing access may require a human decision when the outcome is uncertain. That decision belongs outside the model. Managed Agents lets developers require approval for selected tool calls, add messages to a running turn, interrupt work and reopen a stored session later. Because the session is durable, an approval can outlive the application that requested it. The approval record should name the action, evidence, approver, decision, time and scope. “Approved” should not silently authorize a changed amount, destination or tool version after a restart. Sandboxes need the same treatment. Mistral offers a per-session Linux container for agents that need shell or file access. The container has a writable workspace and a configurable lifetime. A session can outlive a worker, but a sandbox has its own expiration. If the sandbox disappears, files, installed packages and uncommitted work can disappear with it. Record the sandbox identifier, image, mounted inputs, network rules, package lock, artifact locations and expiration. Put important outputs in durable storage before the next checkpoint depends on them. Secrets need boundaries too. The same agent definition can move from a laptop to a self-hosted worker or a managed worker. That portability is useful, but the environments should not inherit identical access by default. The ledger should record which secret references and service roles were available during the run, without copying the secret values into the ledger. Tracing adds another tradeoff. Mistral says deployed managed and self-hosted agents send model and tool spans to Studio by default. Prompt and completion content is included unless the operator disables it. Content is redacted before export, but Mistral warns that pattern-based redaction can miss secrets or personal data in unfamiliar formats. That means “redacted” should be treated as a control with limits, not as a magical privacy fog. Record whether tracing was enabled, whether content was included, which redaction policy ran, who can view the traces and how long they are retained. For sensitive workflows, test the redaction policy with representative data or turn content off. Session limits should be visible as well. Mistral's documentation says a deployed session ends by default after four idle hours or 24 total hours, though operators can change the limits within documented maximums. A session waiting only for approval can count as idle. When a limit ends a session, it cannot resume and a new session must start. An operator needs to know whether a session resumed after a crash, restarted after expiration or forked into a new line of work. Those are different histories. Close the ledger with the final state. List completed external effects, unresolved outcomes, compensating actions, approvals, produced artifacts, remaining risks and the person or system that accepted the result. If the session was cancelled, say which steps had already escaped into the world. This is not a complaint about durable agents. It is the opposite. Durability is what makes agents useful for work that takes longer than a browser tab's attention span. It also exposes the fact that a workflow is more than a string of model messages. It is a sequence of real effects across systems with different ideas about retries, identity and time. Mistral has made the session harder to lose. Now teams need to make the resume point harder to misunderstand. Keep the checkpoint. Keep the receipt. Keep the uncertain zone visible. Then let the agent continue without pretending the crash erased what may already have happened.