JSON-Only Action Schema
Anti-pattern: restrict the agent's action language to JSON tool-call dictionaries even for tasks where code-as-action (functions composing, loops, conditionals over results) would be the natural shape.
Problem
A JSON tool call cannot directly express a loop, a conditional over an intermediate value, or the reuse of one tool's output as another tool's argument. To compose three tools the agent must take three or more turns, ship each intermediate result back through the model as a string, and reconstruct any structured object on each side. Token cost is dominated by these round-tripped intermediates, latency is dominated by the turn count, and the action language drifts further from the code-shaped composition the model actually saw most of in training.
Solution
Don't insist on JSON-only when the task needs composition. For composition-heavy work, swap to code-as-action: expose tools as ordinary 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.
When to use
- JSON-only is acceptable for narrow one-tool-per-turn flows; declare that scope explicitly.
- Cite this entry when tasks need nesting, conditionals, or reuse of intermediate results and the schema forbids expressing them.
- Switch to code-as-action behind sandbox-isolation; the sandbox becomes the security envelope.
Open the full interactive page →
Diagram, neighbourhood map, code examples, related patterns and full provenance.