Built-in AI Tools

A Curiosity Workspace ships with a set of AI tools that are seeded into the graph on boot. They are ordinary _ChatAITool nodes — they show up under Settings → AI → AI Tools, they are picked in the chat and assistant tool pickers, and they are enforced against the calling user's permissions like any tool you write yourself. What differs is where their code comes from and whether you may change it.

This section covers the tools an ordinary chat user ends up calling:

The three kinds of built-in

Every seeded tool carries a version stamp on its node. On boot the workspace skips a tool whose node is already at the shipped version, so your edits survive restarts — and a release that bumps the stamp re-seeds the tool and overwrites local edits. Clone a sample into a tool of your own when you want to keep changes; the consult readers are the one place you are expected to edit in place.

Who can call what

Built-in tools carry an access mode. Most are AdminOnly — the introspection and propose/apply tools belong to Sudo, the admin assistant, and never appear for an ordinary user. The tools below are available to all users:

consult and chat-context are also auto-enabled: a chat that has items attached to it gets both, whether or not they were picked in the tool picker, because the model has to be able to read what the user just handed it.

Tool system prompts

A [Tool] description says what one call does; it is read when the model is choosing a call. Some tools also need something said up front: a habit to keep across the whole conversation, a rule about how their results must be presented, an order two of their functions have to be called in.

A tool can contribute an excerpt to the system prompt of every run it is offered in. Put it in a class-level [ToolSystemPrompt("…")] on the class your tool code returns, and every chat or agent run that offers the tool appends the excerpt to its system prompt:

[ToolSystemPrompt("""
    When you cite a ticket, always give its number and its current status — a ticket referred to by
    title alone is ambiguous, several are usually open with the same one.
    """)]
public class TicketsTool
{
    [Tool("Looks a ticket up by number.")]
    public static async Task<string> GetTicket(ToolScope scope,
        [Parameter("Ticket number", required: true)] string number)
    {
        // ...
    }
}
return new TicketsTool();

The rule then travels with the tool: it does not have to be copied into the prompt of every assistant that enables the tool, and it cannot go stale when the tool changes.

What the runtime guarantees:

• Only tools the run actually offers contribute. Excerpts are read through the same cache the run's tool surface is built from — on the agent path, after the per-user accessibility filter — so the prompt can never describe a tool the model cannot call.
• Order is by tool UID, never the order the caller listed its tools in. The same set of tools produces the same prompt bytes on every turn, which is what lets the provider's prompt cache hit.
• The excerpts are laid out as one section: a # Tool usage guidelines heading, then a ## subsection per tool named after it. Write your excerpt without a heading of its own.
• The excerpt is read once, when the tool is compiled into the cache, and is replaced when an edit recompiles the tool.

For a deep research tool the attribute goes on the IDeepResearcher implementation. Both shipped researchers carry one, which is where the assistant is told not to summarise a report away and that the chat takes no messages while a run is in flight.

Related

• AI Tools — writing a tool of your own.
• AI Tools Scope — the ToolScope surface every tool method receives.
• AI Agents — packaging a prompt, a tool set and a model.