How to build a company brain for AI

Collect ten questions people actually ask: from support tickets, chat threads and onboarding notes. Next to each, write who asks it and which system holds the answer. You will notice that two or three sources answer most of them. Start with one.

Pick a first source that is well organised and has clear owners, such as a policy wiki or a documentation space. Avoid chat and email at the start. They hold the most useful context and the hardest permission problems, because access depends on who was in each conversation. Do the easy permission model first and let the design harden.

Keep the ten questions. They become your test set in step 9, and they stop the project turning into "index everything".

For every source you plan to connect, record the owner, how it exposes permissions, how often it changes, and how sensitive it is. The permission column is the one that decides the work. Some systems give you an access list per item through an API. Some only expose roles on a folder. Some do neither, and you will have to decide whether to exclude them.

Write the rule for the unknown case now: if you cannot read an item's access list, the item is invisible to everyone except its owner. Public by default is how a brain leaks. The same rule applies when a sync of permissions fails halfway.

Also write the exclusion list. Credentials, API keys and password vaults stay out. Strip secret-looking strings before storage, and treat personal data as local-only unless there is a recorded reason to index it.

The same person appears as a Microsoft account, a Google account, a Git username and a ticketing login. If you cannot say those are one person, you cannot apply their permissions. Match accounts to a person by a stable key first (employee identifier, then email), record which key matched in match_evidence, and send anything uncertain to a human. Never merge on display name.

Read group membership from the directory with a read-only account. In Microsoft Graph, the transitive membership call returns groups the user belongs to directly or through nesting, which is what you want, because a nested group still grants access. The default page size is 100 and the maximum is 999, so follow the paging links. When you cast to groups, Microsoft documents that the ConsistencyLevel: eventual header and $count are required, and that the index behind it may lag recent changes. The application permission needed to read another user's memberships is User.Read.All as least privileged, per Microsoft's documentation.

For per-file permissions in Google Drive, the permissions list call returns who has access to one file. Request only the fields you need, page through the results and use a read-only scope.

Keep it in one database to start. Every item records where it came from (source_id, source_ref), which version it was, a content hash, when it was retrieved and the list of principals allowed to read it. A principal here is a string such as user:42 or group:engineering; the identity step produces them. The chunks table carries a denormalised copy of that list so one indexed filter can serve the search.

The facts table is the graph, kept small: subject, predicate, object, the item that is the evidence, when it was observed and a status. Five statuses are enough to begin with: observed, verified, inferred, stale and disputed. A status you never use is clutter; a status you cannot show on an answer is worse.

Embeddings use vector(768) to match the embedding model in the RAG guide. Change it if you use another model. The GIN index on the principals array supports the overlap operator, and the HNSW index uses cosine distance, as the pgvector README documents.

Application code that adds WHERE allowed_principals && ... will be forgotten in one place eventually. Add row-level security as a second lock. When it is enabled, Postgres says all normal access must be allowed by a policy, and with no policy the default is deny. Superusers, roles with BYPASSRLS and table owners normally bypass it, so connect your application as a role that owns nothing, and use FORCE ROW LEVEL SECURITY so that even the owner is subject to it.

The policy reads the caller's principals from a transaction-local setting. Postgres accepts a custom two-part setting name such as app.principals without declaring it, and set_config with its third argument true applies the value to the current transaction only. Passing true to current_setting returns NULL instead of an error when it is unset, which turns into "no rows". The value must come from your authentication layer, never from anything the user typed.

For each source, a sync lists items, fetches each item's content and access list, resolves the access list into principals using the identity tables, and upserts. The upsert below touches a row only when the content hash or the access list changed, so a nightly run is cheap and a permission change takes effect on the next run. Chunk and embed changed items as in the RAG guide, copying the principals onto every chunk.

Two details earn their place. First, write the access list and the content in the same transaction, so a chunk is never stored with a stale list. Second, record the sync start time before listing, because the deletion sweep in the next step compares against it. If the sync fails, do not run the sweep.

A brain that returns last year's policy with confidence is worse than none. After a complete sync, mark any item the source no longer returned as deleted, and make every query exclude deleted items. Run the sweep only after a full successful pass, or a half-finished sync will hide half your content.

Facts age differently from documents. Decide how long each kind stays trustworthy without new evidence (ownership might be six months; a price list might be a week) and mark facts stale when they pass it or when their evidence item is deleted. Show the status and the date next to any answer that relies on a fact. People forgive an answer that says "last confirmed in March"; they do not forgive one that does not say.

Permissions need their own schedule. Sync access lists more often than content, because a person leaving a group should lose access within hours, not weeks.

Pass the retrieved chunks to the model with their titles and dates, ask it to cite them, and show those citations to the user. The model should be told that if the sources do not contain the answer, it must say so. Return the item title, link, version and retrieval date with each citation, plus the status of any fact used.

Write an audit record for each question: who asked (the verified identity), the question, which items were retrieved, which model answered and when. This is how you answer "who could have seen this?" and "what did the assistant know when it said that?". Keep the log append-only and restrict who can read it, because it contains the questions themselves.

If agents, not people, will use the brain, give each agent its own identity and its own principals. An agent that borrows a human's access list can read everything that human can. See how to govern AI agents.

Reuse the ten questions from step 1 and add four kinds of test. Permission tests: ask a question as a caller who must not see the answer and assert that no chunk from the restricted item appears. Deletion tests: delete a source item, run the sweep and assert it no longer appears. Freshness tests: change an item's content and permissions and assert both changes show after the next sync. Refusal tests: ask something the sources cannot answer and assert the system says so.

Run the permission tests as a gate: any leak fails the build. Then prove the gate works by removing the row-level policy in a test database and confirming the permission test fails. A test you have never seen fail is a guess.

Track two numbers over time: the share of your ten questions the brain answers correctly with a valid citation, and the share of items whose access list was synced in the last 24 hours. If the second falls, your permissions are rotting even if the first looks fine.