# "Scoping shared memory: per repo, per node, per teammate"

*How kgai scopes team decision memory, and an honest note on what scoping is. Filtering for relevance, not access enforcement. No permissions theater.*

The first question teams ask about shared AI memory is rarely about recall quality. They want to know who sees what. Fair question, and it deserves a straight answer, including the part where we tell you what scoping doesn't do.

kgai, which we build, scopes its decision memory three ways.

## Per repo, by default

Each project gets its own store, created inside the project and nowhere else. Decisions about your side project never land in the company graph. Crossing that line is deliberate. You enroll a repo into a shared store on purpose, the config change is committed and visible, and each teammate approves it on their own machine before it takes effect.

## Per node, at recall

The store is a small graph of domain elements shaped by an append-only decision log. Recall is queried per node, so a prompt can pin a tool to its own subgraph. An agent working on payments reads what's decided about payments, not the whole history of the monolith. That keeps the context the agent gets small and on-topic, which is the practical fix for the [thousand-line CLAUDE.md](https://kgai.dev/blog/claude-md-1000-lines) that tries to brief every agent on everything at once.

## Per teammate, opt-in

A store is local until someone configures a remote. Sharing is opt-in per store, over an S3 bucket your team owns, and a store that never gets a remote never leaves the machine. [Sharing memory with your team](https://kgai.dev/blog/share-ai-memory-with-your-team) happens because somebody chose it, never because a default was left on.

## What scoping is not

Here's the honest part. All of the above is filtering, not enforcement. There are no per-user permissions inside a store. Anything that can read the repo can read the store, because the log is data sitting next to the code it describes. Per-node recall keeps context relevant, it doesn't hide the other nodes from someone who goes looking.

So treat access to a shared store exactly like access to the repos it describes. The bucket credential is a team credential. If a decision shouldn't be readable by everyone who can reach the bucket, don't record it into that store.

Could enforcement, real access control inside a store, come later? It's a possible direction, and we're promising nothing. Today the model is simple on purpose, and you should size your trust to what it is, not to what a settings page implies. We'd rather tell you that plainly than sell filtering as security.

If repo-shaped trust matches how your team already works, the rest is two commands. Local first, shared only when you say so.

## Try kgai

Two commands, MIT, nothing leaves your machine until you configure a bucket:

```
claude plugin marketplace add kgaidev/kgai
claude plugin install kgai@kgai-marketplace
```

Source: https://github.com/kgaidev/kgai
See how kgai compares to other tools: https://kgai.dev/compare
All notes: https://kgai.dev/blog/

---

Canonical: https://kgai.dev/blog/scoping-shared-memory · Written by kgai maintainers · kgai is MIT open source