01
What is kumbuka?
kumbuka is a shared, curated memory for your team’s AI assistants. Decisions, conventions, constraints and glossary — stored once, governed by your team, and loaded by any MCP-capable assistant at the start of a session. The name is Swahili for “remember!”.
02
How does kumbuka work?
Your team’s knowledge lives as small, typed memory entries — a decision, a convention, a constraint, a glossary term — organized into scopes: global (organization-wide), project (team-shared) and private (one member only). Assistants connect through one MCP endpoint and load a compact digest of the relevant entries at session start, so every session begins already knowing how your team works. New knowledge is stored deliberately — by a teammate in the console, or by telling the assistant to remember it.
03
What is the deal with the six kinds (types) of knowledge?
Every entry carries exactly one of six fixed types, and the assistant treats them differently: a “decision” is a choice your team made and stands by; a “convention” is how you do things; a “constraint” is a hard rule that must not be violated; a “glossary” entry pins what a term means in your team; an “open_question” marks something deliberately undecided yet — parked, not forgotten; and “status” captures the current state of things, the one type that is expected to change often. The taxonomy is deliberately small and closed: types are what make memory loadable as steering rather than a pile of notes — an assistant weighs a constraint differently from an open question, and curation stays honest because every entry must commit to what it is.
04
How is this different from my assistant’s built-in memory?
Built-in memory is personal, opaque, and auto-extracted from conversations — it belongs to one person and one vendor. kumbuka memory is team-shared, deliberately curated (humans decide what goes in), typed and auditable, and portable across every assistant that speaks MCP.
05
There are memory tools out there already — what makes kumbuka different?
Most existing memory tooling is single-user and local, or an auto-extracting layer that mines conversations into a vector store and retrieves by similarity. kumbuka takes the opposite stance: memory as deliberate, governed team knowledge. Entries are explicit and typed instead of mined, loading is deterministic instead of similarity-guesswork, the whole team shares one curated source of truth instead of drifting personal caches — and privacy boundaries are structural, not settings. And kumbuka locks nothing out: it runs happily alongside whatever else your team uses — graph-based knowledge tools included. It owns the steering layer, not your toolbox.
06
I saw a video about a team AI wiki — is that not the same thing?
Close neighbor, different job. A wiki is long-form documentation written for humans and found by searching; assistants can quote it, but nobody guarantees they load the right page at the right moment. kumbuka holds the distilled steering layer: short, typed statements an assistant loads deterministically at every session start, within a predictable context budget. The two work well together — the wiki explains, kumbuka steers.
07
Which assistants can use it?
Any MCP-capable client. Claude, ChatGPT, Mistral’s Le Chat and Grok all speak MCP today, and more assistants are adopting the protocol steadily. One endpoint, one connector setup per member, no per-assistant integration. And because kumbuka is protocol-neutral, it also bridges between assistants: what one model stores, another can load. A decision captured while working in Claude steers the next ChatGPT or Le Chat session, mixed-model teams work from one shared memory instead of per-vendor silos — and knowledge moves freely between the systems through the curated middle. And since every client has its own personality: during the beta we are genuinely keen to hear how kumbuka behaves with yours — feedback about any of these is very welcome.
08
How do I set kumbuka up?
For the hosted beta:
- request access via the form on the home page;
- once approved, you receive an invite — activate your account;
- in the console, find your team’s connector details (the MCP endpoint URL);
- add that URL to your assistant as a connector — in Claude, for example, under Settings → Connectors;
- sign in when the assistant asks — the connection is bound to your personal account;
- start a session and ask the assistant to load the team context.
The one thing to get right: link your AI projects to kumbuka scopes. The connector is one per member and tenant — it does not know which of your projects a given chat belongs to. So create a kumbuka scope per project, and pin that scope in the project’s instructions on the assistant side (one line, along the lines of: “at session start, load context from the scope billing-platform, and store new memories there”). That single convention keeps every project’s memory clean and loaded at the right moment; skipping it is the most common setup mistake — the assistant is left guessing where to read and write. The docs at docs.kumbuka.ai show the exact wording to use.
Self-hosting the Community Edition instead: the README at github.com/kumbuka-ai has you covered.
09
How do I use the console?
The console is your team’s curation surface: browse and search memory entries, filter by type and scope, add or retire entries, manage members and roles, set the default write policy, and manage the connector (endpoint, client id, and a one-click secret rotate as kill-switch). Day-to-day memory work happens naturally in your assistant; the console is where the team governs it.
10
What is the difference between the Community and the Enterprise edition?
The Community Edition is the open-source core: self-hosted, single-tenant, the full memory model with scopes, the private-memory guarantee and the MCP interface — AGPL-licensed, free forever. The hosted platform runs that same core as a managed, multi-tenant service. Enterprise capabilities — context documents, versioning and richer governance — are in active development and will roll out incrementally as optional features on the hosted platform.