Functions Handle Large Results and Bad Inputs Better

This is follow-through on the original Function Sandbox release: fewer wedged runs, clearer guidance, and better behavior when a function touches large responses or malformed template data.

Large Tool Results No Longer Blow Up the Next Turn

Oversized results from API calls, SQL queries, and function returns are now trimmed before they can overflow the next prompt. The agent still keeps a small inline snippet for context, but the full payload remains available through an execution ref instead of wedging the work order on a giant body or base64 file.

Nested Tool Calls Can Recover Full Payloads

Nested tool calls inside functions.run now follow the same truncation rules as top-level tools. The guidance also points function authors toward get_ref(...) inside the same main() when they need the full HTTP body or SQL result for a follow-up step, rather than forcing a second turn.

Clearer Function and Template Errors

Function tool results now use a consistent success envelope, and template-variable validation rejects malformed shapes before they poison later prompt compilation. If a variable definition uses field where the platform expects name, canvas_editor.create now says that directly instead of returning a misleading "missing title/component" error.

Safer Defaults Around Calls and Returns

Functions can call tools by bare name, callable prefixes like fn_ and workflow_ resolve correctly, and template refs can read nested return values with dot-path access. Together, those fixes remove a set of avoidable footguns from normal function authoring.

Try It

Run a function that chains API or SQL calls, or creates a template with variable definitions. If a result is large, use the returned execution ref for the full payload instead of trying to stuff the whole thing into the next prompt.