Tijdens een experiment bij Thoughtworks Europe, waarbij tien engineers probeerden een complex IROps-systeem voor luchtvaartmaatschappijen te bouwen via agentic engineering, ontstond er onverwacht emergent gedrag. Door een strikte discipline van frequente commits en rebase-acties in een monorepo, begonnen de AI-agents de repository te gebruiken als een gedeeld geheugen.
De agents gebruikten de opgeslagen plannen in de repo om elkaars voortgang te monitoren en hun werk op elkaar af te stemmen. Dit patroon staat bekend als een blackboard-systeem (of tuple space), waarbij autonome agents onafhankelijk van elkaar informatie lezen en schrijven in een gedeelde ruimte om tot een gemeenschappelijk doel te komen.
Omdat dit proces toevallig ontstond en CI-pipelines overbelastte, is de auteur begonnen aan het project Talwrn. Dit project beoogt een specifiek communicatiekanaal te creëren dat dient als blackboard voor agentic engineering, los van traditioneel bronbeheer.
Een Toevallig Blackboard-systeem
De tien engineers kregen de opdracht om een IROps-systeem voor luchtvaartmaatschappijen te bouwen. Dit is het systeem dat luchtvaartmaatschappijen gebruiken in een vluchtcontrolescentrum wanneer er iets misgaat: wanneer een vliegtuig een technisch defect heeft dat gerepareerd moet worden, of wanneer een bemanningslid ziek wordt en vervangen moet worden. Het is het middel waarmee zij beslissen welke vluchten worden geannuleerd, welke vliegtuigen worden gewisseld, welke passagiers worden uitgeladen en in hotels worden geplaatst, enzovoort. Ze doen dit voor honderden vliegtuigen, honderdduizenden passagiers en zeer veel bemanningsleden over meerdere stations en luchthavens. Het is een zeer moeilijk probleem om op te lossen en uit te voeren. Een IROps-systeem is complex om te bouwen, complex om te begrijpen en complex in gebruik.
We slaagden erin om er binnen vier dagen een te bouwen. Maar dit artikel gaat niet over hoe we dat hebben gedaan.
We begonnen met een specificatie en een gesimuleerde luchtvaartmaatschappij, omdat dit een oefening was en geen echte klant. We probeerden een paar dingen om te zien wat wel en niet zou werken. We gebruikten een monorepo en alle engineers begonnen tegelijkertijd. Na een paar dagen begonnen we dingen op interessante manieren te zien gebeuren; er ontstonden nieuwe patronen.
Emergent gedrag door het afstemmen van onze aanpak
Met veel agents die in één repo werkten, liepen de build-pipelines vast. Om dit op te lossen introduceerden we een discipline: onze agents moesten voortdurend committen en rebasen vanaf de main branch. In eerste instantie vereisten we een rebase na de commit en daarna een push, waarbij alle build-checks en controles actief waren. We introduceerden deze wijziging om build-fouten lokaal op te vangen: vroeg en vaak integreren.
Dit had echter een bijeffect. We instrueerden de agents om te plannen, het werk af te bakenen tot secties in de specificatie en plannen te maken die gekoppeld waren aan die secties. Deze plannen werden in de repo opgeslagen. Alle agents werkten vanuit dezelfde specificatie, gebruikmakend van dezelfde genummerde en geïdentificeerde secties. Terwijl de agents werkten, werden de plannen bijgewerkt om de voortgang vast te leggen. Deze updates werden, samen met alle andere wijzigingen, meegenomen in de nieuwe commit-discipline. Hierdoor konden agents de voortgang van andere agents zien.
Stel dat één agent werkte aan de evaluator, het component dat bepaalt of een specifiek plan om de operaties te herstellen geldig is (of het harde of zachte restricties schendt, etc.). Tegelijkertijd werkte een andere agent aan het zoekalgoritme dat zoekt naar plannen die de verstoring kunnen oplossen. Het zoekcomponent is afhankelijk van de evaluator. Elk component kan afzonderlijk worden geschreven, maar er is een gedeelde interface en de zoekfunctie leunt op de evaluator.
De plannen legden deze integratiepunten vast. Het ene plan vermelde: "op dit punt moet ik de aanroepende functies bijwerken zodat ze de echte verifieerder aanroepen". Aan de zoekzijde stond: "op dit punt moet ik de aanroep naar de echte verifieerder invoegen zodra deze beschikbaar is". Beide agents konden elk plan en de voortgang ervan inzien. We realiseerden ons dat de agents de plannen gebruikten om te coördineren. Wanneer één agent een regel van het plan markeerde als "in behandeling", zag de andere agent dat en werkte niet aan die specifieke regel. Wanneer de eerste agent klaar was, zag de andere agent niet alleen dat het werk voltooid was en hij dus kon doorgaan, maar kreeg hij ook direct aantekeningen over hoe de regel was geïmplementeerd.
We begonnen dit uit te buiten. We startten een sessie en instrueerden deze om aan een specifiek traject te werken. Een voorbeeld was het introduceren van een kostenmodel naast de verifieerder. Wetende dat iemand anders aan het kostenmodel had gewerkt en voortdurend commits pushte, instrueerden we de agent die aan de verifieerder werkte om de plannen en broncode te bekijken, de repo te monitoren en, zodra het werk voor het kostenmodel werd gepusht, te beginnen met de integratie. En dat gebeurde ook.
Dit was volledig ad hoc. Het was het resultaat van een reeks toevallige beslissingen. We zagen het gebeuren en begonnen het vervolgens bewust in te zetten.
De repo als toevallig blackboard-systeem voor agents
Er is een naam voor het patroon dat onze agents hadden ontdekt: een blackboard-systeem. Dit is iets waar ik tijdens mijn studietijd onderzoek naar heb gedaan. Mijn scriptie ging over het sturen van agent-gedrag met hiërarchische sensoren. Ik keek naar het toepassen van destijds moderne machine learning-technieken, zoals reinforcement learning, op grote, dynamische datasets. Bij het bestuderen van de literatuur adopteerde ik het blackboard-patroon als de kernstructuur voor coördinatie. Dit patroon was eerder ontdekt bij de ontwikkeling van het Hearsay-II-systeem in 1980 en werd later door Gelernter et al. in 1986 verder ontwikkeld tot het formalere concept van de tuple space.
Een blackboard of tuple space is een gedeeld geheugen waarin autonome agents onafhankelijk van elkaar kunnen lezen en schrijven. Ze lezen en schrijven tuples met een bepaalde minimale structuur, en daarna zoveel extra velden als gewenst: er is geen vast schema. Het is een zeer effectieve techniek voor het coördineren van autonome probleemoplossers richting één gemeenschappelijk doel. Ze kunnen elk een ontleed deel van het probleem oplossen, hun oplossing in de gedeelde ruimte plaatsen en labelen, waarna andere autonome zoekers dit vinden, oppikken en gebruiken als onderdeel van hun eigen werk.
We hadden onze agents per toeval ertoe aangezet om onze repo als een blackboard te gaan gebruiken. Maar het was een ongeluk; het was geen bewuste actie en het was niet volledig gestructureerd. Enkele kernonderdelen van hoe blackboards normaal gesproken opereren ontbraken. Omdat het toevallig gebeurde, ben ik er niet van overtuigd dat ik onze agents betrouwbaar opnieuw zou kunnen aanzetten tot dit gedrag via prompts. Ik heb een vrij goed idee wat we hebben gedaan, omdat we analyse hebben uitgevoerd en de specifieke prompt hebben geïdentificeerd die deze cascade in gang heeft gezet, maar het was emergent gedrag, geen gestuurd gedrag.
Naast het bewust creëren van dit systeem in plaats van toevallig, geloof ik dat dit communicatiekanaal onafhankelijk van bronbeheer (source control) moet staan. Hoewel we het creëerden door een frequente push-cyclus af te dwingen, zijn we daar later vanaf gestapt. De frequente commits overbelastten onze CI-pipeline. We stapten over op pushen alleen wanneer een coherenter blok wijzigingen voltooid was. Hierdoor verloren de agents de continue stroom van updates over de voortgang.
Een goede toevallige oplossing vereist een goed intentioneel project. Ik ben begonnen aan een project dat ik Talwrn noem. Dat is Welsh voor een dorsput, een gebied of ruimte waar argumenten en conflicten worden uitgevochten. Dit is bedoeld als een blackboard voor agentic engineering. Mijn doel is een zeer eenvoudig te gebruiken tool die direct in je project kan worden geplaatst en onmiddellijk een communicatiekanaal biedt voor agents om werk te coördineren. De eerste stap is om Talwrn op een punt te brengen waarop het zijn eigen ontwikkeling kan ondersteunen. Ik ben van plan hier regelmatig over te berichten, omdat ik het wil gebruiken als een enkel, evoluerend voorbeeld van hoe pure agentic engineering kan verlopen.
Een Toevallig Blackboard-systeem
De tien engineers kregen de opdracht om een IROps-systeem voor luchtvaartmaatschappijen te bouwen. Dit is het systeem dat luchtvaartmaatschappijen gebruiken in een vluchtcontrolescentrum wanneer er iets misgaat: wanneer een vliegtuig een technisch defect heeft dat gerepareerd moet worden, of wanneer een bemanningslid ziek wordt en vervangen moet worden. Het is het middel waarmee zij beslissen welke vluchten worden geannuleerd, welke vliegtuigen worden gewisseld, welke passagiers worden uitgeladen en in hotels worden geplaatst, enzovoort. Ze doen dit voor honderden vliegtuigen, honderdduizenden passagiers en zeer veel bemanningsleden over meerdere stations en luchthavens. Het is een zeer moeilijk probleem om op te lossen en uit te voeren. Een IROps-systeem is complex om te bouwen, complex om te begrijpen en complex in gebruik.
We slaagden erin om er binnen vier dagen een te bouwen. Maar dit artikel gaat niet over hoe we dat hebben gedaan.
We begonnen met een specificatie en een gesimuleerde luchtvaartmaatschappij, omdat dit een oefening was en geen echte klant. We probeerden een paar dingen om te zien wat wel en niet zou werken. We gebruikten een monorepo en alle engineers begonnen tegelijkertijd. Na een paar dagen begonnen we dingen op interessante manieren te zien gebeuren; er ontstonden nieuwe patronen.
Emergent gedrag door het afstemmen van onze aanpak
Met veel agents die in één repo werkten, liepen de build-pipelines vast. Om dit op te lossen introduceerden we een discipline: onze agents moesten voortdurend committen en rebasen vanaf de main branch. In eerste instantie vereisten we een rebase na de commit en daarna een push, waarbij alle build-checks en controles actief waren. We introduceerden deze wijziging om build-fouten lokaal op te vangen: vroeg en vaak integreren.
Dit had echter een bijeffect. We instrueerden de agents om te plannen, het werk af te bakenen tot secties in de specificatie en plannen te maken die gekoppeld waren aan die secties. Deze plannen werden in de repo opgeslagen. Alle agents werkten vanuit dezelfde specificatie, gebruikmakend van dezelfde genummerde en geïdentificeerde secties. Terwijl de agents werkten, werden de plannen bijgewerkt om de voortgang vast te leggen. Deze updates werden, samen met alle andere wijzigingen, meegenomen in de nieuwe commit-discipline. Hierdoor konden agents de voortgang van andere agents zien.
Stel dat één agent werkte aan de evaluator, het component dat bepaalt of een specifiek plan om de operaties te herstellen geldig is (of het harde of zachte restricties schendt, etc.). Tegelijkertijd werkte een andere agent aan het zoekalgoritme dat zoekt naar plannen die de verstoring kunnen oplossen. Het zoekcomponent is afhankelijk van de evaluator. Elk component kan afzonderlijk worden geschreven, maar er is een gedeelde interface en de zoekfunctie leunt op de evaluator.
De plannen legden deze integratiepunten vast. Het ene plan vermelde: "op dit punt moet ik de aanroepende functies bijwerken zodat ze de echte verifieerder aanroepen". Aan de zoekzijde stond: "op dit punt moet ik de aanroep naar de echte verifieerder invoegen zodra deze beschikbaar is". Beide agents konden elk plan en de voortgang ervan inzien. We realiseerden ons dat de agents de plannen gebruikten om te coördineren. Wanneer één agent een regel van het plan markeerde als "in behandeling", zag de andere agent dat en werkte niet aan die specifieke regel. Wanneer de eerste agent klaar was, zag de andere agent niet alleen dat het werk voltooid was en hij dus kon doorgaan, maar kreeg hij ook direct aantekeningen over hoe de regel was geïmplementeerd.
We begonnen dit uit te buiten. We startten een sessie en instrueerden deze om aan een specifiek traject te werken. Een voorbeeld was het introduceren van een kostenmodel naast de verifieerder. Wetende dat iemand anders aan het kostenmodel had gewerkt en voortdurend commits pushte, instrueerden we de agent die aan de verifieerder werkte om de plannen en broncode te bekijken, de repo te monitoren en, zodra het werk voor het kostenmodel werd gepusht, te beginnen met de integratie. En dat gebeurde ook.
Dit was volledig ad hoc. Het was het resultaat van een reeks toevallige beslissingen. We zagen het gebeuren en begonnen het vervolgens bewust in te zetten.
De repo als toevallig blackboard-systeem voor agents
Er is een naam voor het patroon dat onze agents hadden ontdekt: een blackboard-systeem. Dit is iets waar ik tijdens mijn studietijd onderzoek naar heb gedaan. Mijn scriptie ging over het sturen van agent-gedrag met hiërarchische sensoren. Ik keek naar het toepassen van destijds moderne machine learning-technieken, zoals reinforcement learning, op grote, dynamische datasets. Bij het bestuderen van de literatuur adopteerde ik het blackboard-patroon als de kernstructuur voor coördinatie. Dit patroon was eerder ontdekt bij de ontwikkeling van het Hearsay-II-systeem in 1980 en werd later door Gelernter et al. in 1986 verder ontwikkeld tot het formalere concept van de tuple space.
Een blackboard of tuple space is een gedeeld geheugen waarin autonome agents onafhankelijk van elkaar kunnen lezen en schrijven. Ze lezen en schrijven tuples met een bepaalde minimale structuur, en daarna zoveel extra velden als gewenst: er is geen vast schema. Het is een zeer effectieve techniek voor het coördineren van autonome probleemoplossers richting één gemeenschappelijk doel. Ze kunnen elk een ontleed deel van het probleem oplossen, hun oplossing in de gedeelde ruimte plaatsen en labelen, waarna andere autonome zoekers dit vinden, oppikken en gebruiken als onderdeel van hun eigen werk.
We hadden onze agents per toeval ertoe aangezet om onze repo als een blackboard te gaan gebruiken. Maar het was een ongeluk; het was geen bewuste actie en het was niet volledig gestructureerd. Enkele kernonderdelen van hoe blackboards normaal gesproken opereren ontbraken. Omdat het toevallig gebeurde, ben ik er niet van overtuigd dat ik onze agents betrouwbaar opnieuw zou kunnen aanzetten tot dit gedrag via prompts. Ik heb een vrij goed idee wat we hebben gedaan, omdat we analyse hebben uitgevoerd en de specifieke prompt hebben geïdentificeerd die deze cascade in gang heeft gezet, maar het was emergent gedrag, geen gestuurd gedrag.
Naast het bewust creëren van dit systeem in plaats van toevallig, geloof ik dat dit communicatiekanaal onafhankelijk van bronbeheer (source control) moet staan. Hoewel we het creëerden door een frequente push-cyclus af te dwingen, zijn we daar later vanaf gestapt. De frequente commits overbelastten onze CI-pipeline. We stapten over op pushen alleen wanneer een coherenter blok wijzigingen voltooid was. Hierdoor verloren de agents de continue stroom van updates over de voortgang.
Een goede toevallige oplossing vereist een goed intentioneel project. Ik ben begonnen aan een project dat ik Talwrn noem. Dat is Welsh voor een dorsput, een gebied of ruimte waar argumenten en conflicten worden uitgevochten. Dit is bedoeld als een blackboard voor agentic engineering. Mijn doel is een zeer eenvoudig te gebruiken tool die direct in je project kan worden geplaatst en onmiddellijk een communicatiekanaal biedt voor agents om werk te coördineren. De eerste stap is om Talwrn op een punt te brengen waarop het zijn eigen ontwikkeling kan ondersteunen. Ik ben van plan hier regelmatig over te berichten, omdat ik het wil gebruiken als een enkel, evoluerend voorbeeld van hoe pure agentic engineering kan verlopen.
Groetjes,