Configuring Capabilities

The built-in agent assembles itself at runtime from providers — each responsible for a specific aspect of the agent's behavior. You don't write code to wire these together; you write configuration that controls which providers are active, which sources within each provider are enabled, and how they behave.

Providers and the Request Lifecycle

Each provider hooks into one or more phases of the request lifecycle. When a user sends a message, the agent goes through a loop:

1. Dispatch — check if a routing rule should handle this request directly (no LLM call)
2. Collect tools — gather all callable tools the LLM can use
3. Build system prompt — assemble instructions, skill catalog, memory, context
4. Process conversation — inject context (documents, filters) into the message history
5. LLM loop — call the LLM, check if it wants to use tools, execute them, feed results back, repeat until done
6. Post-process — transform the final response (e.g., resolve citations)

Each capability article in this section is tagged with badges showing which phases its provider participates in:

Badge	Phase	Description
🔧 Tools	Tool collection	Contributes callable tools to the LLM's toolset
📋 Prompt	System prompt assembly	Adds a section to the system prompt
💬 Conversation	Conversation processing	Injects or transforms messages in the conversation history
📝 Post-process	Response post-processing	Transforms the LLM's response before it reaches the user
🚦 Dispatch	Pre-LLM routing	Can short-circuit the entire flow

Available Providers

Provider	Phases	What It Does
Tools	🔧 📋	Provides callable tools (search, browse, read documents, web fetch, data analysis, etc.) and tool-specific prompt guidance
Skills	🔧 📋	Discovers skill catalog, provides use_skill tool for loading detailed instructions on demand
Memory	🔧 📋	Loads recalled memories into the prompt, provides save_memory tool
Context	📋 💬	Resolves what the user is looking at (documents, filters, tags) and injects it into the conversation
Instructions	📋	Adds cross-cutting instruction sections (date/time, citations, onboarding, custom text)
Delegation	🔧 📋	Routes tasks to named specialized agents via the delegate tool
Message Processing	📝	Post-processes the LLM response (e.g., resolves inline citations to structured evidence)
Dispatch	🚦	Pre-LLM interceptor — matches context patterns and short-circuits with a direct response
MCP Tools	🔧	Connects external MCP servers and exposes their tools to the LLM

Policies

Policies are cross-cutting configuration that affects multiple providers simultaneously. Unlike providers, they don't own a lifecycle phase — they're read by whichever components need them.

How Source Filtering Works

Every provider supports include_sources and exclude_sources for controlling which sources are active. Sources ship with a default enabled flag (some are on by default, some opt-in). Your configuration overrides these defaults:

1. exclude_sources — hard veto. Always off.
2. include_sources — if defined and the source is listed, it's on (overrides the source's own default). If defined and the source is not listed, it's off.
3. Source default — when neither list applies, the source's own enabled flag decides.

{
  "tools_provider_configuration": {
    "include_sources": ["index_tools", "document_tools"],
    "exclude_sources": ["web_tools"]
  }
}

This filtering is a cross-cutting pattern — it works identically for tools, skills, context, instructions, memory, and message processing. See Source Filtering in the architecture guide for the full explanation.

Provider Settings

Each provider also has its own configuration block that controls provider-level behavior (not per-source). For example, the skills provider has an injection_mode setting that controls whether skills are injected into the system prompt, as tools, or both. These settings are documented in each capability's article below.

For the full JSON schema covering all providers, sources, and settings, see the Agent Configuration Reference.