Documentation Index
Fetch the complete documentation index at: https://docs.agno.com/llms.txt
Use this file to discover all available pages before exploring further.
The web, workspace, and connected sources answer questions about external data. The knowledge wiki and CRM answer questions about your company: who’s who, what’s in flight, what was decided, what’s pending. Both are always on.
Knowledge wiki
The knowledge wiki is Scout’s prose memory. Runbooks, design notes, decisions, learnings. Anything that doesn’t have a natural source home goes here.
| Tool | Does |
|---|
query_knowledge | Reads pages from the wiki |
update_knowledge | Writes new pages or appends to existing ones |
wiki/knowledge/. For production, swap the storage layer to a Git repo so pages persist across container restarts and you get an audit trail. Setup is in the Railway deploy guide.
Try it
“File a runbook for incident response: page on-call first, post status in #incidents, capture timeline as you go.”
Scout writes wiki/knowledge/runbooks/incident-response.md.
“What’s the runbook for incidents?”
query_knowledge returns the page Scout just wrote.
Voice wiki
The voice wiki is a read-only style guide that lives in wiki/voice/. It tells Scout how to write external content: emails, Slack messages, X posts, long-form copy. Voice rules are committed to the repo and changed via PR, not by the agent.
| Tool | Does |
|---|
query_voice | Reads the style guide |
update_voice. The provider is constructed with write=False, which removes the write tool entirely.
Try it
“Draft a Slack message announcing the launch.”
Scout calls query_voice first to load the style guide, then drafts in that voice.
CRM
The CRM is a Postgres-backed context provider with two tools:
| Tool | Does |
|---|
query_crm | Reads via a read-only engine. Cannot write under any prompt. |
update_crm | Writes via a schema-guarded engine scoped to the scout schema. |
scout schema, created on first startup:
| Table | Purpose | Domain columns |
|---|
scout_contacts | People | name, emails TEXT[], phone, tags TEXT[], notes |
scout_projects | Things in motion | name, status, tags TEXT[] |
scout_notes | Free-form notes | title, body, tags TEXT[], source_url |
scout_followups | Things to come back to | title, notes, due_at TIMESTAMPTZ, status, tags TEXT[] |
id, user_id, and created_at.
Schema on demand
Beyond the four shipped tables, the write sub-agent creates new scout_* tables on demand:
“Track my coffee consumption. First one: flat white, extra shot.”
The write sub-agent generates DDL for scout.scout_coffee_orders (drink, notes, consumed_at), runs it, then inserts the row. Next time you say “two flat whites today”, it just inserts.
The schema guard rejects DDL or DML targeting any schema other than scout. Even if Scout is prompted into running DROP TABLE public.users, the engine refuses.
The closed loop
The CRM and the knowledge wiki turn Scout into a closed loop. Patterns to try:
| Pattern | What Scout does |
|---|
| ”Josh from Anthropic shared a new RLM paper this week.” | Adds Josh to scout_contacts, files the paper as a note linked to his contact, and writes a wiki page summarising it. |
| ”The v3 schema migration decision is pending. Surface it next Tuesday.” | Inserts into scout_followups with due_at set. |
| ”What’s open?” | Reads scout_followups WHERE status='pending'. |
Next
Connect Scout to Slack →
