Een tijdje terug opende ik een brief van mijn huisarts. De informatie erin raakte aan zeker vier werelden in mijn lenzen- en informatiesysteem: de brief zelf als correspondentie, mijn financiën en verzekering, mijn adres- en contactgegevens, en mijn gezondheidsdagboek. Dat digitale informatie vaak bij meerdere dingen hoort, wist ik allang. Dat hetzelfde gewoon ook voor papier geldt, drong pas nu tot me door. De vraag is alleen hoe je dat slim verwerkt en organiseert zonder dat je er telkens extra werk van hebt.

Die vier werelden bekijk ik door wat ik lenzen noem, en samen met een fors groeiend aantal andere lenzen vormen ze mijn Life Lens System: een informatiearchitectuur waarin verschillende lenzen naar dezelfde werkelijkheid kijken. De grondlaag eronder noem ik ThetaOS, met personen, datums, locaties en nog heel wat meer. Daarop bouw ik lens na lens. Die lenzen helpen me los, of soms ook samen, vanuit een ander perspectief te kijken naar alle informatie in mijn leven, om inzicht te krijgen, betere beslissingen te kunnen nemen, of gewoon veel werk uit handen te nemen, zoals nu bij mijn binnenkomende papieren post.

Zo'n lens, of het nu ThetaOS zelf is of een van de lenzen die ik eraan toevoeg, ben ik voortdurend aan het verbeteren en fijnslijpen, en doordat ik door al die lenzen steeds nauwkeuriger en beter kan kijken, ontdek ik voortdurend nieuwe mogelijkheden. Het is een manier van kijken, uitgevoerd door een software-agent die binnen zijn eigen domein leest of meet, een conclusie voorstelt, en die conclusie nooit zelf vastlegt. Het laatste woord blijft aan mij. Na jaren spelen en experimenteren met apps als Evernote, Workflowy en meer kwam ik tot het inzicht dat ik alle informatie veel slimmer aan elkaar moet knopen om er minder werk van te hebben. Dat gaat dus veel verder dan een notitie maken en die later handmatig aan andere notities linken, zoals in de meeste PKM-aanpakken (Persoonlijk Kennis Management) gebeurt. Bij mij ligt het schema vooraf vast, kan ik het aanpassen zodra ik meer weet, en verbindt en duidt het systeem zelf, volautomatisch.

Ik open een brief vaak uit pure nieuwsgierigheid, onderweg, nadat ik hem 's ochtends in mijn tas heb gegooid. Zelden is dat het moment waarop ik er ook iets mee doe, en dan moet ik er later weer bij nadenken wat ik er ook alweer mee moest. David Allen noemde dit ooit een open loop, in wat hij Getting Things Done ging noemen. De psychologie erachter is een stuk ouder: onafgemaakte taken blijven volgens het Zeigarnik-effect uit 1927 beter hangen dan afgemaakte, en recenter onderzoek laat zien dat een concreet plan opschrijven de mentale ruis daarvan al wegneemt. Sommige mensen kunnen daar prima mee leven. Maar ik leef graag zonder die ruis.

Wat het nog lastiger maakt: een envelop komt binnen zonder dat je weet wat erin zit, een rekening, een officieel bericht, of gewoon reclame. Die onzekerheid is precies waarom een stapel post zwaarder aanvoelt dan de inhoud rechtvaardigt, en waarom een lens hier pas iets kan doen zodra hij weet wát er eigenlijk binnenkomt. De hoogste tijd dus om daar iets slims op te verzinnen, niet door een agent te bouwen die zoveel mogelijk zelf mag beslissen, maar door hem steeds preciezer te vertellen waarop hij dat wel en niet mag doen.

De oplossing die ik voor PostOS heb gebouwd, is een mix van lokale, privacy-first beeldherkenningssoftware die post herkent, en logica die bepaalt welke informatie in een poststuk waar en hoe moet worden opgeslagen en geduid. Het resultaat bekijk ik via een lokale pagina in mijn browser, met een vriendelijke interface die me gewoon vertelt wat ik ergens mee moet, een wereld van verschil met handmatig taken uit post overtypen in een taken-app.

Zonder agentic AI was me dit nooit gelukt, maar het enige wat ik daarmee doe, is de software schrijven die het zware werk daarna zelf doet. AI is daarin gereedschap, en niet het fundament. Voor de diepte, breedte en nauwkeurigheid van mijn data is een taalmodel vaak gewoon niet het juiste gereedschap. Ik zet agentic AI in waar het wél robuust werkt, zoals bij het schrijven van die code, en houd het ver weg waar het onbetrouwbaar of ongeschikt is, wat verderop in dit stuk heel concreet blijkt. De kern van mijn LLS is dus IA, informatie-architectuur: snel en betrouwbaar.

Voordat ik ging bouwen, maakte ik een lijstje: welke soorten post zijn er eigenlijk, en wat vraagt elke soort van me? Drie categorieën bleken genoeg. Post is correspondentie, een partij die zich tot mij richt met een mededeling, een eis of een besluit. Een bewijsstuk is iets anders, het bewijs van een transactie of toestand zoals een factuur of een bon, en gaat door naar AdministratieOS, mijn administratie-lens. En soms is iets helemaal geen post, maar een verdwaalde screenshot die toevallig is meegescand. Mijn systeem herkent dat inmiddels automatisch, het is classificeren, en geen conclusie trekken. Pas als vaststaat wát iets is, kan hij gaan sorteren, filteren en de juiste actie voorstellen.

De code die zo'n lens bedient, functioneert als een software-agent, en die geef ik een korte, herkenbare naam. Bij PostOS lag Pieter Post voor de hand, en de rest volgde vanzelf: Pat, naar Postman Pat, de sympathieke Engelse kinderserie-figuur. Elke lens in mijn systeem krijgt zo'n naam, zoals mijn research-agent Vera, naar Veritas, waarheid.

Die brief van mijn huisarts waarmee dit stuk opent, is een goed voorbeeld van hoe dat er in de praktijk uitziet, uiteraard deel ik mijn medische info hier niet. Hij kan tegelijk correspondentie zijn, financiële informatie bevatten, en iets zeggen over mijn gezondheid, zonder dat ik ooit hoef te kiezen welke van de drie het is.

Voor Pat is de brief in de eerste plaats correspondentie, een afzender, een datum, misschien een actie die eraan hangt. Diezelfde brief bevat ook een arts die niet opnieuw hoeft te worden uitgezocht, want die staat al als entiteit in ThetaOS, de grondlaag die alle lenzen delen. Zit er een rekening bij, dan gaat dat deel naar AdministratieOS. Staat er de uitslag van een bloedonderzoek of een andere waarde in die iets zegt over mijn lichaam, dan sla ik dat op in HealthOS.

Bij administratie liep ik altijd tegen dezelfde puzzel aan: er bestaat een boekhoudkundige, fiscale werkelijkheid, en er bestaat een veel rijkere werkelijkheid die verbonden is met allerlei andere elementen in mijn leven. De kunst is die twee naast elkaar te laten bestaan, in plaats van de ene aan de andere op te offeren. Bij Simon, de software-agent van AdministratieOS, zie ik dat concreet terug. Hij houdt de betaling en verzekeringsdeclaratie in de gaten, inclusief de status ervan, zonder dat de rijkere laag, dat het om een doktersbezoek gaat, verdwijnt zodra het fiscale feit, een uitgave, is vastgelegd. Staat er in de brief dat ik moet bellen om een declaratie te regelen, dan blijft die open totdat er een week later, via de bankkoppeling, een afschrijving opduikt waarvan het bedrag, de datum na de brief, en de partij en het factuurnummer allemaal kloppen. Pas dan markeert Simon de declaratie als voldaan, en pas na het zien van die match bevestig ik dat ook zelf.

Eén stuk papier levert zo informatie op waar ik op meerdere plekken iets mee kan of moet, zonder dat ik ergens hoef te kiezen of te kopiëren. Hoe HealthOS precies een waarde uit zo'n brief leest, en hoe ThetaOS als grondlaag in elkaar zit, laat ik hier nog buiten beschouwing.

Bij de doktersbrief werkt dat combineren anders dan bij ContactOS. Daar wordt een optreden uit mijn agenda pas na verloop van tijd naast een bloeddrukdal uit HealthOS gelegd, en pas dan ontstaat een correlatie die in geen van beide lenzen apart bestond. Bij de doktersbrief hoeft dat niet: zodra hij binnenkomt, vindt elk onderdeel meteen zijn eigen lens, zonder dat het origineel wordt aangetast. Soms moeten mijn agents informatie splitsen: uit één ding de onderdelen halen die elk hun eigen lens vinden. Maar vaak moeten ze ook combineren: losse dingen náást elkaar leggen en het verband pas later laten ontstaan en inzichtelijk maken.

Zodra een scan binnenkomt, herkent Pat eerst wat voor soort stuk het is: correspondentie, een bewijsstuk, of iets dat helemaal geen post is. Vervolgens legt hij het naast wat hij al weet via ThetaOS. Ken ik deze afzender al, hoort dit bij een lopende zaak, is er een datum of een bedrag dat om actie vraagt? Dat weten komt niet uit het niets: per afzender en per soort poststuk bouwt Pat een patroonprofiel op, waar de datum staat, waar het kenmerk staat, wat een normaal bedrag is. Herkent hij dat patroon exact, dan hoef ik alleen nog te checken of het klopt, en zet ik zelf mijn vinkje. Wijkt een brief af, of is Pat ergens onzeker over, dan krijg ik een alert en moet ik het stuk zelf bekijken.

Een vroege versie van Pat liet zien wat er kan misgaan. Op een dag verscheen er een ingescande brief van het Kadaster op mijn scherm, met daaraan vastgeplakt zeventien kassabonnen die er niets mee te maken hadden, gewoon omdat ze toevallig na elkaar waren gescand. De eerste versie van de pagina-groepering redeneerde simpel: geen aanhef betekent vervolgpagina, dus plak hem aan de vorige brief. Dat werkt voor een echte vervolgpagina, maar een kassabon heeft ook geen aanhef zonder ergens een vervolg van te zijn, en zo kon een ambtelijke brief opeens boodschappenbonnetjes adopteren. Een lens houdt dus niet alleen bij wát iets is, maar ook waar het ene stuk ophoudt en het volgende begint.

Andere keren werkt precies datzelfde onderscheid in mijn voordeel, ver voorbij het moment van scannen. Een eerste herinnering van een energieleverancier legde ik ooit weg als niets-mee-doen, gewoon een betaling die al onderweg was. Weken later kwam er een aanmaning binnen, met hetzelfde dossierkenmerk ergens onderaan de pagina, en Pat legde de twee meteen naast elkaar. Niet omdat hij de eerste brief opnieuw las, maar omdat het kenmerk dat destijds al was vastgelegd nu gewoon weer opdook. Wat ik als afgehandeld had weggelegd, bleek het begin van een keten. Ik hoefde het zelf niet te onthouden, het kenmerk deed dat netjes voor me.

PostOS is de tweede lens waarover ik in deze serie schrijf. Eerder ging ik al in op ContactOS. Maar inmiddels heb ik er bijna twintig, en het onderliggende idee is groter dan de twee die ik tot nu toe heb beschreven. PostOS bewaart namelijk geen wereld naast mijn andere systemen. Het kijkt naar dezelfde wereld door een andere lens. De meeste mensen lossen dit soort dingen helemaal niet gestructureerd op, hooguit met een taken-app of een Excel-sheetje waar je zelf alles in moet typen.

Een enkele lens, hoe goed ontworpen ook, blijft een enkele blik op een enkel domein. Pas als er genoeg lenzen zijn, en ze zijn zo ontworpen dat ze op hetzelfde fundament landen, kunnen ze samen iets zien dat je met één lens nooit had kunnen waarnemen, of het nu gaat om één brief die vier werelden raakt, of om veel optredens in een week die diezelfde periode een bloeddrukdal laten zien. Willekeurig lenzen over elkaar stapelen vertekent juist het beeld. Het werkt alleen omdat elke lens vanaf het ontwerp is afgestemd op datzelfde fundament, en dat werk doet mijn informatie-architectuur dus helemaal zelf, ik hoef er niet meer over na te denken als de lenzen eenmaal werken.

Verderop in deze serie volgen onder meer FinanceOS, HealthOS en een verdieping van ThetaOS zelf, dat ik tot nu toe alleen kort als grondlaag heb geïntroduceerd, elk met hun eigen aflevering.

Bij een vroege versie van PostOS ging het mis, op punten als het lezen van de brief zelf. Het kenmerk stond rechts in de kantlijn, de datum eronder, en de OCR-tekst die daaruit rolde had de twee gewoon door elkaar gegooid.

Het probleem zit in wat de meeste OCR-tools doen met de positie van elk woord op de pagina. Ze weten die positie wel, per woordblok, maar veel toepassingen negeren die informatie gewoon en plakken de herkende tekst achter elkaar, van boven naar beneden, tot één lopende tekst. Daardoor gaat de structuur alsnog verloren.

De oplossing is dat de eerste laag helemaal geen taalmodel is dat losjes naar een scan kijkt. Pat leest een brief aan de hand van positie: elk woordblok krijgt een plek op de pagina. Dat is de crux, want een brief is opgemaakt in kolommen en velden, en gewone OCR gooit die opmaak weg zodra hij de tekst leest. Door juist op positie te matchen, bijvoorbeeld het label "Kenmerk:" met de waarde die er direct naast staat, blijft de structuur van de brief intact. Elke gevonden waarde wordt bovendien nog gecontroleerd: lijkt dit wel op een geldig kenmerk of een geldige datum? Zo voorkomt Pat dat een toevallig woord in de buurt de koppeling verpest.

Voor Pat aan de duiding begint, bepaalt hij eerst de documentgrenzen. Dat gebeurt op de kale scanvolgorde, nog vóór er iets over de inhoud wordt beweerd: eerst het goedkope werk, waar houdt het ene poststuk op en begint het volgende? Pas daarna komt de duurdere vraag: wie is de afzender, en wat behelst de brief? Een afzender wordt vastgeklikt op een expliciet controleerbaar kenmerk. Bij voorkeur is dat een KvK-nummer, te verifiëren bij de Kamer van Koophandel, en anders een domeinnaam die letterlijk in het document staat, iets minder hard omdat die makkelijker door een ander bedrijf of een tussenpartij kan worden gebruikt. Beide zijn sterker dan geraden op een logo of een bekende naam. Het stramien waar ik het eerder over had, wordt zo per afzender scherper na elke herhaling.

De OCR zelf draait volledig lokaal. Elke scan wordt eerst opgeschaald zodat kleine lettertjes en cijfers scherper worden, waarna Apple's eigen Vision-engine het lezen doet, met een voorkeur voor Nederlands, Duits en Engels. Is een PDF al digitaal in plaats van gescand, dan slaat het systeem OCR gewoon over. Ik heb ook een vision-agent, Argus, die op een lokaal taalmodel draait, Qwen3-VL-32B via Ollama, en die elders scans leest, maar voor de post heb ik hem bewust uitgezet: hij las een 06-08 waar 06-24 stond. Bij een deadline kan één verkeerd cijfer geld kosten. Daarom blijft de kernextractie deterministisch: vaste regels bepalen aan de hand van de positie van elk woord wat erbij hoort, zonder dat een model hoeft te gokken. Alleen bij een echt onduidelijke scan, of een handgeschreven datum, ligt dat anders. Dan kijk ik zelf naar de originele scan en controleer ik met eigen ogen of het systeem de tekst goed heeft gelezen.

Herkennen en lezen is één ding. Weten of een brief nog om actie vraagt is iets anders, en daarvoor bestaat een laatste laag: de koppeling met mijn eigen bankregister, om af te leiden of het openstaande bedrag erachter al is voldaan. Ook hier geldt liever een eerlijk "weet ik niet zeker" dan een gladde ja. Er wordt gematcht op het hele dossier, niet op de losse brief, want een factuur, de herinnering die erop volgt, een eventuele aanmaning, een incassobureau dat wordt ingeschakeld, en in het uiterste geval een dwangbevel, horen in werkelijkheid allemaal bij hetzelfde, oplopende bedrag. Mijn software onthoudt die hele keten en brengt hem in verband, zodat ik dat zelf niet meer hoef vast te houden.

Niet elke match weegt daarbij even zwaar. Vind ik het betaalkenmerk letterlijk terug in een afschrijving, dan geef ik dat een hoge bewijskracht, want zo'n kenmerk is meestal uniek per zaak. Een OCR-fout kan het natuurlijk verkeerd lezen, of een latere terugboeking kan dezelfde transactie nog een keer laten opduiken, waardoor het net lijkt of er twee keer is betaald. Komt alleen het IBAN van de crediteur terug, met een kloppend bedrag en een datum na de briefdatum, dan noem ik dat redelijk. Blijft er alleen een partijnaam over met een bedrag dat er ongeveer op lijkt, dan is dat zwak, want juist bij een abonnement matcht dat al snel elke maand opnieuw. En betaald is geen aan-of-uit-knop: een betalingsregeling die in termijnen wordt afgetikt krijgt een eigen label, deels betaald, in plaats van stilzwijgend als open of klaar te worden weggezet.

Het meest bruikbare dat uit deze laag rolt, is niet het lijstje van wat al betaald is. Dat is geruststellend maar niet urgent. De echte waarde zit in de omgekeerde vraag: wat staat nog open én is al geëscaleerd, zonder gevonden betaling erachter. Mocht daar ooit een dwangbevel of exploot tussen zitten, dan is dat precies waar ik als eerste naar zou kijken. Ook hier blijft de discipline hetzelfde: het systeem stelt een match voor met de bewijskracht erbij, en pas na mijn goedkeuring is de zaak echt gesloten. Een gat in de bankdata is namelijk geen bewijs dat iets onbetaald is, het kan net zo goed zijn dat de laatste mutaties nog niet zijn binnengehaald.

Dat onderscheid, tussen wat het systeem niet weet en wat er werkelijk niet is, loopt door elke lens die ik bouw. Dat iets niet in de data staat, wil niet zeggen dat het niet is gebeurd.

Wat ik bij het bouwen van al mijn lenzen keer op keer ontdek, staat haaks op hoe de meeste mensen met AI omgaan. Ik gebruik AI consequent om code te fijnslijpen, code die vervolgens robuuste IA oplevert, informatiearchitectuur, met AI precies zo afgebakend als eerder in dit stuk beschreven: ingezet waar het werkt, weggehouden waar het dat niet doet. Ik leun daarbij niet op AI zelf, maar op code die ik heb getest en gecontroleerd, en die daardoor keer op keer hetzelfde blijft doen.

Pat, de software-agent van PostOS, krijgt door die precisie steeds minder ruimte, niet omdat hij zelf slimmer wordt, maar omdat steeds preciezer vastligt wat hij wel en niet moet doen, en vooral hoe.

Dat leren gaat stap voor stap en steeds beter.Een kassabon dwong me een classificatieregel aan te scherpen. Een KvK-nummer verankert een afzender en een betaalkenmerk weegt zwaarder dan een partijnaam. Het lokale AI-model Qwen werd juist de deur gewezen zodra precisie telde. En bij twijfel? Dan beslis ik zelf, en weet de agent daarna de nieuwe spelregel.

Ik bouw dus geen software-agent die steeds meer mag beslissen. Ik bouw een architectuur die steeds beter weet waar hij moet stoppen. Dat is, uiteindelijk, de kern van mijn hele Life Lens System. Dit najaar verschijnt mijn nieuwe boek erover bij uitgeverij Van Duuren.