A company AI has two problems, and memory is the easy one
Ask a general-purpose AI assistant to summarize what your team decided about the raise and it will do something reasonable. It searches, it reads, it writes a tidy paragraph. Ask the same question inside a company that has a board, a cap table, and a confidential folder, and that reasonable answer becomes the wrong one.
The right answer depends on who is asking. A board member asking about the raise should get the board's discussion. An operations hire who joined last month, typing the same eight words, should get only the part they were already cleared to see. Same company, same question, two different correct answers.
Most AI memory systems are not built to produce two answers. They are built to produce the best one. That is the gap we spent the last stretch of engineering closing, and this post is the argument behind the design.
The model is never the source of truth
The first rule we wrote down, before any code: the language model does not know anything about your company. It reasons over what the system hands it. Your directors, your entities, your filings, your decisions, your ownership records live in ordinary structured data, and that data is the truth.
This sounds like a limitation. It is the opposite. A model asked to generate facts about your governance will eventually generate a wrong one, and a wrong fact about who approved a share issuance is not a typo. It is a governance problem that surfaces years later in diligence. A model that only reasons over records can be checked against the records.
In practice that means we do not ask the AI when an annual report is due and trust what comes back. The system looks the deadline up in the rules, hands the model the result, and lets the model explain it in plain words. The same holds for authority questions and for filing requirements. The Decision Engine holds the decisions. The model reads them.
A useful test for any AI product: ask it something factual about your own company, then ask it where it got that. If it points at a record you can open, it is reasoning. If it explains its reasoning instead, it is writing.
Filter the memory before the model reads it, never after
This is the most important design choice in the system, and the one we would defend hardest: a permission check belongs at retrieval, not in the prompt.
The tempting shortcut is to hand the model everything and add an instruction along the lines of do not reveal board material to non-board users. That is not a control. That is a request. Prompt instructions are guidance, and prompt injection, where a hostile instruction is hidden inside a document the AI is reading, sits at the top of OWASP's Top 10 for LLM Applications for exactly this reason.
So we do the boring thing. Before the model sees a single word, the candidate memories are narrowed to the set the asking person is cleared for. Material outside that set never enters the prompt. There is nothing for the model to leak and nothing for a hidden instruction to unlock, because the text is not in the room.
Default-deny does the quiet work here. A memory whose clearance the system can't establish is treated as off-limits rather than as public. An unclassified document is the most dangerous kind, so it gets the strictest handling, not the loosest.
| Scope | The question it settles | What it prevents |
|---|---|---|
| Organization | Whose memory is this? | An adviser serving two clients never gets a blended answer |
| Clearance tier | What level does this person hold? | Board material staying out of a staff-level answer |
| Person | Is this somebody's private working record? | Your own notes surfacing in a colleague's recall |
| Entity | Which company in the group? | A subsidiary manager pulling from the parent or a sibling |
The scopes compose. A staff member in a multi-entity group gets the intersection, not the union.
The point of composing them is that clearance is not one number. A person is simultaneously a member of an organization, a holder of a role, an individual with private notes, and someone assigned to some entities and not others. Any one of those alone is a leak waiting to happen.
Recall is a router, not a search box
The second lesson cost us the most time, and it runs against the grain of how most retrieval systems get built: not every question should go through embeddings.
Vector search is genuinely good at what is our risk posture on the raise, because that is a question about meaning spread across many documents. It is bad at how many filings are overdue, because counting is not a fuzzy problem and semantic similarity is a fuzzy instrument. Pointing every question at the same index is the most common way a company AI ends up confidently approximate.
| What the person asks | What they actually want | Where it should go |
|---|---|---|
| “What did I do on June 17?” | A precise, dated record | A direct database query |
| “How many filings are overdue?” | A count, correct to the unit | A direct database query |
| “What is our governance posture?” | Meaning across many documents | Semantic search over embeddings |
| “List every party across our contracts” | A complete enumeration | The relationship graph |
Sending all four down the vector path produces four plausible answers and two correct ones.
That last row deserves more attention than it usually gets. Ask a vector search to list every party across your contracts and it returns the handful of most similar passages. That is a sample, not a list, and the difference only shows up when the missing party is the one that mattered. Enumeration needs structure.
The knowledge graph is the database you already have
Does an AI business brain need its own graph database?
Usually not. If a company already stores people, roles, entities, decisions, and documents in a relational database, the relationships between them are already recorded and already permissioned. Adding a separate graph database means keeping two stores in agreement, doubling the places a permission rule has to be right. The case for one is narrow, and for a governance product the declared records carry most of the weight.
We looked seriously at standing up a dedicated graph database and decided against it. The company's structured records already are the graph. A person holds a role. A role sits on a board. A board governs an entity. A decision is supported by a document and produces a task. Those relationships are declared facts, already stored, already correct, already permissioned.
The real gap was the unstructured tail: contracts, minutes, uploads where the relationships are written in prose and nobody ever typed them into a form. For those we run an extraction pass and fold what it finds back into the same structured store, linked to the document it came from. Nodes and edges, in the database we already run and already back up.
That provenance link is not bookkeeping. It is how clearance survives the trip. An extracted fact inherits the clearance of the document it came from, so a party name pulled out of a board-level contract stays at board level. An extracted fact is never more public than its source. Strip the provenance and you have quietly built a declassification machine.
Judgment should be a number with a threshold, not a vibe
A surprising share of what an assistant does is not retrieval at all. It is judgment. Did they mean this week or the last seven days? Is that a question or an instruction? Of the actions the system can take, which one did those words actually ask for?
The normal approach is to ask the model in prose and parse whatever comes back. It works until it doesn't, and when it doesn't you have no idea how close the call was. A wrong guess and a lucky guess look identical in the logs.
So we route those judgments through a separate, smaller model we call Jev, whose job is to return a typed number rather than a sentence. Not the model said create a task, but a probability spread across the possible readings with a threshold underneath it. Above the bar, act. Below the bar, ask a clarifying question instead of guessing. The bar is set higher for anything that writes than for anything that only reads, because the cost of being wrong is not symmetrical.
Two rules keep that honest. Jev chooses among values the person actually typed rather than composing new ones, so a date or a name that was never said is not available for it to pick. And Jev is allowed to make the system more cautious about a request, never less. A second opinion can add caution. It should not be able to remove it.
An AI that can act has to prove that it acted
Memory is half a brain. The other half is doing something with it, and that is where most of the risk moves once recall is solid. Our rule is short: the AI proposes, ordinary software executes, and anything high-impact waits for a person to confirm it. The model does not reach into your records.
What that looks like from the outside is undramatic. You ask for a board meeting. The system shows you the meeting it is about to create. You confirm. A normal, auditable piece of code creates it under your own permissions. The model wrote the proposal. It did not write the row.
- The request is turned into a typed proposal, a named action with checked fields, not free text.
- Permission is checked against the asking person's role before anything runs.
- High-impact changes, such as scheduling a meeting or sending a board packet, come back to a person for confirmation first.
- The action runs as ordinary code, under the person's own access, not the model's.
- The result has to carry proof, such as the identifier of the record that now exists.
- The work is written to the timeline so it can be recalled, and questioned, later.
Step five is the one we would put on a poster. It is genuinely easy to build an assistant that replies Done and did nothing at all, and that failure is invisible precisely because it is cheerful. We made done a claim the system has to substantiate: an executor that returns without evidence is treated as a failure, not reported to the customer as a success.
The same instinct governs drafting. When the AI writes a plan or a board memo out of company memory, the claims carry citations back to the sources they came from, and if the memory turns up nothing, there is no draft. An empty corpus produces an honest answer about not having enough to go on, rather than a confident invented document, which on a governance topic is the worst thing the system could hand you.
The moment an AI can act on your company, cheerful is the most expensive setting it has. I would rather it tell you it is not sure, or ask you one more question, than hand a founder a confident document nobody can trace.
Why we are publishing the thesis and not the blueprint
A fair objection to a post like this one: why explain the security architecture of your own product in public?
Because the thesis and the blueprint are not the same thing. The thesis, which is filter at retrieval, default-deny, route the question, own the permission layer, is an argument. Arguments get better when people push on them, and we would rather be told we are wrong now than discover it later on someone's live data.
The implementation is a different matter. Exact thresholds, storage layouts, clearance tokens, and the internals of the leak tests are a map of the building, and maps are most useful to the person walking the perimeter. Those stay in. Be suspicious of a vendor who publishes those details, and equally suspicious of one who has only the idea to show you.
On verification, here is what we will say. The permission layer is tested against an independent model of who should be able to see what, so the tests do not simply agree with the code by construction. That suite runs as a build gate rather than as a report somebody reads on a Friday. Our security controls are designed for SOC 2 readiness, and we keep a written register of the claims we allow ourselves to make in public, which is why this paragraph is more careful than a marketing page would be. You can read the current posture on our security page.
What to ask the next vendor who says their AI remembers everything
If you are evaluating AI for a company with a board, confidential files, or more than one entity, the demo will look good. It always does. These are the questions that separate a real memory layer from a search box with a friendly voice.
- Show me two answers. Ask the same question as a board member and as a new hire. If the answers match, there is no permission layer.
- Where does the check happen? Before the model reads the text, or after it writes the reply? Only one of those is a control.
- What happens to a document nobody classified? If the answer is that it's treated as general, the default is backwards.
- How do you answer how many and list every? Those are counting and enumeration questions. A pure vector system will approximate them and sound certain doing it.
- When it creates something, what proves it was created? Ask what happens when the underlying action quietly fails.
- If the memory has nothing, what do I get? The honest answer is nothing, with an explanation.
- Whose infrastructure holds our memory, and can you delete it? Ask specifically what happens to the stored copy when you delete the original.
None of these are gotchas. They are the questions we had to answer for ourselves, in roughly this order, and each one changed the architecture when we answered it honestly. You can see where they landed in EntityMax, which is the part of the product a person actually talks to.
An AI that remembers everything your company knows is a liability until it can forget on purpose, per person, at the moment of recall. Memory is the easy half. Permission is the product.
