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.

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:

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())

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	Search and history tools	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.

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 (search, history). 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.

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.

from agno.context.mode import ContextMode

slack = SlackContextProvider(mode=ContextMode.tools)
# Agent sees: search_messages, get_channel_history, get_thread, list_channels, 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 search_messages, 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:

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

Attach providers to agents and configure them.

Custom Providers

Create your own provider for any data source.

Provider Catalog

Browse all built-in providers.

Resources

Cookbook Examples

Working examples for every provider

Runtime Guide

Production patterns: Knowledge, Dependencies, and Context Providers together