JSON-Only Action Schema
Forcing agents to express loops, conditionals, and multi-step logic through flat JSON tool calls when they should just be writing code.
Intent & Description
🎯 Intent
Locking the agent’’s action language to JSON tool-call dictionaries even when the task needs composition, branching, or reuse of intermediate results.
📋 Context
The team standardized early on the provider’’s function-calling contract: one JSON tool call per turn, one result back. Works fine for simple lookups. Falls apart for data wrangling, multi-step reductions, conditional branching — which now require 10x more turns to express, each round-tripping intermediate objects as strings through the model.
💡 Solution
When the task needs composition, switch to code-as-action — expose tools as functions in a sandboxed interpreter and let the agent write the glue. Keep JSON for simple one-tool, one-arg actions where the contract genuinely fits. See code-as-action, agent-computer-interface, sandbox-isolation.
Real-world Use Case
- Never as the default. JSON-only is appropriate for narrow one-tool-per-turn flows — declare that scope explicitly.
- If the task needs nesting, conditionals, or reuse of intermediate results, switch to code-as-action.
- Pair code-as-action with sandbox-isolation; the sandbox is the new security boundary.
Source
📌 TL;DR
Switch to sandboxed code execution (code-as-action) for tasks that need composition or control flow — JSON tool calls are for simple one-step operations.
Disadvantages
- Composition and control flow unroll into many turns, multiplying token cost
- Intermediate objects (dataframes, images, structured returns) round-trip through the model as strings
- JSON action language is further from the model’’s training distribution than actual code