Polar Brain.

What it is

Polar Brain is your company's memory, kept outside the chat. What gets decided is filed the moment it is decided, it is searched by meaning instead of by exact words, and the next session pulls it back before it answers. It connects to the Claude your team already uses, so nobody changes tool.

Polargate builds it inside your business. It is a product implemented inside your company, not one you sign up for.

The problem it solves

Everyone works with Claude or ChatGPT now, and everyone runs out of context. Two hours into a conversation the window fills up. You open a new chat, explain it all again, and the model proposes the approach the team ruled out last week. Compacting does not fix it: it compresses the conversation instead of persisting it. A notes file does not fix it either, because nobody searches it by meaning and it never enters the session on its own.

Meanwhile the things the company actually knows, the price agreed, the architecture discarded, the mistake already made, live in the heads of three people.

The proof is our own brain

Polargate runs this on itself, every day, in production. Measured in September 2026:

• 2,864 knowledge chunks across 2,158 sources, 5.83 million characters.
• 599 new sources in the last 30 days.
• 8,463 MCP calls, every one of them audited.
• 507 sources stopped by the confidentiality wall before they reached the classifier.
• 284 lessons promoted to the shared library, 568 evaluated and discarded.

Those figures are the size of a corpus running in production, and nothing more. They are here because a memory system is only credible if someone is living inside it.

The confidentiality wall

This is the part that decides whether a company can use it at all. What belongs to one client does not leave that client. What is personal does not cross into client work.

Four independent layers

The rule is enforced four times over: a canonical SQL predicate, a TypeScript check with its own test in continuous integration, a table trigger that refuses the write at the point of writing, and a revalidation of each request. A failure in one layer does not open the door, and because part of it lives in the database, the protection survives a bad deploy.

What it does not do

There is no per-client encryption key and no physical isolation per tenant. Claiming otherwise would be easy and false.

What goes into it

Three ways in: by hand from the chat or the panel while you work, automatically from real mail, and on demand by uploading documents.

It reads PDF, with OCR when the PDF is a photograph of a page, Word, web pages, mail from Gmail and Microsoft 365, and meeting transcripts. Everything is deduplicated by hash, with a ceiling of 20 MB per file. Measured in our own corpus: 172 documents, 40 emails, 18 meetings.

This runs on discipline. If nothing is filed, there is no brain. The habit is small, read before you form an opinion and file when you finish, and it is the whole difference.

How it is searched

By meaning, over embeddings of 3,072 dimensions in Postgres. There is a minimum relevance floor, and that floor is exactly what lets the answer be "I do not know" instead of an answer assembled from noise.

The model has two levels: the entity, which is the account, and the project, which is a piece of work inside it. Knowledge filed without a project is shared canon of the entity and every project inherits it. A search inside a project returns that project's sources plus that shared canon. Projects do not link to each other by default: separate by default, connected on demand.

Today this is vector search. It is not hybrid and there is no reranking. We would rather write that down than let you assume it.

The shared library

A generic lesson learned in one project is anonymised automatically and served inside anyone else's search, without the client data travelling with it. The redaction strips names of people, companies, clients and projects, along with figures, credentials, URLs and email addresses. When the classifier is not confident, it does not promote: losing a lesson is cheaper than leaking one.

Measured: 284 lessons promoted, 568 evaluated and rejected, 31 dropped as duplicates, 1 rejected because it carried personal data.

Why it exists at all: a deployment error that cost hours in one project was already written down in another project's brain, locked inside its silo. The shared library is what stops the same mistake being paid for twice.

Connecting it to the Claude you already use

The brain is exposed over MCP, with our own OAuth. There are no keys to paste by hand: the client registers dynamically, so connecting an account is a URL and a login. Once connected there are 125 tools, and every call is written to the audit log.

Access is locked by role. An outside guest can invoke a subset, five tools today, and the tool list itself is filtered, so the rest is not even visible. A guest's searches do not get the shared library folded in, because that library is distilled from work with everyone else. Revoking access takes effect mid-session: membership deleted, pending invitations void, unredeemed codes gone, tokens revoked.

The visual console

Retrieval is invisible by nature, which makes it hard to trust. The console turns it into something you can look at: a graph of entities and projects, a search box per entity, knowledge by category, and document upload with a status per file. It is protected by role, and it is what we show in a demo.

For a company or for one person

For a company: several entities and projects, roles, an audit trail of every call, a ceiling of 200 AI calls per user per day, and rate limits per entity. It fits consultancies with several clients, professional firms, and any team where the knowledge lives in two people's heads.

For one person: the same product without the multi tenant part. One brain, with the same wall between what is personal and what is professional. It is not an afterthought. The heaviest real use of this system today is exactly that.

The limits

Time

The hard one is the time axis. In our own retrieval lab, the question about which price is valid now failed in all four configurations we tested, and every one of them returned the old price. The problem is knowing what is true today, and retrieval does not solve that. So state that has to be exact, tickets, dates, orders, hours consumed, is read deterministically from the database and never inferred from vectors. Vectors are for fuzzy knowledge.

What is not deployed

Hybrid search, reranking and a temporal knowledge graph are studied and parked, not running. We do not claim a security certification either. What we can show is the architecture, the tests in continuous integration and the audit log.