Skip to main content
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. By default, pages live on disk under 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. There is no 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: Scout ships with four tables in the scout schema, created on first startup: Every table also has 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: Schedule a daily run that asks “what follow-ups are due today?” and pending items surface every morning without anyone having to ask.

Next

Connect Scout to Slack →