Enterprise AI knowledge · 2026 — present

Beever Atlas

Team memory for AI agents — a wiki that writes and maintains itself.

AI MemoryGraph memorySemantic memoryMCPRAGRBACGo-to-Market
>2m
Sales pipeline from HK enterprises & APAC clients
#453
of 18,000+ MCP servers on PulseMCP

01About

What it is

Beever Atlas plugs into the places work happens — Slack, Discord, Teams, and in v2 Drive, Jira, and email — and turns scattered conversation into a searchable wiki that maintains itself. Every fact keeps its citation and its permissions.

Beever Atlas Q&A chat interface
Ask the wiki, get a cited answer — the core interaction, backed by permission-aware search across every connected source.
Beever Atlas semantic wiki page
The wiki itself — every page self-maintaining, every fact still carrying its citation back to the original thread.
Beever Atlas graph memory view
The memory graph underneath — facts and their relationships, not just flat search results.
Beever Atlas data ingestion pipeline
The ingestion pipeline that turns a scattered thread into a structured, permission-tagged fact.

02How it works

01

Sources

Slack · Teams · Drive · Jira

02

Ingest & cite

Every fact keeps its source

03

Memory spaces

Semantic + graph, RBAC applied

04

Living wiki

Pages recompile themselves

Agents over MCP — AI agents read and write the same memory

03My role

I joined during v1 development. My leverage: go-to-market, positioning, and brand — plus the v2 product direction.

The PM half

  • Oversee product roadmap and shipping strategy
  • Tap into B2B channels for discovery and adoption
  • Designed the licensing and cross products pruchasing flow
  • Reframed v2 from chat memory to cross-source memory spaces with RBAC

The UX/UI half

  • Set the brand accent and a logo system that switches with light/dark themes
  • Directed and shipped the explainer-site polish in AI pair-programming sessions
  • Prepare sales team go to market materials and narratives
  • Specced an expand-and-pan viewer for the architecture diagrams

04Use case

Use case 01

Ask the wiki, get a cited answer

  1. 01

    Ask Beever Altas: "Who made this decision?"

  2. 02

    Atlas searches chat, docs, and tickets. Scope to what the asker can see.

  3. 03

    Answer with a cited result.

Why did we move off per-channel memory?

v1 scoped access by channel, not by reader1. v2 moved to a Space model, so visibility is a property of each fact.

Decision: per-channel → Space-based memorycited
Use case 02

Pull memory into Claude Code, mid-task

  1. 01

    A teammate working in Claude Code.

  2. 02

    The Agent decides to use Beever Atlas skill to call MCP

  3. 03

    It returns cited facts, permission-mirriored for the agent.

claude code

> /beever-atlas-memory "what's our RBAC decision?"

⏺ beever-atlas MCP · ask_wiki

⎿ 1 wiki page cited — Space-based RBAC decision

Space-based RBAC keeps visibility a property of each fact, not the channel it came from.

05Challenges & solutions

Technical

v1's permissions followed the channel, not the reader — access tracked what a connection could see, not who was actually asking.

Redesigned around a Space container with per-fact access, so visibility belongs to each fact rather than how it was connected.

Business / market

Self-hosted and enterprise competed on the same features — everything given away free was one less thing to sell.

Moved the moat from features to operations: keep the mechanism free, sell the tenant, permission, and hosting layer around it.

People / process

v1's in-channel bot answered with whatever it could see, not what that channel's members were actually entitled to — a live RBAC gap.

Pulled the feature rather than ship a known gap, ahead of the v2 redesign that closed it properly.

Beever Atlas answering a question directly inside a Slack channel, citing a source
The removed feature — the bot answering in-channel, citations included. Names redacted for this portfolio.

06UX / UI

The explainer site

The explainer site is the front door for a skeptical technical audience. I directed the polish pass and implemented it live — working in CSS variables, not handing over a spec.

Trust is the UX

The product UX that matters most is trust: a "Viewing as" switch lets an admin preview the wiki exactly as another permission-holder would see it.

No metadata leaks

Folders only appear if you can see at least one page inside — a restricted folder's name never leaks.

Viewing as Admin (you)

  • Overview
  • People & Experts
  • Decisions
  • Client Contracts
  • FAQ
  • Glossary

Viewing as Contractor

  • Overview
  • People & Experts
  • FAQ
  • Glossary

Same wiki, two viewers — the two hidden folders were never in the response the contractor received.

07System decisions

  • One codebase, two editions — config is the lever, not a fork.
  • v2 splits one overloaded "channel" field into four coordinates, so visibility can't accidentally leak.
  • A background "dreamer" re-clusters themes and reconciles contradictions while the team sleeps.
  • Deny-by-default for any source without a machine-readable access list.
  • Battle-tested the architecture with a PoC that processed 700GB of data in two weeks, before committing to the v2 build-out.
  • Made the call to move from v1 (channel-based memory) to v2 (space-based, source-agnostic) — the model needed to change to unlock new business opportunities, not just to fix the permission gap.
  • Aligned the team around one vision: as an AI SaaS, compete on result quality, not quantity — a value-based solution, not a volume one.

08Workflow tools

  • Claude Code — Primary agentic dev environment for the explainer site and multi-file work.

  • Linear — Milestones and tickets for the gated v2 roadmap.

  • PostHog — Product analytics, session recording, and usage tracking.

  • Langfuse — Tracing and logging for the AI agents.

  • GitHub — Repo, CI, and registry/directory-listing visibility as a public growth signal.

  • Mermaid — Architecture and permission diagrams, authored as code.

  • CLI toolbelt (gh · GWS CLI) — Registry submissions and workspace ops straight from the terminal.

  • AI infographic HTMLs — I generate one-page explainer infographics as HTML to align the team fast.

09Data

The data boundary

Atlas only ingests what a team already owns, and permission is a property of every single fact.

Sources

  • Chat: Slack, Discord, Mattermost, Microsoft Teams (v1)
  • Docs and tickets: Google Drive, Notion, OnceDrive, Jira, etc. (v2)
  • Email — shared team mailbox or strictly personal (v2)
Beever Atlas connector settings
Connector setup — Slack, Discord, and Teams today, Drive and Jira landing in v2.

Where it sits

Same conversation as Glean or Notion AI — but callable by any AI agent over MCP as a self-hostable memory layer, not a closed search box.

10AI

  • Three memory layers: semantic (Weaviate), graph (Neo4j), and a generated wiki on top.
  • Every answer streams back with citations to the source message.
  • Images and PDFs share one vector space with text (Jina v4 embeddings).
  • Runs fully self-hosted (LiteLLM → Ollama/vLLM) when data can't leave the building.
  • Agent-operated end to end: exposed over MCP, so agents drive it — humans keep the one consent click.
WeaviateNeo4jOllama