> ## Documentation Index
> Fetch the complete documentation index at: https://agno-v2.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# What are Context Providers?

> Context Providers give agents clean access to external systems without tool sprawl.

Context Providers solve three problems that appear when agents integrate with multiple external systems:

1. **Tool sprawl.** Slack alone is 8-12 tools. Add Drive, GitHub, your CRM, and you're at 50 tools before adding anything custom. Past 20, models start hallucinating tools or picking the wrong one.

2. **Name collisions.** `search` in one toolkit collides with `search` in another. `send_message` could be Slack, email, or your CRM. No naming convention fixes it.

3. **System-prompt bloat.** Using Slack well requires Slack-specific guidance: look up user IDs before DMing, resolve channel names, prefer `conversations.history` for channels. Multiply by every API. The system prompt becomes the union of every source's quirks.

A `ContextProvider` wraps an external system and exposes it as one or two tools:

```
Agent  ↔  ContextProvider  ↔  Tools
```

The calling agent sees `query_<id>` (for reads) and `update_<id>` (for writes). Behind the tool is a sub-agent scoped to that one source.

```python theme={null}
from agno.agent import Agent
from agno.context.slack import SlackContextProvider
from agno.context.gdrive import GoogleDriveContextProvider
from agno.context.database import DatabaseContextProvider

slack = SlackContextProvider()
drive = GoogleDriveContextProvider()
db = DatabaseContextProvider(sql_engine=engine, readonly_engine=readonly_engine)

agent = Agent(
    model=...,
    tools=[*slack.get_tools(), *drive.get_tools(), *db.get_tools()],
)
```

The agent sees five tools: `query_slack`, `update_slack`, `query_gdrive`, `query_database`, `update_database`. Each provider exposes one read tool plus an optional write tool.

## How it Works

### Sub-agent Architecture

Each provider runs its own sub-agent. Use a cheap model for source-specific work and a stronger model for synthesis:

```python theme={null}
from agno.models.openai import OpenAIResponses
from agno.context.slack import SlackContextProvider

slack = SlackContextProvider(model=OpenAIResponses(id="gpt-5.4-mini"))

agent = Agent(model=OpenAIResponses(id="gpt-5.4"), tools=slack.get_tools())
```

> [!TIP]
>
> The sub-agent does the tool work; the calling agent does the reasoning. On most workloads this is cheaper *and* faster than putting every source's tools on one big agent.

### Read/Write Separation

Writable providers run two sub-agents with minimum privilege:

| Provider | Read sub-agent | Write sub-agent |
| - | - | - |
| Database | Uses `readonly_engine` | Uses `sql_engine` |
| Slack | History, thread, and lookup tools (search with a user token) | `send_message` + lookups |

These are infrastructure-level guarantees, not prompt instructions. The read sub-agent physically cannot call write tools.

### Mode

**default**

Provider's recommended exposure. For read/write providers, this means `query_<id>` + `update_<id>` with separate sub-agents.

```python theme={null}
slack = SlackContextProvider()
# Agent sees: query_slack, update_slack
```

**When to use:** Most cases. You get clean read/write separation with privilege isolation. The read sub-agent cannot call write tools.

**How it works:** Two sub-agents handle the underlying toolkit. Reads go through the read sub-agent (history, threads, lookups, plus search when a user token or Slack-interface token is configured). Writes go through the write sub-agent (send\_message + lookups for channel resolution).

**agent**

Single `query_<id>` tool. Read-only access through one sub-agent.

```python theme={null}
from agno.context.mode import ContextMode

slack = SlackContextProvider(mode=ContextMode.agent)
# Agent sees: query_slack only
```

**When to use:** Read-only access, or when you want maximum abstraction. Your agent just asks questions; the sub-agent figures out which tools to call.

**How it works:** All requests route through the read sub-agent. No write access. The sub-agent orchestrates reads internally.

**tools**

Bypass sub-agents entirely. Your agent sees the raw toolkit methods.

```python theme={null}
from agno.context.mode import ContextMode

slack = SlackContextProvider(mode=ContextMode.tools)
# Agent sees: get_channel_history, get_thread, list_channels, get_user_info, etc.
```

**When to use:** Building a source-specific agent, or when you need fine-grained control over individual API calls.

**How it works:** No sub-agent wrapping. Your agent directly calls read tools like `get_channel_history`, `get_thread`, `list_channels`. Write tools require using `mode=default`.

## Multi-Provider Composition

Three providers on one agent compose cleanly because each has its own namespace:

```python theme={null}
from agno.context.fs import FilesystemContextProvider
from agno.context.web import WebContextProvider, ExaMCPBackend
from agno.context.database import DatabaseContextProvider

fs = FilesystemContextProvider(root="./docs")
web = WebContextProvider(backend=ExaMCPBackend())
db = DatabaseContextProvider(sql_engine=engine, readonly_engine=readonly_engine)

agent = Agent(
    model=...,
    tools=[*fs.get_tools(), *web.get_tools(), *db.get_tools()],
    instructions="\n".join([fs.instructions(), web.instructions(), db.instructions()]),
)
```

The agent sees `query_fs`, `query_web`, `query_database`, `update_database` and picks the right one per question.

## Guides

> **[Using Providers](https://agno-v2.mintlify.site/context-providers/using-providers.md)**
>
> Attach providers to agents and configure them.

> **[Custom Providers](https://agno-v2.mintlify.site/context-providers/custom-providers.md)**
>
> Create your own provider for any data source.

> **[Provider Catalog](https://agno-v2.mintlify.site/context-providers/providers/overview.md)**
>
> Browse all built-in providers.

## Resources

> **[Cookbook Examples](https://github.com/agno-agi/agno/tree/main/cookbook/12_context)**
>
> Working examples for every provider


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.