Knowledge wiki and CRM

Two always-on providers that turn Scout into a closed-loop company brain.

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

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.

Tool	Does
query_voice	Reads the style guide

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:

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 ships with four tables in the 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[]

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:

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'.

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 →