Tools and skills

The Dispatch agent has access to a few dozen tools across all the connectors a user might have active. Putting that whole catalog into every system prompt would be expensive, would inflate latency, and would lower accuracy. The model gets worse at selecting tools as the catalog grows. Dispatch avoids that by surfacing tools through a search registry: the model sees a small always-on subset on every call, and reaches for the rest through a tool_search tool.

Always-on tools

A small set of tools is included without going through tool_search. The exact set depends on the run type, because not every run shape benefits from the same tools:

• tool_search: discover other tools by name pattern. Present on every run.
• send: the agent's primary way to send a message back to the user. Present on every run.
• read_file, write_file, edit_file, delete_file, list_directory: the file-system surface. These tools operate over a virtual filesystem composed of every active connector's file resolvers. Internal-surface connectors (preferences, daily-notes, people, meetings, documents, todos, automations) register resolvers; integration connectors (Gmail, Calendar, Slack, Composio) typically do not, and instead expose their state through their own dedicated tools. Present on most runs; omitted for the research-agent run shape.
• remember: a read-only search over the long-term memory store. Present on chat-style runs where the user is in the loop (including Slack and Telegram messaging sessions). Omitted on fully autonomous runs (triggered automations, scheduled tasks, todo runners).
• web_search, web_fetch: open-web reads. Enabled only for research runs and NEW_PERSON triggered runs (where the agent is gathering context on someone it has just met). When omitted they are not in the tool catalog at all, so tool_search cannot recover them on other runs.

Everything else has to be discovered through tool_search.

Searching for a tool

When the model needs something beyond the always-on set, it calls tool_search with a glob pattern. The registry filters the full catalog for matches and returns names and descriptions. Matched tools are unlocked for the remainder of the session. Once discovered, they remain available without re-searching.

A few examples of patterns the agent might use:

• email_*: every email-shaped tool across Gmail and Outlook
• calendar_*: every calendar tool across providers
• slack_*: every Slack tool
• *_send: every "send" verb across connectors

The patterns are case-insensitive, support * as a wildcard, and otherwise treat the rest of the string as a literal.

Why search instead of catalog

Two reasons:

• Accuracy. Models choose worse from larger catalogs. Search narrows the candidate set to a small, semantically related batch, which improves selection.
• Token cost and latency. Tool definitions in the system prompt cost input tokens on every call. Dispatch keeps the always-on set tight and lets the model pull in the rest by name when relevant.

The trade-off is that the model occasionally has to take a turn to discover a tool before it can use it. In practice the model learns to search early when its job is unfamiliar, and the cost is one tool call rather than a fat prompt every run.

Skills

Skills are markdown documents that explain how to do specialized things: how to write a good calendar event, how to interpret an automation trigger, how to use the booking-links surface. Each connector can ship one or more skills.

Skills mount under /skills/{skillName}/ and are read on demand with read_file. They are never inlined into the system prompt. When the agent encounters a task it does not have a strong default for, it reads the relevant skill, then proceeds. The same just-in-time pattern as tool search, applied to prose instructions.

Users can author their own skills too. Custom skills are user-written markdown that mount under /custom-skills/ rather than /skills/. A custom skill runs when the user types its slash command, or, if it has auto-invoke enabled, when the agent matches the user's request to the skill's description (listed in the prompt) and reads the body on demand. Like built-in skills, they are prose instructions, not new tools.

The search connector

Distinct from tool_search (which finds tools by name), the search connector provides a search tool that queries across the agent's data: people, meetings, documents, todos, and past chat sessions. The entityType filter accepts chat, document, person, meeting, or todo; automations are not searchable through this tool. The agent uses it to answer "who is this person?" or "did I have a meeting with them last week?" without paginating through each entity type.

For agents

• The model sees a small always-on tool set on every call; the exact set depends on run shape. tool_search and send are always present. The file-system tools (read_file/write_file/edit_file/delete_file/list_directory) are present on every run except the research-agent shape; they operate over the virtual filesystem composed of active connectors' file resolvers, which is why not every connector contributes file-backed state. remember is present on non-autonomous (chat-style) runs only and is a read-only search over long-term memory; it does not write preferences. web_search and web_fetch are present on research runs and NEW_PERSON triggered runs only; on other runs they are absent from the catalog and cannot be reached via tool_search.
• All other tools are surfaced via tool_search, which takes a glob pattern (case-insensitive, * wildcard) and returns matching tool names with descriptions.
• Discovered tools stay unlocked for the remainder of the run.
• Skills are markdown documents under /skills/{skillName}/, read on demand with read_file, never inlined into the prompt.
• User-authored custom skills mount under /custom-skills/; auto-invoke skills are listed by name and description in the prompt and read on demand, slash-command skills resolve from the user's message. They are prose, not tools.
• The search tool (from the search connector) is distinct from tool_search: it queries the agent's data, not its tool catalog.
• This design optimizes for accuracy on tool selection and for token cost across high-volume runs.