Het tweede brein van het bedrijf: van wiki tot vaardigheden, het draait allemaal om context8 min read

Ik heb veel nagedacht over de hype rond het ‘tweede brein’. Ik besprak dit met anderen in het veld en met mijn collega’s die een tweede brein aan het bouwen zijn of er een versie van hebben.

Voor degenen die er niet bekend mee zijn: de tweede hersenbeweging begon met het ‘Wiki’-idee van Andrej Karpathy: het organiseren van de persoonlijke kennis van de agent in een soort onderling verbonden Wiki-structuur van lokale MD-bestanden. Dit breidde zich later uit tot het organiseren van persoonlijke gegevens in een veel breder formaat, waarbij gebruikers vaak Obsidian gebruikten om notities te ordenen en te visualiseren en gegevens van vergaderingen (Granola/Whisperflow/Zoom-transcripties) toe te voegen aan de Wiki.

rocket-karpathy-kennisbases:start

raket-karpathie-kennisbases: einde

Toen die “Wiki” zich uitbreidde, werd het duidelijk dat het delen van de informatie die erin staat een echte waarde heeft. Zo begonnen de projecten van het ‘bedrijfstweede brein’ tot bloei te komen. De utopische versie van een tweede brein zorgt ervoor dat al het mogelijke wordt getranscribeerd: zoomoproepen, F2F-vergaderingen, zelfs informele interacties, e-mails, slappe berichten, documenten – allemaal in een enorme gegevensdatabase zoals Snowflake. Stel je voor dat iedereen in het bedrijf deze Snowflake-instantie alles kan vragen wat ze willen en dat elke vraag onmiddellijk wordt beantwoord.

Oeps, geen goed idee. Ten eerste is dit super duur. De hoeveelheid gegevens die in zoiets als dit zit is gewoon waanzinnig en het ophalen van gegevens daaruit wordt uiterst moeilijk, traag en kostbaar. Beveiliging en gegevenssegregatie worden een probleem. Hoe voorkom je dat 1:1 persoonlijke gegevens, financiële gegevens, managementbeslissingen, HR-gegevens of zelfs beslissingen om iemand te ontslaan in de transcripties terechtkomen en toegankelijk zijn. Niet iedereen zou moeten weet alles…

En wie heeft dit nodig, wat bespaart het ons en is dit wel een goed idee?

Over het algemeen zou ik zeggen dat een ingeperkte versie hiervan een goed idee is. Een groot deel van de reden dat het middenmanagement bestaat, is om kwesties stroomopwaarts te brengen en beslissingen stroomafwaarts te verduidelijken. Veel hiervan kan nu worden gedaan met een tweede brein.

Tweede brein voor technische teams

Een technisch tweede brein kan veel gemakkelijker te onderhouden zijn. Veel bedrijven gebruiken gewoon een Dropbox/Google drive/OneDrive-map die gedeelde kennis bevat die Claude/Codex kan delen. Automatisering om dit naar een Git-repository te pushen is vrij eenvoudig, of je kunt Github ook echt gebruiken om dit te beheren (ik denk dat het een hele kleine moeite is voor OpenAI/Anthropic om dit scenario te ondersteunen zonder dat je aangepaste vaardigheden hoeft te installeren om dit soort dingen te beheren). De bron van de waarheid wordt nu de Github-repository en de lokale kopieën zijn lokale git-repository’s.

Dit kan kennis en mogelijkheden toevoegen, zoals gedeelde vaardigheden, gedeelde beslissingen, architectonische ontwerpen, visuele ontwerpen (bijvoorbeeld ontwerpsysteembeslissingen) en diverse andere bedrijfsproductbeslissingen.

Kleine teams hebben niet veel meer nodig dan alleen een simpele synchronisatie rond de repository, maar grotere bedrijven met talloze grotere teams zullen zeer snel tegen ernstige beperkingen aanlopen. De ernstigste problemen zijn contextvergiftiging waarbij een bepaalde gebruiker lokale beslissingen kan nemen die in strijd zijn met de gegevens uit het tweede brein, waarbij conflicterende gegevens worden geïntroduceerd of onbedoeld (in sommige gevallen misschien opzettelijk) bedrijfsbeslissingen worden overschreven.

Het in git houden en samenvoegen kan gedaan worden met behulp van een speciale agent die naar conflicten zoekt en een gebruiker kan waarschuwen als hun wijzigingen conflicterend zijn, conflicten oplost en de resultaten samenvoegt.

Houd er rekening mee dat dit geen goede methode is voor het onderhouden van projectdocumentatie. Daarom is het een betere manier om de wiki op te nemen als een integraal onderdeel van het project zelf. Het is vrij eenvoudig te maken. Je zet gewoon een codeeragent opzij en vraagt ​​hem om het project door te nemen, het grondig te documenteren in een map docs, opgesplitst op architectuur, valkuilen, productbeslissingen, technische beslissingen en andere dingen waarvan hij concludeert dat ze nuttig kunnen zijn in kleine beheerbare md-bestanden. De sleutel is om het te vertellen om ervoor te zorgen dat de code en readme.md allemaal naar de documentenmap verwijzen om ervoor te zorgen dat er overal naar wordt verwezen en dat het als onderdeel van het project wordt beschouwd en niet als een externe bron. Het belangrijkste dat de agent moet weten, is dat het hier de bedoeling is om een snelle onboarding van een andere agent voor het project mogelijk te maken, om valkuilen, gaten en technische problemen te vermijden…

Zodra het in de repo-projectstructuur zelf is geïntegreerd, zal de codeeragent het onderhouden alsof het code is. Het zal het lezen alsof het deel uitmaakt van de code en als er iets verandert, zal het de documentatie aanpassen of wijzigen (onthoud dat “documentatie is dat de code gemakkelijk te lezen en duidelijk is” of “documentatie wordt oud zodra deze uw toetsenbord verlaat” – vertrouw erop dat de AI deze onderhoudt, zodat ze niet meer waar zijn).

Tweede brein voor product-, marketing- en niet-technische teams

Dit type tweede brein kan heel cool zijn voor technische teams, maar hetzelfde doen voor niet-technische teams zal uiterst moeilijk zijn.

Neem bijvoorbeeld een team van advocaten; zij beschikken over zeer specifieke kennissets die zich uitstrekken over e-mail, slack, word-bestanden en andere documenten. Hetzelfde geldt voor boekhouders, verkoop, klantensucces, etc. Ze hebben elk hun eigen tweede hersenkennis.

Bovendien wil het management waarschijnlijk dat gegevens opborrelen (ongefilterd via het middenmanagement) en heeft het team mogelijk informatie nodig die het management heeft gegenereerd. Hoe maak je een schaalbare kennisgrafiek die beveiligd en gescheiden is?

Er zijn een paar benaderingen die de zaken gemakkelijker kunnen maken, tenminste totdat de grote jongens dit probleem oplossen, hopelijk op een open manier, maar waarschijnlijker via een dure gesloten oplossing.

1. Persoonlijk tweede brein – elke persoon die dit wil, kan zijn eigen vergaderingen transcriberen en zijn eigen tweede brein onderhouden. Obsidiaan is hiervoor erg handig, elke agent kan het in principe sorteren en opruimen. Gebruik het REM-slaapmechanisme om het te optimaliseren: een agent moet ’s nachts wakker worden, alle informatie identificeren die hij gedurende de dag heeft verzameld, alle informatie vinden die cruciaal en belangrijk is om voor de toekomst te bewaren en deze op een gemakkelijk ophaalbare manier in mappen en MD-bestanden ordenen. Dit betekent dat als u met een bepaalde klant hebt gesproken, die klant een bijgewerkt MD-bestand krijgt met informatie die belangrijk is om te onthouden over hem, waar u samen aan werkt, enz. Hetzelfde geldt voor projecten. Er zal overlap zijn: overlap is goed – het is oké dat de informatie over een bepaald project zowel in het dossier van de persoon met wie je hebt gesproken, als in het bedrijf en in de projectbestanden aanwezig is. Laat de makelaar dit voor u regelen. Als u vragen heeft, kunt u dit uw primaire gegevensbron voor uw agent maken. U kunt uw agent blootstellen aan uw e-mail/gesprekken/enz. – zorg er wel voor dat u geen dingen transcribeert die u niet gedocumenteerd wilt hebben (laten we er geen realityshow of soap van maken).

2. Tweede brein op teamniveau – een tweede gegevenslaag omvat gegevens die zich in het persoonlijke tweede brein bevinden en waarvan de agent 100% zeker weet dat deze relevant zijn voor het hele team, of gegevens die afkomstig zijn uit vergaderingen op teamniveau die van nature teamgebaseerd zijn. Een agent kan ook gegevens voor dit tweede brein verzamelen via de slack-kanalen van uw team. Deze mogen niet in uw 1:1-kanalen of zoom-oproepen staan. Zodra de gegevens zijn opgehaald, kan een agent deze in realtime of elke nacht ordenen en inconsistenties aanwijzen waar beslissingen zijn teruggedraaid of niet overeenkomen met persoonlijke of managementbeslissingen. Deze moeten worden benadrukt en gewaarschuwd voor de persoon die de onverenigbare beslissing neemt, zodat deze op een geïnformeerde manier zijn keuzes kan maken.

3. Het tweede brein op managementniveau – dit is eigenlijk een tweede brein op teamniveau, maar vanwege de gevoeligheid van de gegevens en de beslissingen die worden genomen, moet er op een veel genuanceerder manier mee worden omgegaan. Alleen definitieve beslissingen en openbare gegevens mogen hier worden gedeeld om mogelijke lekken naar de rest van het bedrijf te voorkomen. Het kan voor een mens een goed idee zijn om, althans in het begin, een aantal gegevens door te nemen om de gegevensbeveiliging te garanderen. Het is ook een goed idee om het managementbrein buiten het tweede brein van het bedrijf te laten.

4. Bedrijfsbreed tweede brein – dit is de moeilijkste en mag alleen gegevens bevatten die concreet en informatief zijn en die relevant kunnen zijn voor het hele bedrijf. Alleen financiële resultaten gerapporteerd, bijvoorbeeld informatie over personeel (wie bekleedt welke functie).

Hierdoor blijven veel gegevens achterwege, waaronder bijvoorbeeld sentimentgegevens, die het management van het hele team wil horen. Dit kan afzonderlijk worden verzameld of geoogst uit slack en andere bronnen. Het is geen goed idee om dit soort gegevens rechtstreeks uit het bedrijfsbrein te halen.

Dus, wat zoek je in een tweede brein of een bedrijfsbrein, heb je pogingen ondernomen om er een te bouwen en wat waren je conclusies?