Tools and integrations: let agents act, safely

The model is given tool definitions (a name, a description and an input schema) alongside the conversation. When it decides a tool is needed it returns a structured call instead of text; the toolbox node executes the call, records the result and hands it back to the model for the next turn. The loop repeats until the model answers or the iteration limit is reached.

The description is written for the model: what the tool does, what it needs, what it returns and when to use it. A good description is most of the difference between an agent that uses a tool at the right moment and one that guesses.

A name and description, JSON Schema input and output, and configuration for its type: for an HTTP API the method, URL, headers, query and body templates with allowed domains. Auth types: none, API key, bearer token, basic, OAuth2, custom header, a stored connection, or end user token, where the signed-in end user's own token is forwarded so the tool acts as that user.

A safety level from safe read to destructive, and limits: timeout, retry policy, rate limits, a read-only flag and whether calls require approval. Widget events decide whether end users see the tool's activity as hidden, a status line or full detail. Tool types available today: HTTP API, webhook, browser, agent, RAG retriever, file and function; typed connectors such as email, calendar, CRM and e-commerce are defined but not yet executable.

A toolbox can bind every attached tool to each model call, or select the most relevant ones per message with embeddings of the tool descriptions (vector, or hybrid with keyword matching) up to a maximum, plus pinned tools that are always present. That keeps large tool libraries usable without stuffing every definition into every prompt.

The built-in search_tools lets the model widen its own tool set: it can ask for a tool by name or describe the capability it needs, and matching tools become callable on its next turn. The model is shown, as a JSON object, which tools are bound now and which are not, with the exact call that binds each. A tool that is not bound cannot be called directly; the call returns an explicit error.

Large results are compacted: the model receives a preview plus a handle, and the full result is stored. The built-in tool_history lets the model read any part of it by character range, and the most recent tool-calling turn is replayed as compact pairs so the model remembers what it already fetched instead of fetching it again.