What is Scout?

An open-source context agent that navigates live information sources to assemble answers.

Scout is an open-source context agent. It navigates Slack, Google Drive, the web, your codebase, and any MCP server you point it at to answer questions about your company. As it works, Scout files what it learns into its own wiki and CRM so the next answer is faster.

Why Scout exists

Every company has critical know-how scattered across Slack threads, support tickets, shared drives, and people’s heads. The default playbook for a “company brain” is to ingest everything into a vector database, embed, and retrieve top-k chunks. The index is always stale, the chunks land at the wrong boundaries, and citations point at fragments that were true last Tuesday.

Coding agents figured out a better pattern. Don’t search, navigate. ls a directory, grep for a function, open the file, follow the import. Scout applies the same pattern to your information sources.

Navigation over search

Every source has the equivalent of ls, grep, and cat. Slack has search and conversations.replies. Drive has folder listings and file fetches. Postgres has SQL. Scout walks these primitives at query time instead of pre-indexing.

The trade is more LLM calls per query. The wins:

Win	What you get
Live state	The Slack message you sent thirty seconds ago is queryable.
Real citations	Every reference is a path you can open. No fragment from an embedding boundary.
Permissions stay where they live	Drive enforces who can read what. Slack enforces channel membership. Scout sees what its credentials see.

Context providers

Each source is a ContextProvider that exposes two natural-language tools to Scout:

• query_<source> for reads
• update_<source> for writes (when supported)

A sub-agent behind each provider owns the source’s quirks. Scout sees query_slack. Behind it, a sub-agent knows to look up the user before DMing, paginate by cursor, and prefer conversations.replies for threads. Scout’s context never sees any of that.

This solves three problems that hit any agent with a diverse tool surface:

Problem	What context providers do
Context pollution from too many tools	Scout sees query_slack, not Slack’s twelve tools.
Degrading performance from overlapping scopes	Each sub-agent owns one scope. Routing is one tool call.
Main agent forgets its job	Tool quirks and intermediate results stay in the sub-agent.

Skills don’t solve this. Skills move task knowledge out of the always-on prompt, but when the skill loads, the source’s tools and intermediate results still land on the main agent’s context. Two skills with search capabilities will degrade the agent fast.

Providers that ship with Scout

Five always on. Three opt in via env vars or config.

Provider	Tools	Trigger
Web	query_web	Always on. Parallel’s public MCP by default; upgrades to the Parallel SDK when PARALLEL_API_KEY is set.
Workspace	query_workspace	Always on. Read-only, scoped to the Scout repo so Scout can answer questions about its own codebase.
CRM	query_crm, update_crm	Always on. Local Postgres with scout_contacts, scout_projects, scout_notes, scout_followups.
Knowledge wiki	query_knowledge, update_knowledge	Always on. Prose memory Scout files into. Filesystem by default; swap to a Git repo for production.
Voice wiki	query_voice	Always on. Read-only style guide for how Scout writes external content.
Slack	query_slack	When SLACK_BOT_TOKEN is set. Read-only. The Slack interface handles posting.
Google Drive	query_gdrive	When GOOGLE_SERVICE_ACCOUNT_FILE is set. Read-only, scoped to folders shared with Scout’s service account.
MCP servers	query_mcp_<slug> per server	Wired in scout/contexts.py. Linear, GitHub, Notion, anything with an MCP server.

The closed loop

Some context doesn’t have a natural source home. “Josh from Anthropic shared a new RLM paper” belongs in a CRM and a wiki, not in a Slack search.

Scout’s CRM and wiki fill that gap. As Scout works:

• “Josh from Anthropic shared a paper” → Josh becomes a contact, the paper becomes a wiki page linked from his note.
• “The v3 schema migration decision is pending” → a follow-up in scout_followups with status='pending'.
• “Track my coffee orders” → the CRM write sub-agent creates scout.scout_coffee_orders with the right columns. Schema on demand.

Put a daily cron on scout_followups and the loop tightens. Pending items surface every morning.

Next

Run Scout locally →