Product updates — September 14–20, 2026

A list of JSON values can be read and edited as a table. When a field holds a list of JSON objects — line items pulled off an invoice, rows returned by an API — it now opens as a table: one row per item, one column per field. Open the field to edit it and the table comes too; double-click a cell to change a value. Switch to JSON any time for the raw view, which is still where nested values are edited. Thunk offers the table whenever the list is regular enough to fit one, and remembers which view you prefer.

A scheduled AI agent can act on your reports. Monitor has a new Report Automation tab. Write what you want done — "every Monday at 8am, email the Overdue Items report to [email protected] as a spreadsheet" — turn on a schedule, and it runs on its own. It reaches any of your saved reports by name, and can export one to CSV or Excel and attach it to an email without you lifting a finger. You can also just ask it for something right now in its chat, without touching the schedule. Add a condition to the schedule and it only runs when there is something to report, so a quiet day costs nothing.

Imported thunk libraries can be picked while you create a thunk. The Connections step listed only the connections in the environment you chose. It now has a second group, Imported Thunk Libraries — the thunks you and your team have published as libraries — so a new thunk can start with tools you already have instead of you adding them after the fact. Thunk suggests both kinds from your goal, the way it already suggested connections. See AI Tool Libraries and Modular reuse of tools.

See what a custom AI tool costs you, and where its time goes. A tool's Call history has three new views beside the list of calls. Cost shows what the calls cost, how that is spread, the most expensive ones, and how many of the prompt tokens came from cache — the usual reason a small tool has a large bill. Working time shows how long the calls spend actually doing the work, leaving out any wait for a person to reply; Wall clock shows the whole span instead. Each gives you the median, the 90th and 99th percentiles, and the calls that stand out — and the two often name different calls, which is the point of having both. Every view also plots its calls on a chart over time, colours each dot by the model or by how much of its prompt came from cache, and adds a Tokens/sec view of how fast the model wrote — so you can see whether a tool is getting slower or dearer rather than only what is typical. They leave out your Try It and unit-test runs, and open any listed call to the run behind it. See How custom code tools work.

You choose how each tool of an MCP interface is built. Creating an MCP server from an interface file built every tool the same way. The Review step now lists the interface's tools with a type beside each one: AI, Code, Database, Document Template or Spreadsheet Lookup — so a tool that summarizes a document can be an AI tool while a tool that computes a total is code. You can also point a new custom tool at an interface — a file you upload, or one already used by a plug-in connection — and pick the tool it should match; Thunk fills in that tool's name, description and inputs from the interface and holds them fixed while it writes the implementation, so the tool keeps matching the interface it was built for. See Publish your thunk as an MCP server for AI agents and Custom Tools.

Time Analysis measures the work, not the waiting — and the step picker follows your workflow. The timing figures in Monitor → Time Analysis counted every minute a work item spent waiting — queued behind other work, held for a scheduled step, or sitting on a reply that came back the next morning — so a workflow that does two minutes of work could report a median of a day. The tab now reads by Working time and leaves that waiting out, and says how much it excluded; switch Measure to Wall clock for the old end-to-end figure, which is still the one to quote when the question is how long a customer waits. The Scope dropdown on Time Analysis and Token Costs also lists the steps the way the workflow runs them — Whole workflow, then Step 1, Step 2 with each step's own name, then Setup & automation at the end — instead of reordering itself heaviest-first. See Time Analysis: how long your thunk takes.

Steps get to work directly instead of writing a plan first. The Enable dynamic planning? setting under a step's AI Settings is gone, and so is the planning turn it added. A step with it switched on used to spend its first turn writing out which tools it intended to call, then work through that list; it now starts on the work itself. That is one fewer model call on every run of those steps, so they finish sooner and cost less. Nothing you wrote needs changing — instructions, tools, examples and data bindings steer the work exactly as before — and if a step should follow a particular sequence, say so in its instructions. See AI Instructions.

A run's cost names the model and prices the alternative, and every model picker tells you what you're choosing. The dialog behind a run's cost figure now names the model that answered and calls out the two things that usually explain a surprising bill: output that ran long, and a prompt the provider barely served from its cache. You can also pick any other model your environment offers and see what the same calls would have cost at its published rates. And every model picker — a step's model, a thunk's default, an environment's default, the test grader — now shows under each name how fast that model answers, what it costs relative to the others on offer, and a sentence on what it is built for, so a name one character apart from another is no longer a guess. See Understanding LLM costs and latency.

API keys can expire. When you create a thunk API key or an account Builder API key, you can leave it with no expiration or choose how long it should last — 1 day, 1 week, 30 days, 90 days, 1 year, or a date you pick. After that time the key stops working, the same as if you had revoked it. Existing keys stay valid until you revoke them. See Inbound requests via a REST API.

"Is not empty" now excludes a list with no entries. A condition on a field that holds a list — line items, a list of names, a list of dates — judged the list by the brackets around it rather than by what was in it, so is not empty kept work items whose field reads "0 items" and is empty left them out. An empty list now counts as empty wherever a condition is graded: filtering the work items table, a saved report, a step's condition, and the filter on a scheduled run. Worth a look if you built around the old behavior — a step gated on is not empty will now skip work items whose list is empty. See Scheduled work on workflow steps.

Chat apps handle short replies, stay visibly working while a tool talks, and give new steps the conversation. A short confirmation like "ok" was sometimes treated as "still waiting," so the step stopped instead of using the answer — those replies now continue the conversation. When a step handed the conversation to a custom AI tool, the chat could look idle and send-and-wait could return while the tool was still writing; the typing indicator and agentWorking now stay on until the tool is waiting for the person. And a new step added to a Chat App now lists EndUserConvo under its input and output properties, so the AI can read and reply on the chat without you turning the conversation on by hand. See Conversational interface via a REST API.

A thunk's conversational MCP URL opens sign-in, and follow-ups keep the caller's name. Copying MCP Server URL from Run → Inbound Requests → Chat UI into a host such as Claude Desktop could fail before Thunk asked you to allow access; that connection now opens the sign-in page so you can grant the host the thunk's conversational tools. And after the first message, later turns could show an opaque id in the transcript instead of the name you sent at the start — follow-ups now keep that name when you don't send it again. See Conversational interface via a REST API.

The extra thunk properties your organization defines now show in the card view too. In My Thunks, the properties your organization adds to a thunk showed as tags in the table view but were missing from the card view. Both views show them now, as Property: value tags beside a thunk's built-in tags. Where a thunk carries a lot of them, the card shows the first few and collapses the rest into a count you can hover to read.

A work-item link that names only some of its fields now opens. Asking a step to read a work item from a URL that includes a field filter (for example, only Name) could fail with an error instead of showing those fields. Those links open now, and the step sees only the fields the URL asked for.