Polar Brain
Een geheugen voor je bedrijf dat het chatvenster overleeft. Wat besloten wordt, wordt meteen vastgelegd, op betekenis doorzocht en door de volgende sessie opgehaald voordat die antwoordt. Gebouwd binnen je eigen bedrijf en gekoppeld aan de Claude die je team al gebruikt.

Wat het is
Polar Brain is het geheugen van je bedrijf, bewaard buiten de chat. Wat besloten wordt, wordt vastgelegd op het moment van beslissen, het wordt op betekenis doorzocht in plaats van op exacte woorden, en de volgende sessie haalt het op voordat die antwoordt. Het koppelt aan de Claude die je team al gebruikt, dus niemand hoeft van tool te wisselen.
Dezelfde week, met en zonder geheugen
Polargate bouwt het binnen je eigen bedrijf. Het wordt bij jou geïmplementeerd, het is geen aanmeldformulier.
Het probleem dat het oplost
Iedereen werkt inmiddels met Claude of ChatGPT, en bij iedereen raakt de context op. Na twee uur gesprek loopt het venster vol. Je opent een nieuwe chat, legt alles opnieuw uit, en het model stelt precies de aanpak voor die het team vorige week heeft afgeschoten. Comprimeren lost het niet op: het perst het gesprek samen in plaats van het te bewaren. Een notitiebestand lost het evenmin op, want niemand doorzoekt het op betekenis en het komt nooit uit zichzelf de sessie binnen.
Ondertussen zit wat het bedrijf echt weet, de afgesproken prijs, de verworpen architectuur, de fout die al gemaakt is, in het hoofd van drie mensen.
Het bewijs is ons eigen brein
Polargate draait dit op zichzelf, elke dag, in productie. Gemeten in september 2026:
De zes lagen tussen de kennis van een klant en de gedeelde bibliotheek
- 2.864 kennisfragmenten verdeeld over 2.158 bronnen, 5,83 miljoen tekens.
- 599 nieuwe bronnen in de laatste 30 dagen.
- 8.463 MCP-aanroepen, stuk voor stuk geauditeerd.
- 507 bronnen tegengehouden door de vertrouwelijkheidsmuur, nog voor de classificatie.
- 284 lessen doorgezet naar de gedeelde bibliotheek, 568 beoordeeld en afgewezen.
Dat zijn de afmetingen van een corpus in productie, meer niet. Ze staan hier omdat een geheugensysteem pas geloofwaardig is als iemand er zelf in leeft.
De vertrouwelijkheidsmuur
Dit is het deel dat bepaalt of een bedrijf hier überhaupt mee kan werken. Wat van één klant is, verlaat die klant niet. Wat persoonlijk is, komt niet in klantwerk terecht.
Vier onafhankelijke lagen
De regel wordt vier keer afgedwongen: een canoniek SQL-predicaat, een controle in TypeScript met een eigen test in continuous integration, een tabeltrigger die de schrijfactie weigert op het moment van schrijven, en een hervalidatie van elk verzoek. Faalt één laag, dan gaat de deur niet open, en omdat een deel in de database zit, overleeft de bescherming een mislukte deploy.
Wat het niet doet
Er is geen encryptiesleutel per klant en geen fysieke isolatie per tenant. Het tegendeel beweren zou makkelijk zijn en onwaar.
Wat er in gaat
Drie ingangen: met de hand vanuit de chat of het paneel terwijl je werkt, automatisch vanuit echte mail, en op aanvraag door documenten te uploaden.
Het leest PDF, met OCR als de PDF een foto van een pagina is, Word, webpagina's, mail uit Gmail en Microsoft 365, en vergadertranscripties. Alles wordt ontdubbeld op hash, met een plafond van 20 MB per bestand. Gemeten in ons eigen corpus: 172 documenten, 40 e-mails, 18 vergaderingen.
Het deel dat niemand verkoopt en iedereen moet horen: dit draait op discipline. Wordt er niets vastgelegd, dan is er geen brein. De gewoonte is klein, lees voordat je een mening vormt en leg vast als je klaar bent, en daar zit het hele verschil.
Hoe er gezocht wordt
Op betekenis, via embeddings van 3.072 dimensies in Postgres. Er is een minimumdrempel voor relevantie, en precies die drempel maakt het antwoord "dat weet ik niet" mogelijk in plaats van een antwoord dat uit ruis is opgebouwd.
Het model heeft twee niveaus: de entiteit, dat is de account, en het project, dat is de opdracht daarbinnen. Kennis die zonder project wordt vastgelegd, is gedeelde canon van de entiteit en elk project erft die. Zoeken binnen een project levert de bronnen van dat project op plus die gedeelde canon. Projecten zijn standaard niet aan elkaar gekoppeld: gescheiden tenzij je ze bewust verbindt.
Vandaag is dit vectorzoeken. Het is niet hybride en er is geen reranking. Dat schrijven we liever op dan dat je het aanneemt.
De gedeelde bibliotheek
Een generieke les uit het ene project wordt vanzelf geanonimiseerd en meegeserveerd in de zoekopdracht van elk ander project, zonder dat klantgegevens meereizen. De herschrijving haalt namen van personen, bedrijven, klanten en projecten eruit, plus cijfers, credentials, URL's en e-mailadressen. Twijfelt de classificatie, dan gaat de les niet door: een les kwijtraken is goedkoper dan er een lekken.
Gemeten: 284 lessen doorgezet, 568 beoordeeld en afgewezen, 31 afgevallen als duplicaat, 1 afgewezen wegens persoonsgegevens.
Waarom het bestaat: een deploy-fout die in het ene project uren kostte, stond al opgeschreven in het brein van een ander project, opgesloten in die silo. De gedeelde bibliotheek zorgt dat dezelfde fout niet twee keer wordt betaald.
Koppelen aan de Claude die je al gebruikt
Het brein wordt ontsloten via MCP, met eigen OAuth. Er zijn geen sleutels om met de hand te plakken: de client registreert zichzelf dynamisch, dus een account koppelen is een URL en inloggen. Eenmaal verbonden zijn er 125 tools, en elke aanroep komt in het auditlogboek.
Toegang zit op slot per rol. Een externe gast kan een deelverzameling aanroepen, vandaag vijf tools, en de lijst zelf wordt gefilterd, dus de rest is niet eens zichtbaar. Bij een gast wordt de gedeelde bibliotheek niet in de zoekopdracht meegenomen, want die bibliotheek is gedestilleerd uit het werk met alle anderen. Toegang intrekken werkt direct: lidmaatschap verwijderd, openstaande uitnodigingen vervallen, niet-verzilverde codes weg, tokens ingetrokken.
De visuele console
Retrieval is van nature onzichtbaar, en daardoor moeilijk te vertrouwen. De console maakt er iets van waar je naar kunt kijken: een graaf van entiteiten en projecten, een zoekveld per entiteit, kennis per categorie, en documentupload met een status per bestand. Hij is beveiligd per rol en is wat we in een demo laten zien.
Voor een bedrijf, en ook voor één persoon
Voor een bedrijf: meerdere entiteiten en projecten, rollen, een auditspoor van elke aanroep, een plafond van 200 AI-aanroepen per gebruiker per dag, en limieten per entiteit. Het past bij adviesbureaus met meerdere klanten, bij kantoren, en bij elk team waar de kennis in het hoofd van twee mensen zit.
Voor één persoon: hetzelfde product zonder het multi-tenant deel. Eén brein, met dezelfde muur tussen privé en werk. Het is geen bijzaak. Het zwaarste echte gebruik van dit systeem is vandaag precies dat.
De grenzen, eerlijk gezegd
Tijd
De harde grens is de tijdas. In ons eigen retrieval-lab liep de vraag welke prijs nu geldt in alle vier de geteste configuraties mis, en alle vier gaven de oude prijs terug. Dat is geen zoekprobleem, dat is een probleem van wat nu waar is. Daarom wordt de status die exact moet kloppen, tickets, datums, orders, verbruikte uren, deterministisch uit de database gelezen en nooit uit vectoren afgeleid. Vectoren zijn voor vage kennis.
Wat niet draait
Hybride zoeken, reranking en een temporele kennisgraaf zijn onderzocht en geparkeerd, niet in gebruik. We claimen ook geen beveiligingscertificering. Wat we wel kunnen laten zien is de architectuur, de tests in continuous integration en het auditlogboek.
Vragen, beantwoord
Wat is een bedrijfsgeheugen?
Kan informatie van de ene klant in een antwoord over een andere klant belanden?
Werkt het met de Claude die we al gebruiken?
Is dit alleen voor bedrijven, of kan één persoon ook een brein hebben?
Wat is het verschil met documenten uploaden naar een chatbot?
Start de motor
Vertel ons in een paar korte vragen wat je bouwt. Een senior engineer antwoordt binnen twee werkdagen schriftelijk met een eerste inschatting van scope, planning en prijs.