This week we made it easier to understand a run — why it took the time it did and what went wrong when it failed — added plug-in connections so a thunk can require capabilities from another, and let people download a conversation as a PDF.
New
Plug-in connections. A thunk can now declare the connections it needs from another thunk as a typed interface, then bind a candidate to it. Binding checks the candidate against the interface and refuses it — naming the specific tools and reasons — if it does not satisfy the contract. You can write the interface out to a file to hand to whoever implements it, and check a thunk against an interface from its export page. See Modular reuse of tools for more on sharing tools between thunks.
"Why so long?" A finished run now shows a "Why so long?" control beside its duration that opens a measured breakdown of where the time went, so you can see whether a slow run was work the model had to do or overhead. For background on what drives execution time, see Understanding LLM costs and latency.
"What went wrong?" When a run fails, you can now ask what happened in that specific run — not just the general kind of error, but the concrete diagnosis (for example, that the same update failed identically three times because the account is read-only, so retrying will not help), grounded in the help center. Our Troubleshooting Errors guide covers every error category and what to do about each.
Download a conversation as a PDF. The end-user conversation view now has a quiet action row above the composer to save the transcript as a PDF. The download keeps the conversation exactly as it was read, in any language, and stays available after the conversation has ended.
Author a JSON object column's schema directly. A JSON object column can now be authored by example or by writing its schema directly, with a mode switch in the column details. You can generate a schema from an example and then refine it by hand. See Schematized State for why strong typing improves reliability.
Improvements
Balanced error-handling policy. Error handling now has a Balanced option that takes no opinion on whether the agent should keep going after a failure — the same behavior thunks have had by default — alongside the existing Proactive and Conservative choices. See AI reliability mechanisms for more on how reliability controls work.
Filter work items by end user. The Work Items grid can now filter by end-user name, with the filtering done on the server so it stays fast on large lists.
Trace a work item back to its request. Open a work item and you can now jump to the inbound webhook, email, or API call that created it — the reverse of the link that already went from a request to its work item. See Inbound Requests for the ways work can arrive in a thunk.
Tool builder: run one test, see console output. In the tool builder you can now run a single unit test from its row, see a custom code tool's sandbox console output in its call history, and review a record of builder and unit-test runs there. For the full tool-testing workflow, see Automated tests for custom tools.
Clearer review explanations. Step and property review findings now offer the same "Why" and "Fix it" explanations already available in the review report. See Workflow Review for more on the review system.
Fixes
PDFs an agent produces now open as a link. A PDF an agent references in a message now renders as a "View PDF" link instead of a broken image.
Merged spreadsheet cells read correctly. When an agent reads a spreadsheet, merged cells now come through as the values you see rather than as blanks.
A re-routed message shows a failed routing run. A message that had already routed once now shows a later failed routing run instead of hiding it.
Clearer label for dynamic tool inputs. A tool whose inputs are determined at run time now says so, instead of showing "No input parameters". See AI Tools for more on how tools work.