A U.S. patent issued to Mistral AI on June 30, 2026 has pushed a familiar agent primitive into an unfamiliar conversation. US 12,670,045 B1 is titled Code implemented tool calls. Its first claim describes a particular way to generate code around tool calls, run that code in a sandbox, pause when a client-side tool is pending, resume after the client returns a result, and send a later result back to the language model.
The news is not that Mistral patented every form of function calling. The interesting question is narrower and more practical: how close is an agent runtime’s implementation to the sequence described by the claim?
Read the claim as a workflow
The patent’s claim 1 is a chain of required steps. A server receives a request for one or more tool calls. An LLM generates a code block that encapsulates them. The server executes that block in a sandbox. If execution reaches a pending tool call, the block pauses and the pending call is sent to a client. After the client returns a result, the server resumes execution, substitutes that result, and returns another result to the LLM.
The patent describes a resumable path between server-side orchestration and client-side tool execution.
That is more specific than the everyday idea of giving a model access to a function. Mistral’s own documentation presents function calling as a normal way for a model to connect to external tools. The patent, by contrast, focuses on an orchestration shape: code as the container for multiple calls, sandboxed execution, a pause at a client boundary, and resumable evaluation. Those layers should not be collapsed into one claim that all tool calling is suddenly unavailable to developers.
Why developers started arguing about it
Tool calls sit underneath most agent SDKs. They connect a model to files, browsers, databases, APIs, and local devices. Open-source runtimes often need to make similar systems interoperable, so the possibility of a patent covering a recognizable execution pattern naturally raises concerns about implementation freedom, licensing, and long-term compatibility.
The public document does not by itself answer whether a particular open-source project infringes, whether the claim would survive every validity challenge, or how the patent would be enforced in a given product and country. Those are legal and factual questions that depend on the full claim set, prior art, implementation details, jurisdiction, and the history of a specific dispute. A patent grant is an important signal, but it is not a court finding against every similar system.
That distinction matters because hot discussions tend to compress three different statements into one: Mistral has a granted U.S. patent; the patent describes one code-mediated tool-call workflow; and every function-calling implementation is now at risk. The first two are supported by the patent record. The third is not established by the document.
Separate the common function from the specific implementation
The simplest form of function calling returns a structured name and argument set, after which an executor invokes the function and places the result back into the conversation. A code-implemented approach can go further by putting dependencies and ordering into a code block. Some operations can run in parallel, others can wait for earlier results, and intermediate results do not all have to be exposed to the model. Both systems use tools, but they place execution responsibility in different places.
When reading a patent, the combination of claim limitations matters more than a product or feature label. The patent contains 20 claims. Claim 1 describes the method sequence, while other claims add details such as client-side execution, a resumable sandbox, an evaluation stack, parallel and sequential execution, and error information. One similar feature does not make an implementation identical to the whole claim, and a different name does not prove that the implementation is different.
In practice, an engineering team should turn the runtime into a table. Record whether the LLM generates the code, whether a server executes it, whether the sandbox can pause and resume, how a client result is substituted, and which results are returned to the model. The table is not a legal opinion, but it turns vague anxiety into a concrete comparison and shows which parts deserve counsel’s review.
What an agent team should inspect
The first step is to draw the runtime rather than search for a single keyword. Does the model emit ordinary structured calls, or does it generate executable code that contains several calls? Where does that code run? Is there a resumable sandbox? Can a call cross from a server to a client and return into the same execution? Does the model receive intermediate results or only a final result? These details are closer to the claim than the broad label of tool calling.
The second step is provenance. Record when the runtime design was introduced, which open-source components it depends on, which jurisdictions matter, and which alternatives were considered. If the product depends on a distinctive orchestration sequence, document the technical reason for it and ask counsel to review the relevant claims before a commercial launch. This is not a request to stop building; it is a request to avoid treating an IP question as an afterthought.
The third step is architectural flexibility. A system can separate the model interface from the execution engine, keep tool permissions explicit, and make the pause-and-resume boundary replaceable. That improves security and observability even when no patent question exists. It also gives a team more room to change an implementation if a legal review identifies risk.
Record the moments when the implementation changes
Agent runtimes rarely arrive fully formed. A prototype may begin with simple JSON calls, then add code blocks and a sandbox as the number of calls grows. In production, security or cost concerns may move the boundary between server and client. If the reasons for those changes disappear and only the final code remains, it becomes difficult to explain when a particular execution pattern was introduced or which alternatives were considered.
The design record should therefore include more than an architecture diagram. Keep the runtime version, open-source dependencies, tool-call mode, and the points where execution can pause and resume. Record when a patent was reviewed and which jurisdictions were considered. Then a future model or executor change does not force the team to reconstruct the same questions from scratch. Open-source license compliance and patent review are separate responsibilities.
This record is not only for counsel. Operators can use it to reproduce an execution, security teams can inspect the permission boundary, and engineers can replace one risky component without rewriting the whole agent. Even when a patent concern never becomes a dispute, the separation lowers the maintenance cost of an agent system.
The broader lesson is uncomfortable but useful. As agents move from single JSON calls to code execution, sandboxes, client delegation, and replay, the runtime itself becomes a product surface with legal as well as technical constraints. Developers do not need to assume that Mistral owns the idea of tool use. They do need to read the actual claims, preserve design provenance, and separate a hot community interpretation from what the patent record actually says.
