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 runs one turn:

1. Dispatch: a dispatch rule that matches answers directly, with no LLM call.
2. Process conversation: context (documents, filters, tags) goes into the message history.
3. Build system prompt: instructions, skill catalog, memory and context, once per turn.
4. LLM loop, before every model call:
   1. Messages the user sent since the last call are added.
   2. The tools are read from the providers' cached listings.
   3. The tool rules select the tools the caller gets, then set which ask first and which load on demand.
   4. The model answers. Tool calls run; a tool that asks first waits for the user's approval. Results go back to the model, and the loop repeats until it answers without calling a tool.
5. Post-process: the response is transformed (for example, citations resolved).

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, 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
Queued Messages	💬	Reads the messages the user sends while a turn runs before the model's next call
Interjections	📋 💬	Adds supervisor messages between model calls (repeated tool failures, a reviewer, attempt and refinement checkpoints)
Python REPL	🔧 📋	Provides run_python, a sandboxed Python session in which the agent's other tools are functions

Self-Improvement combines sources of several providers: a scored attempts gate on known tasks, and refinement of the agent's own memories, skills, prompt notes and sub-agents.

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"]
  }
}

On the Zeta Alpha platform, the chat input's source toggles (Internal knowledge, Web, My files) switch tools sources off for one conversation. Each turn sends them as bot_params.source_selection_configuration.excluded_sources; the conversation keeps the latest turn's choice, and the platform's user_choices tool rule applies it, so it can narrow the agent's tools but never add one. source_selection_configuration is a platform setting that the agents SDK does not read.

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.