Skip to content
POLARGATE
Build // Your company's memory for working with AI, so no session starts from zero again.

Polar Brain

A memory for your company that survives the chat window. What gets decided is filed on the spot, searched by meaning and pulled back by the next session before it answers. Built inside your business and connected to the Claude your team already uses.

In an archive aisle lined with grey boxes, an archivist turns the wheel of a mobile shelving unit while holding a laptop showing charts

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.

The same week, with and without a memory

The same week, with and without a memoryOn the left, three chat sessions in one week that each start from nothing, so the context is explained three times and what was decided is lost. On the right, the same three writing to and reading from one memory, so Wednesday starts with Monday and Friday starts with both.TodayWith a brainMondayyou explaineverythingMondayyou explain itoncelostWednesdayyou explain itagainWednesdayit already knowslostFridayyou explain itagainFridayit already knowsOne memorysearched bymeaningNothing kept
The difference is not a better model. It is whether what you decided on Monday is still there on Friday.

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:

The six layers between one client's knowledge and the shared library

The six layers between one client's knowledge and the shared libraryA lesson learned on one client's work passes six independent checks before it can be reused anywhere else. What comes out has been rewritten with every identifying detail removed, and any check that is unsure stops it.What we learned on a client's workprivate to that client1Strict classifier: is this eventransferable?2Confidence floor: unsure means no3Sweep for names, figures, keys,URLs4Semantic dedupe against thelibrary5Reversible marking, one per source6Dry run: the plan before the writeThe shared librarythe lesson, rewritten, nothingidentifying left
Six checks, and each one can stop the whole thing on its own. Losing a lesson is cheaper than leaking one.
  • 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.

The part nobody sells and everybody should hear: 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, and 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 honest 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. That is not a retrieval problem, it is a problem of what is true now. 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.

FAQ

Questions, answered

What is a company brain?
A company brain is a memory that lives outside the chat window, so an AI session can start with what the company already knows. What gets decided is filed as a short atomic note, stored with its embedding in Postgres, searched by meaning and pulled back into the next session before the model answers. It is organised in two levels, the entity, which is the account, and the project, which is a piece of work inside it, and knowledge filed without a project is inherited by every project of that entity.
Can one client's information end up in an answer about another client?
That is what the confidentiality wall is for, and it is enforced four times: a canonical SQL predicate, a TypeScript check with its test in continuous integration, a table trigger that refuses the write, and a revalidation of each request. Part of it lives in the database, so the protection survives a bad deploy. In our own corpus, 507 sources were stopped by the wall before reaching the classifier. What the wall does not do is also written down: there is no encryption key per client and no physical isolation per tenant.
Does it work with the Claude we already use?
Yes. The brain is exposed over MCP with our own OAuth, and the client registers dynamically, so connecting an account is a URL and a login rather than keys pasted by hand. 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, the tool list itself is filtered so the rest is invisible, and revoking access takes effect mid-session.
Is this only for companies, or can one person have a brain?
One person can have one. It is the same product without the multi tenant part: a single brain, with the same wall between what is personal and what is professional, so private notes never surface inside work. Individuals and one person teams get the piece that matters most to them, which is that a new chat starts knowing what was decided in the old one.
How is this different from uploading documents to a chatbot?
Three things. The unit is a short atomic note written to be retrieved, not a long document chopped up blindly. The knowledge is organised by entity and project, with a confidentiality wall between them, instead of sitting in one pile. And state that has to be exact, tickets, dates, orders, hours consumed, is read deterministically from the database and never inferred from vectors, because vectors are for fuzzy knowledge and not for facts that must be right.
INITIATE

Start the engine

Tell us what you are building in a few short questions. A senior engineer answers in writing within 48 business hours, with a first take on scope, timeline and price.

Start your project Talk to us