Scout: Open-Source Company Intelligence Agent by Agno
Open Source Company Brain
At a glance
- What is it?
- Scout is a Docker-based Python agent that navigates Slack, Google Drive, wikis, and CRM data on demand by calling sub-agents behind each source, and builds its own persistent wiki and CRM as it learns about a company.
- Who is it for?
- Scout fits teams that need a conversational interface over fragmented company knowledge sources without sending data to a third-party knowledge management product. The prerequisite is Docker and an OpenAI API key; integrating Slack or Google Drive requires additional credentials documented in the `docs/` folder.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 82 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 28, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What Scout Is and Who It Is For
Company knowledge typically lives across Slack threads, Google Drive folders, wikis, and CRM entries. Pulling it together for a specific question usually means searching each source manually. Scout addresses this by giving teams a single conversational agent that navigates those sources on demand and writes the things it learns back to its own wiki and CRM.
The README frames the design goal in terms of Y Combinator's Summer 2026 Request for Startups, which named "Company Brain" and "AI Operating System for Companies" as wanted ideas. Scout's approach is to assemble context on demand rather than ingest everything up front, and to persist what it learns in a structured form. It is open-source, self-hosted, and targeted at teams that want to keep company data off external services.
The WorkspaceContextProvider, which is always on, roots itself at the Scout repository directory. This means Scout can answer questions about its own codebase without any additional configuration. The description in the README's context provider table is explicit: `query_workspace` is "rooted at the scout repo, so Scout can answer questions about its own codebase."
Navigation Over Search: How Scout Queries Sources
The README makes a design argument worth understanding. The default approach to knowledge retrieval is to ingest everything into a vector database, chunk it, embed it, and search. Scout's authors argue this does not work well for company knowledge. Instead, they adopted what they call navigation: the same strategy coding agents use when exploring a codebase with `ls`, `grep`, and file opens.
Scout implements this through a context provider architecture. Each information source gets its own sub-agent that owns the quirks of that source. Slack pagination by cursor, thread fetching via `conversations.replies`, and user lookups happen inside the Slack sub-agent. Scout's main context never sees those implementation details. It sees only `query_slack` and `update_slack`. This thin interface solves three problems: context pollution from too many tools, degraded performance from overlapping tool scopes, and the main agent losing track of its task because its context is filled with tool quirks.
All currently available context providers are listed in the README's table: `WebContextProvider` (always on), `WorkspaceContextProvider` (rooted at the Scout repo), `DatabaseContextProvider` for CRM, `WikiContextProvider` for knowledge and for voice (the style guide), `SlackContextProvider` (requires `SLACK_BOT_TOKEN`), `GDriveContextProvider` (requires `GOOGLE_SERVICE_ACCOUNT_FILE`), and `MCPContextProvider` for any registered MCP server.
The MCPContextProvider registers each server defined in `scout/contexts.py`, supporting stdio, SSE, and streamable-HTTP connection types. Each server gets its own `query_mcp_<slug>` tool exposed to the main agent. Adding a new MCP server means adding its entry in `contexts.py` and restarting the application. The Web backend uses the Parallel SDK when `PARALLEL_API_KEY` is set; without that key, it falls back to the free Parallel MCP server.
Installing Scout and Running It Locally
Scout requires Docker Desktop. The README's quick-start:
git clone https://github.com/agno-agi/scout && cd scoutcp example.env .envSet `OPENAI_API_KEY` in the `.env` file, then:
docker compose up -d --buildScout runs at `http://localhost:8000` after the build completes. The `compose.yaml` starts two services: `scout-db` (a pgvector-enabled PostgreSQL image at port 5432) and `scout-api` (the application at port 8000). The `RUNTIME_ENV: dev` environment variable disables the JWT-based RBAC that is active in production.
For chat access, the README directs users to connect via AgentOS at `os.agno.com`. Alternatively, Scout can be added to a Slack workspace using the guide in `docs/SLACK_CONNECT.md`.
The Wiki and CRM Scout Builds Itself
Scout does not just read from existing sources. It writes back. As it answers questions and processes information, it populates two persistent stores: a markdown wiki under `wiki/knowledge/` and a PostgreSQL-backed CRM. The README gives concrete examples of what this looks like in practice. When someone says "Josh from Anthropic shared a new RLM paper," Scout adds Josh to the CRM, parses the paper into the wiki, and links the two entries. A request to track a coffee order creates a new table in the CRM on demand.
The wiki is git-backed. The `docs/WIKI_GIT.md` file documents how to set this up so changes are versioned and can be reviewed as commits. The style guide used for drafting Slack messages, emails, and long-form posts lives in a separate `WikiContextProvider` mounted at a different path. This separation means the style guide is always queried before drafting communications but is not mixed with the general knowledge wiki.
Deploying Scout to Railway
For production, the README documents a Railway deployment. The process starts with the Railway CLI and `railway login`, then:
./scripts/railway/up.shThis provisions a PostgreSQL service and the application service on Railway. After the first deploy, the application will fail until a `JWT_VERIFICATION_KEY` is set. The README explains this directly: production endpoints require RBAC authorization, and without a verification key the app refuses to serve traffic. The key is generated from AgentOS by connecting the Railway domain and enabling token-based authorization.
Three maintenance scripts exist: `scripts/railway/up.sh` for initial provisioning, `scripts/railway/env.sh` for syncing `.env.production` to Railway, and `scripts/railway/redeploy.sh` for pushing code updates.
Limitations and Alternative Tools
Scout is wired to OpenAI by default. The `pyproject.toml` lists `openai` as a direct dependency. Swapping to another model provider requires changing the application code; there is no model configuration parameter exposed in `.env` or `example.env`.
The eval suite commands are documented in the README. To run wiring invariants without an LLM: `python -m evals wiring`. For behavioral cases: `python -m evals`. For a single case: `python -m evals --case <id>`. For LLM-scored quality evaluation: `python -m evals judges`. The full eval documentation is in `docs/EVALS.md`. These commands are useful during development but require a running Scout instance and configured connections for the behavioral and quality tiers. The wiring tier, which checks code-level invariants, can run in a clean environment with no credentials, making it suitable for CI.
Notion AI is a comparable alternative for teams that already store knowledge in Notion. It runs as a hosted product and queries content within the Notion workspace. Scout differs by being self-hosted, by extending to Slack and Google Drive, and by actively writing new knowledge back into structured stores rather than only querying existing content.
The repository's last push was on 2026-07-10. The Apache-2.0 license permits commercial use. The `pyproject.toml` lists `agno[os,slack]==2.7.0` as the core dependency, which pins the Agno framework version. Updates to that framework will require a corresponding update to Scout's dependency declaration. The `requirements.txt` is generated by the repository's own `scripts/generate_requirements.sh` script, meaning dependency updates go through that script rather than direct edits.
Editorial conclusion
Scout fits teams that need a conversational interface over fragmented company knowledge sources without sending data to a third-party knowledge management product. The prerequisite is Docker and an OpenAI API key; integrating Slack or Google Drive requires additional credentials documented in the `docs/` folder. Before deploying Scout to production on Railway, read the RBAC note in the README carefully: without a `JWT_VERIFICATION_KEY` from AgentOS, the production endpoint refuses all traffic by design. The repository had its last push on 2026-07-10 and carries an Apache-2.0 license.
Frequently asked questions
Does Scout require an OpenAI API key to run?
The pyproject.toml lists openai as a direct dependency and the example.env has an OPENAI_API_KEY field. The README's quick-start sets this key before starting the containers.
How does Scout store the knowledge it gathers?
Scout writes knowledge to two stores: a markdown wiki in the wiki/ directory (optionally git-backed) and a PostgreSQL CRM database backed by pgvector.
Can Scout read from MCP servers?
The MCPContextProvider supports stdio, SSE, and streamable-HTTP connections. Each registered server gets its own query_mcp_slug tool. Configuration is done in scout/contexts.py.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/agno-agi-scout)