Let the Model Write Code, Not JSON
A newly granted patent describes an underused agent pattern: instead of emitting one JSON tool call per turn, the model writes a code block that orchestrates many calls in a sandbox. For multi-step tool work, that is often the better shape.
- #agents
- #devex
Most agents call tools the same way: the model emits a single JSON tool call, waits a full round-trip for the result, then emits the next one. It works, but it is a slow way to do anything with more than two steps, and the model has to fake control flow across turns because it cannot actually loop or branch inside a JSON blob.
A newly granted patent spells out the alternative that a lot of us have been reaching for: have the model write a code block that encapsulates the tool calls, run it in a sandbox, pause when it hits a call that needs the client, hand that one back, then resume with the result substituted in. In other words, let the model express the plan as code, because code is the language of loops, conditionals, and chaining, and a plan is exactly those things.
The upside shows up fast on multi-step work. Fetch a list, filter it, call a second tool for each survivor, and combine the results; that is one code block and one execution instead of a dozen chatty round-trips. The model gets to say what it means directly, and you get fewer places for the conversation to drift.
The catch is not subtle: you are now executing model-written code, so you need a real sandbox, tight egress, and the assumption that the code is untrusted until proven otherwise. Code-as-actions trades a JSON-shaped safety rail for a general-purpose one you have to build. If your agent calls one tool at a time, it is not worth it. If your agent juggles many tools in tight loops, it is a different and better ergonomics.
Patents on agent primitives are their own conversation. The pattern, though, is worth stealing on the merits: when the task is really a program, stop making the model pretend it is a chat.