Retrieval is deliberately split three ways — a composed answer, ranked facts within one channel, and a literal substring match — and choosing the wrong one is the usual reason an answer disappoints. Two behaviours are worth knowing before you build on it: find_decisions and find_facts collapse missing auth and access-denied into an empty list, so a bare [] means either nothing matched or you cannot see it; and search_channel_knowledge is a retired shim that returns a rename error and performs no work.
A knowledge layer over chat platform connections — Slack workspaces, Discord servers, file imports — that extracts facts from a channel's messages and answers questions about them with citations.
- Composed answers to a natural-language question about one channel, with citations, and a session id that keeps follow-up turns in the same thread
- Three ways to reach the underlying facts: hybrid BM25-plus-vector ranking inside one channel, the same search fanned across every channel you can reach, and a deterministic case-insensitive substring match
- A compiled wiki per channel — the seven fixed pages, overview, faq, decisions, people, glossary, activity and topics, plus a slug-keyed set you can list, read whole, or open one prose section or structured module at a time
- The decision record: current decisions with their rationale and rejected alternatives, an ordered timeline built from SUPERSEDES edges, and the tensions still unresolved
- The people and entity layer: who in a channel is most knowledgeable about a topic, and the subgraph showing how named entities connect
- Provenance for a single fact — the platform, message, author and timestamp it came from, with the raw message text when it is still reachable
- Ingestion you drive yourself: sync a channel's messages, re-render wiki pages from facts already ingested, and poll either job by its id
Uv with a Python available, and an auth token that resolves to a principal with at least one platform connection — whoami is what confirms both. Apache-2.0.