Beever Atlas: A Wiki-First Knowledge Base Built From Team Chat

The problem Beever Atlas targets: chat history that nobody can search

Team knowledge accumulates in channels. A decision gets made in a thread, a project name gets coined in a different channel, and the person who needs both facts six months later has no way to join them. Search inside Slack or Teams returns messages, not answers, and it cannot tell you that the same decision was restated three times by three people. Beever Atlas is aimed at that gap. The README describes it as pulling conversations from Slack, Discord, Microsoft Teams and Mattermost, extracting atomic facts, deduplicating them, and clustering them into topic pages with citations. The intended reader is a team that already has the conversations and wants a knowledge base that grows on its own from them, rather than a wiki someone has to maintain by hand. The topic list confirms the scope: agent-memory, rag, knowledge-base, mcp-server. This is infrastructure for an organisation, not a utility script.

Dual memory: a 3-tier semantic store plus a graph store

The architecture section is specific about the shape. Conversations from any supported platform flow into one ingestion pipeline that produces two memory systems. The first is a 3-tier semantic store organised as channel, topic and atomic fact, which serves hybrid search. The second is a graph store that extracts entities and their relationships. Those two memories feed two consumer surfaces: the LLM Wiki and the QA Agents. The QA side is described as having a smart router that picks semantic or graph retrieval per question, which is the part worth scrutinising. A router means a classification step before retrieval, and a misrouted question is answered from the wrong memory. The README claims this keeps latency low and context precise, but it does not publish routing accuracy or a fallback path when the router is wrong. Treat the router as the component to test first with your own question mix. Underneath, three services (backend, bot, frontend) sit on four data stores: Weaviate, Neo4j, MongoDB and Redis. That is the real cost of the design, and it is stated plainly rather than hidden.

The 6-stage ADK pipeline and what it produces

Ingestion is described as a 6-stage ADK pipeline built on Google ADK, which distils messages into atomic facts, entities and relationships. The README does not enumerate the six stages, so the internal ordering is not something you can verify from the repository description alone; the documentation site at docs.beever.ai/atlas is where the pipeline detail lives. What is clear is the output contract. Messages become atomic facts, facts are deduplicated, and facts are clustered into topic pages carrying citations. The wiki is generated per channel and includes an overview, topics, people and decisions. Two properties follow from that. First, deduplication is the mechanism that makes retrieval cleaner than raw message search, and its quality depends on the extraction step being consistent across phrasing. Second, the wiki is a first-class artifact. The README argues that retrieval works against clean, deduplicated knowledge rather than noisy chat history, and that the wiki is useful to browse independently of the Q&A interface. That claim is the project's central bet: spend compute up front on distillation so that queries are cheaper and more consistent. It is a defensible bet, but it front-loads LLM cost onto ingestion rather than onto query time.

Running it: services, stores and the MCP surface

The repository is Python, Apache-2.0 licensed, and laid out as three services backed by four data stores. The README names Weaviate, Neo4j, MongoDB and Redis explicitly, and the v0.2.0 release notes add pluggable embeddings, which means the embedding provider is a configuration decision rather than a fixed dependency. The MCP server arrived in v0.1.2 and is exposed to Claude Code and Cursor; the README states 28 tools with per-agent auth. The dashboard and the MCP server are two delivery surfaces over the same memories, so an agent you already use can query the knowledge base without you building a UI. What the supplied material does not give is a compose file, an environment variable list, or a first-run command sequence. The README points to docs.beever.ai/atlas for the architecture overview and component responsibilities. If you are evaluating this for adoption, the absence of an install transcript in the repository description is itself a signal: budget time for reading the docs site before you can estimate deployment effort.

Where Beever Atlas is the wrong tool

The four-store requirement is the first hard boundary. If your team cannot operate Weaviate and Neo4j alongside MongoDB and Redis, the project is not for you, regardless of how good the wiki output is. The second boundary is the ingestion path itself. The README lists Slack, Discord, Microsoft Teams, Mattermost and file imports as sources. It does not describe a connector for email, ticketing systems, or code review comments, so knowledge that lives outside chat stays outside the wiki. The third is the distillation bet. Because the pipeline converts messages into atomic facts before any query runs, an extraction error propagates into the wiki and into every answer that cites it. A raw-snippet RAG system degrades more gracefully: a bad retrieval returns the wrong message, while a bad fact returns a wrong statement presented as knowledge. The README does not describe a correction or review workflow for facts that the pipeline got wrong, and that is the limitation I would press hardest on during an evaluation.

How this differs from raw-snippet RAG

The obvious comparison is a conventional retrieval-augmented generation stack: embed the messages, store the vectors, retrieve the top matches at query time, and hand them to a model. The README frames the difference directly, describing most RAG systems as retrieving raw message snippets and feeding them straight to an LLM, while Beever Atlas distils conversations into a structured wiki before any query is issued. The practical consequences run in both directions. Conventional RAG has a shorter path from message to index, so new content is searchable almost immediately and there is no extraction step to get wrong. Beever Atlas inserts a distillation stage, which means ingestion latency and LLM cost per message, but the retrieval layer sees deduplicated facts and can cite the source messages behind each one. Conventional RAG also has no browsable artifact; you get an answer or you get nothing. Whether the distillation stage earns its cost depends on how repetitive your channels are. In a channel where the same decision is restated five times, deduplication is doing real work. In a low-volume channel, it is overhead.

Maintenance, releases and the licence

The release cadence visible in the material is three releases between April and May 2026: v0.1.1 as the open-source launch, v0.1.2 adding the MCP server and CodeQL hardening, and v0.2.0 adding the wiki narrative engine, an Obsidian-style graph view, and pluggable embeddings. The repository was last pushed on 2026-09-09 and is not archived. The project is still on a 0.x version, which in practice means the API surface and the MCP tool set can change between minor releases; v0.2.0 changing the embedding layer is an example of that. Upgrading therefore carries a real cost, particularly if you have written MCP clients against the 28 tools. On licensing, the project is Apache-2.0, which permits commercial use and modification and includes a patent grant; it also requires that you preserve copyright and licence notices and state significant changes. That is a summary of the licence, not legal advice, and the obligations around bundled assets and any hosted service you build on top are worth checking with counsel. The four backing stores carry their own licences, and Neo4j in particular has a distinct licensing model from Weaviate, MongoDB and Redis, so the effective licence picture of a deployment is not just Apache-2.0.

Editorial conclusion

Adopt Beever Atlas if your team already lives in Slack, Discord, Teams or Mattermost, you are willing to operate three services and four data stores (Weaviate, Neo4j, MongoDB, Redis), and you want the wiki as a browsable artifact rather than only a retrieval index. Do not adopt it if you need a single-process library, if your chat history cannot leave your platform's export tooling, or if you cannot run Neo4j and Weaviate side by side. Before committing, verify the 6-stage ADK pipeline against your own channel volume, confirm the resumable sync behaviour on a rate-limited workspace, and check which embedding provider the v0.2.0 pluggable embeddings path expects.

Official sources

1. Beever-AI/beever-atlas on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases