Convergent Tool Calling

OpenAI GPT-5.6 Announcement on 2026-07-09:

GPT‑5.6 can write and run lightweight programs that coordinate tools, process intermediate results, monitor progress, and choose the next action as work unfolds. This lets tool-heavy tasks advance with fewer tokens, fewer model round trips, and less guidance. Instead of requiring developers to script every step or passing every tool response back through the model, Programmatic Tool Calling in the Responses API can filter large amounts of intermediate data, retain only what matters, and adapt its workflow along the way.

I am getting some sweet validation from this feature they revealed. I built a similar system at work recently, and I think it fits coding agent capabilities nicely.

State Machine Automation #

Because this is about proprietary code I am writing for work, I am going to be a little vague about the surrounding context. Let's say you're building a service which will execute state machines (directed graphs). As a team we decided the state machines would be defined as configuration ahead of time. So at runtime the engine takes in the configuration and executes it. To make these state machines easier to build, we lean on a coding agent to build them, using a bunch of tooling I wrote.

Let's also say that some of the states are "automation" states, where you want to query services, or call them for side effects. Rather than inventing a whole configuration-based DSL for this, I chose JavaScript to express those service calls.

Some of the constraints that led me to JavaScript:

• LLMs are very good at writing JS these days.
• Our services are written in Kotlin, and our infosec targets Kotlin for service-to-service security infrastructure.
  • GraalVM allows execution of JS natively inside the JVM.
• Service interfaces are not guaranteed to line up exactly as needed: inconsistent timestamp formats, decimal place rounding, or the need to combine two pieces of data into one for a given service call.
• Minor conditional logic can be needed to decide which state to transition to next.
• The state machine execution is asynchronous from its users.

The complexity of the requirements pushed me away from wanting to implement a bespoke DSL on top of the configuration — LLMs wouldn't know the DSL very well, unlike JS. Because these state machines are defined by trusted people, there's not much worry about executing arbitrary JS; low likelihood that they'll deliberately implement a non-terminating loop.

The service call implementations are written in Kotlin. A KSP generator converts their interfaces to TypeScript declarations that return Promises, which are then handed to the LLM to help it author the JS. To provide durability and a convenient observability tool, the whole execution is wrapped in a Temporal workflow, with the service call implementations wrapped as Temporal activities.

The GraalVM runtime is customized to remove sources of nondeterminism (Date, Math.random), which is needed to support Temporal's determinism requirement. It is also restricted to a maximum number of statement executions, to mitigate non-termination. As it's GraalVM, we bridge-in only the Kotlin-defined services — no filesystem or network access.

Programmatic Tool Calling #

OpenAI's documentation on the feature makes a lot of the same choices:

Programmatic Tool Calling Developer Documentation on 2026-07-10:

Programmatic Tool Calling lets a model write and run JavaScript that coordinates the tools in a Responses API request. A program can call tools in parallel, use loops and conditions, and keep intermediate results in the hosted runtime. This is useful when a task needs a sequence of related tool calls or needs to process large tool outputs before returning a result.

...

OpenAI runs each generated program in a fresh, isolated V8 runtime. The runtime supports JavaScript with top-level await, but it does not provide Node.js, package installation, direct network access, a general-purpose filesystem, subprocess execution, a console, or persistent JavaScript state between program executions. Programs can interact with external systems only through tools enabled in the request and can emit output with text(...) or image(...).

This is a very similar feature set, aimed at the same problem space. It gratifies me to see others independently arrive at the same solution.