Scout: a self-building wiki and CRM on top of Slack, Drive and MCP

The problem Scout targets: knowledge that lives in six places and none of them answer questions

Company knowledge is fragmented across Slack threads, Drive folders, a wiki, a CRM and whatever MCP servers a team has wired up. The README frames the problem through YC's Summer 2026 RFS, which named both Company Brain and AI Operating System for Companies. Scout's own framing is narrower and more useful: the brain is the data layer, the OS runs on top of it, and neither exists as a finished product. Scout is an attempt to stitch the pieces together. The intended user is a team that wants one agent it can ask questions of, and that also wants the answers to accumulate somewhere durable instead of evaporating when the chat session ends. That second half is the unusual part. Most retrieval agents are read-only. Scout writes.

Navigation over search: why Scout does not embed your Slack history

The README is direct about the default approach it rejects: ingest everything into a vector database, chunk it, embed it, and, in the project's phrasing, pray. Scout instead borrows the pattern from coding agents. A coding agent does not embed a repository. It runs ls, then grep, opens the file, follows the import. Scout applies the same loop across Slack, Drive and the rest. The practical consequence is that Scout can answer questions about content that was never indexed, because it reads at query time. The trade-off is latency and cost: every question becomes a sequence of tool calls against live APIs rather than a single vector lookup. The README does not publish latency figures, and there are no benchmarks in the supplied material, so treat the speed question as unmeasured.

One agent, many context providers, two tools each

Scout is a single agent with multiple context providers. Each provider exposes exactly two natural-language tools: query_<source> for reads and update_<source> for writes, where writes are supported. The README lists three problems this thin layer is meant to solve: context pollution from too many tools, degraded performance from overlapping scopes, and the main agent losing its job because its context fills with tool quirks. The mechanism behind the thin surface is a sub-agent per provider. Scout only ever sees query_slack. Behind that name, a sub-agent knows to resolve the user before sending a direct message, to paginate by cursor, and to prefer conversations.replies when handling threads. None of that reaches Scout's context. This is the most defensible design decision in the repository, and it is also the one that makes the system harder to debug: when query_slack returns something wrong, the failure is inside a sub-agent you cannot see from the parent's tool list.

The provider table, and what turns each one on

Five providers are always on. WebContextProvider exposes query_web. WorkspaceContextProvider exposes query_workspace and is rooted at the scout repository itself, so the agent can answer questions about its own codebase. DatabaseContextProvider is the CRM and exposes query_crm and update_crm over contacts, projects, notes and follow-ups. Two WikiContextProvider instances are always on as well: one for knowledge with query_knowledge and update_knowledge, and one for voice with query_voice, described as a code-managed style guide for emails, Slack, X and long-form writing. Three more providers are conditional. SlackContextProvider activates on SLACK_BOT_TOKEN and gives read-only query_slack over messages, channel history, threads and users. GDriveContextProvider activates on GOOGLE_SERVICE_ACCOUNT_FILE and gives read-only query_gdrive over files, folders and contents. MCPContextProvider registers one query_mcp_<slug> per server configured in scout/contexts.py, supporting stdio, SSE and streamable-HTTP. The Web backend uses the Parallel SDK when PARALLEL_API_KEY is set, and falls back to the free Parallel MCP server otherwise.

What Scout writes, and where it lands

The README gives four worked examples of the write path. Saving a note routes to update_crm, and the write sub-agent runs an INSERT into the table scout.scout_notes. Filing a runbook for incident response routes to update_knowledge, and the wiki sub-agent writes a markdown page under wiki/knowledge/runbooks/. Tracking coffee consumption also routes to update_crm, where the write sub-agent creates scout.scout_coffee_orders and inserts the row, which the README calls schema on demand. Drafting a Slack message runs query_voice first to load the style guide, then drafts in that voice. The wiki is git-backed, with a setup guide at docs/WIKI_GIT.md, so the prose memory is versioned alongside the code. The CRM is not described as git-backed, which means the two halves of Scout's memory have different backup and review stories. If you care about auditing what the agent learned, the wiki side is the one you can diff.

Getting it running: Docker locally, Railway for production

The prerequisite is Docker Desktop installed and running. Then: git clone https://github.com/agno-agi/scout && cd scout, followed by cp example.env .env, setting OPENAI_API_KEY in .env, and docker compose up -d --build. Scout then serves at http://localhost:8000. To chat with it, you open os.agno.com, log in, click Add OS, choose Local, enter http://localhost:8000 and connect. Slack integration is documented separately in docs/SLACK_CONNECT.md. For production, the README provides Railway scripts. You copy .env to .env.production and edit it, noting that the file is gitignored and should not be committed. Then ./scripts/railway/up.sh provisions Postgres and the app service on first run. Subsequent code updates use ./scripts/railway/env.sh to sync .env.production to Railway, and ./scripts/railway/redeploy.sh to push code. The scripts read .env.production first and fall back to .env. The README states plainly that your first deploy will fail, and explains why: when RUNTIME_ENV=prd, Scout enables RBAC and refuses to serve traffic without a JWT_VERIFICATION_KEY. You generate one through AgentOS, enable token based authorization, and paste the full PEM block into .env.production without surrounding quotes.

Evals, and the maintenance bill you are signing up for

Scout ships an eval harness with four invocations. python -m evals wiring runs code-level invariants with no LLM involved. python -m evals runs behavioral cases in-process. python -m evals --case <id> runs a single case. python -m evals judges runs an LLM-scored quality tier. docs/EVALS.md is the reference. The wiring tier matters more than it looks: it is the only tier that can run without spending tokens, so it is the one worth putting in CI. The maintenance cost of Scout is not the Python code, which is a single agent plus providers. It is the surface area underneath: Slack API behaviour, Google service account credentials, MCP server availability, the Parallel dependency for web search, and Postgres in production. Each conditional provider is another credential that can expire and another failure mode that shows up as a tool returning nothing rather than as an exception. The supplied material contains no release history, so there is no way to judge how often the provider layer changes. Licence is Apache-2.0, which permits commercial use and modification; the README does not discuss trademark or attribution obligations, and this is not legal advice.

Where Scout is the wrong tool, and what to reach for instead

Two limitations are visible in the material. First, Slack and Google Drive are read-only. Only the CRM, the knowledge wiki and, by extension, arbitrary MCP servers can be written to. If your requirement is an agent that replies in Slack threads or edits Drive documents, Scout does not do that today. Second, the write path is schema on demand. The coffee example shows the write sub-agent creating a new table when no suitable one exists. That is flexible, and it also means the CRM schema is whatever the agent decided it should be, which is a poor fit for a team that needs a stable reporting layer. If your actual problem is retrieval over a large, mostly static document corpus, a vector index plus a reranker is the simpler answer, and Scout's own README argues against that approach for fragmented live sources rather than for document sets. If your problem is agent orchestration across many tools with human review at each step, Scout's always-on providers and automatic writes are the opposite of what you want. The honest comparison is not Scout versus a vector database. It is Scout versus doing nothing and letting the knowledge stay in Slack, which is what most teams actually do.

Editorial conclusion

Adopt Scout if you already have a Slack workspace and a Google Drive you want an agent to read and cite, and you are willing to run Postgres and hand it an OpenAI key. Do not adopt it if you need read-only guarantees across every source, or if you expect the wiki and CRM to be curated by humans rather than written by the agent. Before trusting it, run python -m evals wiring and python -m evals, then open wiki/knowledge/ and scout.scout_notes and read what the agent actually wrote.

Official sources

1. agno-agi/scout on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README