On this page · 11 sections
- What Mistral actually announced
- The 86% belongs to a Z.ai model, not a Mistral one
- The doc cites a launch post that has no benchmarks in it
- The part that actually breaks a deployment
- What it costs, on published rates
- If you need residency, self-host the index
- India-specific considerations
- What is still unknown
- FAQ
- How eCorpIT can help
- References
Summary. Mistral published Agentic Search on 20 August 2026, nine days after telling enterprises on 11 August that they could pin inference to Europe or the United States. The two announcements do not fit together. Agentic Search reaches most buyers through Libraries, and Libraries is built on the Agents and Files APIs. Mistral's own regional inference page states that "stateful features, including Agents, Batch, and the Files API, are not available on regional endpoints." The zero data retention page repeats the exclusion by name: ZDR "does not apply to" Agents, Conversations, Libraries or /v1/files. So the product Mistral built for confidential documents runs on neither of the two controls it built for confidential data. The regional endpoint carries a 1.1x upcharge and Priority Tier a 1.75x multiplier, which on Mistral Medium 3.5 moves list input from $1.50 to $1.65 or $2.63 per million tokens.
What Mistral actually announced
The Agentic Search post is dated 20 August 2026. It describes a multi-step retrieval loop built on five tools that behave like file-system operations: search, open, navigate, read and grep. The pitch is that one-shot RAG answers from whatever chunks the first retrieval returned, while an agent can open the document, walk to the right table and check the number before answering.
The headline numbers are large. Mistral reports "3x correctness on financial filings, from 26.7% to 86%" on FinanceBench, a "+45.6 point" gain on OfficeQA Pro from 6.3% to 51.9%, p90 latency down "up to 39.6%", and token consumption down by up to one-third.
FinanceBench (Islam et al., 2023) covers 368 SEC filings and 150 questions, averaging about 147 pages per filing and roughly 53,900 pages in total. OfficeQA Pro is 696 US Treasury Bulletins across about 89,000 scanned pages, scored on a 133-question subset. Both are genuinely hard corpora, and Mistral says it ran them on the default Search Toolkit stack with no tuning.
Nine days earlier, the sovereignty post of 11 August made Regional Endpoints generally available and put Priority Tier into public preview. Matan Grinberg, CEO and cofounder of Factory, is quoted there: "Different workloads need different models, and that will keep changing as the frontier evolves. Mistral allows us to run open models under strict regional controls and service commitments, making it easy for us to maintain data residency and compliance requirements while furthering our commitment to open source". That is the promise a buyer reads. The docs say something narrower.
The 86% belongs to a Z.ai model, not a Mistral one
Read past the summary card and the headline splits in two. Mistral benchmarked two models: its own Mistral Medium 3.5 and Z.ai's GLM-5.2, the first third-party open model it agreed to host.
On FinanceBench, moving from one-shot RAG to a search-only loop lifts accuracy by 47.3 points for Mistral Medium 3.5 and 52.6 points for GLM-5.2. Adding the navigation tools lifts it again, by 8.7 points and 6.7 points respectively. Start both from the stated 26.7% baseline and the arithmetic lands in two different places.
| FinanceBench configuration | Mistral Medium 3.5 | Z.ai GLM-5.2 |
|---|---|---|
| One-shot RAG baseline | 26.7% | 26.7% |
| Gain from search-only agentic loop | +47.3 points | +52.6 points |
| Additional gain from navigation tools | +8.7 points | +6.7 points |
| Implied full-loop accuracy | 82.7% | 86.0% |
| Token change, full loop vs search-only | -23.9% | -33.7% |
The 86% in the headline is GLM-5.2. Mistral's own flagship mid-tier model lands at 82.7% by the same published deltas. The same pattern repeats on OfficeQA Pro, where the advertised 51.9% is GLM-5.2 and Mistral Medium 3.5 reaches roughly 40.9% from the published +27.1 and +7.5 point gains. Neither number is fabricated and neither is hidden, but a buyer sizing this against an existing pipeline should know which model produced the figure on the poster.
One detail does check out cleanly. The worked example in the post sums twelve monthly 1953 US defence expenditure figures from Treasury Bulletin Table 3 and reports 44,463 million nominal dollars. Add the twelve published values and the total is exactly 44,463.
The doc cites a launch post that has no benchmarks in it
Mistral's Agentic Search documentation restates the results and attributes them to "the Search Toolkit launch materials", linking to Introducing Search Toolkit. That post is dated 28 May 2026 and contains no benchmark figures at all. Its only quantitative claim is that CMA CGM's pipeline "returns alerts within 15 seconds end to end".
The restated numbers also drift. The doc says accuracy improved "from 27% for single-shot RAG to 86%" against the post's 26.7%, says p90 latency fell "by 40%" against 39.6%, and adds two figures the 20 August post never published: OfficeQA token usage "reduced by 1.8x" and a Vibe task shortened "from 368 seconds to 227 seconds". Cite the blog if you need the numbers in a board paper. The doc's own citation points at a page that cannot support it.
The part that actually breaks a deployment
Mistral sells Agentic Search through three doors: the managed Libraries feature in Studio and Vibe, the Search Toolkit SDK, and an MCP server exposing seven tools. Only one of those is a managed service, and it is the one most teams will reach for first.
Libraries are created through client.beta.libraries, filled through a document upload API, and queried by creating an agent with the document_library tool and starting a conversation. Agents, Conversations and file storage, in other words.
Now line that up against the two controls Mistral markets to regulated buyers.
| Surface | Runs on api.eu.mistral.ai | Covered by zero data retention |
|---|---|---|
| Chat completions | Yes, the documented regional example | Yes |
| Embeddings and OCR | Not stated on the regional page | Yes |
| Function calling | Yes, the only supported regional tool | Depends on the endpoint called |
| Other tool calls | No, not currently supported | Depends on the endpoint called |
| Agents and Conversations | No, stateful features are excluded | No, listed as out of scope |
Libraries and /v1/files |
No, stateful features are excluded | No, listed as out of scope |
| Self-hosted Search Toolkit index | Not applicable, runs on your infrastructure | Not applicable, no Mistral retention |
The regional inference page is explicit on both counts: "Not all tool calls are currently supported. Function calling is the only supported regional tool," and "Stateful features, including Agents, Batch, and the Files API, are not available on regional endpoints." It tells you to check availability yourself before sending production traffic, because "regional endpoints only serve models hosted in that region" and "available models vary by region." It also warns that if a workload depends on an unsupported feature, "the regional processing guarantees for that workload do not apply," and that the control plane stays global regardless: account configuration, API keys, billing, access management and usage analytics "may still be handled by Mistral systems outside the selected inference geography."
The zero data retention page lists ten eligible stateless endpoints and then names the exclusions directly: Agents, batch processing files, Conversations, Libraries, /v1/files, Vibe Work and Chat. ZDR is also not self-serve. It is available on paid plans, requested through support with a stated "legitimate reason", and Mistral says it reviews each request and "may approve or deny it."
The 11 August post already hedged the residency claim in its own body, noting that in-region processing is "subject to limited, safeguarded transfers to sub-processors that may occur outside that region". Read together, a buyer who wanted Agentic Search over confidential filings, pinned to the EU, with no retention, cannot have all three through the managed path today.
What it costs, on published rates
Mistral's pricing page lists Mistral Medium 3.5 at $1.50 per million input tokens, $0.15 cached input and $7.50 output, as of 21 August 2026. Mistral Large 3 is $0.50 / $0.05 / $1.50 and Mistral Small 4 is $0.15 / $0.015 / $0.60.
Two multipliers sit on top. Regional inference is "billed at 1.1x standard list pricing (a 10% upcharge) for input tokens, output tokens, cached reads, and cache writes". Priority Tier is "1.75x standard list pricing, which is a 75% premium on input, output, and cached tokens", and it is the only tier carrying an uptime SLA, published as 99.5%. Batch and Standard both read "Not available" in that row.
| Tier | Published multiplier | Mistral Medium 3.5 input, per M tokens |
|---|---|---|
| Standard, global endpoint | 1.0x | $1.50 |
| Standard, EU or US regional endpoint | 1.1x | $1.65 |
| Priority Tier, global | 1.75x | $2.63 |
| Batch | Not stated as a multiplier | Not stated |
| Cached input, standard | One tenth of input on every listed model | $0.15 |
The last two columns are arithmetic on Mistral's published list rates, not quoted prices. The docs publish the two multipliers separately and the Priority Tier availability row reads "Global or regional, depending on account setup, model, and capacity", so confirm the combined regional-plus-priority rate with Mistral before you model it.
Two operational details matter more than the headline percentages. Priority Tier defaults to off: omit service_tier and the request is treated as standard_only. And when your Priority Tier limits are exhausted, requests silently fall back to Standard rather than failing, so the only way to know which tier served a request is to read usage.service_tier on every response. If you are already running agentic RAG versus classic RAG cost comparisons, add that field to your logging before you add the tier.
If you need residency, self-host the index
The escape hatch is the Search Toolkit. The 28 May post states plainly that "Search Toolkit is open source and runs wherever your infrastructure does. Cloud, on-premises, edge." The toolkit documentation describes it as "a Python framework for building information retrieval (IR) systems" with swappable components, published on PyPI and requiring Python 3.12 or later, with Vespa available as a storage plugin.
That path keeps the index inside your boundary, but it is engineering work, not a checkbox. The starter app is a Copier template whose prerequisites are a Mistral API key, Docker to run Vespa locally, uv for packages, Copier for scaffolding, and an MCP-compatible agent to drive the loop. Agentic navigation also requires a NavigableIndex with IndexingMode.DOCUMENT_PER_CHUNK so chunks carry source offsets. Your model calls still go to a Mistral endpoint, so the retrieval layer lands in your region while inference residency remains a separate decision governed by the endpoint you call. The real cost here is usually the index operations, not the retrieval code.
India-specific considerations
There is no Indian regional endpoint. Mistral lists exactly two: api.eu.mistral.ai across EU and EFTA data centres, and api.us.mistral.ai across US data centres. An Indian team with a data-localisation requirement gets no help from the 1.1x upcharge, because neither geography is India.
That leaves the same two levers we set out in the DPDP engineering playbook: keep the index and the documents inside your own infrastructure, and treat the model call as a separate processor relationship with its own contractual terms. Self-hosting the Search Toolkit fits that shape well, because the corpus never leaves your VPC and only the query and retrieved spans cross the boundary. The pattern mirrors what we documented for OpenAI zero data retention endpoint limits, where the stateless endpoints were covered and the stateful products were not. Teams already evaluating Mistral on Azure for regulated enterprises should note that the exclusions described here apply to Mistral-hosted endpoints and say nothing about a cloud partner deployment, which carries its own terms.
What is still unknown
Mistral has not published a combined multiplier for regional plus Priority Tier traffic. It has not said whether Libraries will ever reach regional endpoints, or whether the stateful exclusions are permanent architecture or a preview limitation. It has not published per-model Priority Tier availability, which the docs say depends on "account setup, model, and capacity" negotiated with an account executive. And it has not restated the Agentic Search benchmarks anywhere that matches the figures in its own documentation.
For teams building enterprise AI agents in production, the practical read is narrow: the retrieval technique is real and the gains are large, but the managed delivery vehicle carries compliance exclusions that the launch post does not mention.
FAQ
How eCorpIT can help
We build retrieval pipelines that keep the index and the source documents inside your own boundary while the model call stays a separate, auditable decision. Our teams design data residency architecture for DPDP and ship document AI and IDP for BFSI workloads where filings, contracts and KYC packs cannot leave the environment. eCorpIT is CMMI Level 5, MSME certified and ISO 27001:2022 certified, and we design applications aligned with DPDP and GDPR requirements. Tell us which corpus is blocked and we will map the endpoint decisions with you at contact us.
References
Last updated: 21 August 2026.