Bewijs tegen enthousiasme: het register achter een build-versus-buy-beslissing

Veldnotities agentplatform, zeven van acht. De eerste zes notities bevatten meningen. Deze gaat over de discipline die voorkomt dat die meningen op eigen kracht een inkoopbeslissing worden.

De vraag

Build of buy is de vraag die een bestuur één keer stelt. Daaronder liggen honderd kleinere vragen, elk van de vorm “bestaat deze capability in het veld, hebben we hem nodig, en hebben we hem?” De faalwijze is bekend bij iedereen die ooit een leveranciersbeoordeling heeft meegemaakt: bewijs dat iets ergens bestaat, wordt stilletjes bewijs dat wij het hebben, of dat we voorlopen, of dat we het nooit zouden kunnen kopen.

De vraag voor deze notitie is dus: hoe houd je een bewijsbasis eerlijk wanneer de mensen die haar onderhouden, inclusief jijzelf, een bepaald antwoord willen?

Wat ik bouwde

Voor het agentplatform hield ik een register van capabilities bij. Tegen de tijd dat het stabiliseerde, telde het meer dan tweehonderd rijen, elk een capability die een governed agentplatform nodig zou kunnen hebben, afgeleid uit meer dan honderd externe projecten en enkele honderden onderzoeks- en praktijkbronnen, met elke rij geclassificeerd naar strategische positie: core, commodity, differentiator, open window, disrupter of moat.

De classificatie stuurde beslissingen. “Commodity” betekende kopen of adopteren. “Core” betekende bouwen of het contract bezitten. “Differentiator” en “moat” betekenden investeren. Die woorden dragen geld, dus de regels om ze toe te kennen moesten strenger zijn dan de regels voor een essay.

De regel die het werk deed

Ik schreef een korte bewijsstandaard met één centrale regel:

Bewijs dat een ander project een capability implementeert, bewijst externe haalbaarheid. Het bewijst niet dat wij die capability hebben gebouwd, opgeleverd, beheren, er beter mee presteren, hem uniek bezitten of er samengestelde waarde uit halen.

Al het andere volgt daaruit. Elke claim benoemt zijn onderwerp: het externe veld, een benoemde externe partij, het doelplatform of onze eigen organisatie. Elke claim benoemt zijn tijdsbereik: historisch, actueel per datum, doelsituatie, voorspelling of voorwaardelijk. “Het veld implementeert ondertekende ontvangstbewijzen”, “het platform zou ondertekende ontvangstbewijzen moeten afgeven” en “wij beheren ondertekende ontvangstbewijzen in productie” zijn drie verschillende claims, en het register laat je de derde niet schrijven met het bewijs voor de eerste.

Een paar andere regels bleken belangrijker dan ik had verwacht:

• Een bronvermelding is geen onafhankelijke bron. Twintig artikelen die één leveranciersaankondiging herhalen, tellen als één bronfamilie. Convergentie telt families.
• Redenering is geen bewijs. Panels van modellen, stemmen van reviewers en gemiddelde betrouwbaarheidsscores kunnen bewijs ordenen en uitdagen. Ze kunnen het niet creëren, en ze tellen niet als bevestiging.
• Geen pseudo-kansen. Een getal is alleen een kans als de kalibratiemethode is vastgelegd. Anders is het laag, gemiddeld of hoog, met de onzekerheid erbij.
• Afwezigheid wordt conservatief ingevuld. Als eigendom, uitrol of actualiteit niet te verifiëren is, zegt het veld onbekend. Het zegt niet het gunstige.
• Kanttekeningen overleven elke transformatie. Alleen toegang tot de samenvatting, auteurschap door een leverancier, een gedeeltelijke lezing: de kanttekening blijft gehecht aan elke claim die eruit is afgeleid.

Het eerste wat het deed

Toen ik de standaard toepaste op het bestaande register, voerde het uit wat ik nu de first-party herwaardering noem. Elke rij die een bestaand eigen asset claimde, elke “voorsprong”, elke “differentiator” in bezit, elke “moat”, werd afgewaardeerd, omdat het bewijs erachter extern was. We hadden honderd projecten gelezen. We hadden geen honderd capabilities gebouwd. De beslissingskwaliteit van het register ging naar “geblokkeerd”, en bleef daar totdat er eigen bewijs bestond.

Dat was de juiste uitkomst en het was onaangenaam. Het betekende dat de architectuur geen voordeel meer kon claimen op basis van onderzoek. Ze kon behoefte claimen, wat iets anders en beter verdedigbaars is, en ze kon de paar capabilities claimen waar daadwerkelijk code, tests en een draaiende demonstrator achter zaten.

Ik noem dit omdat dezelfde inflatie op dit moment in elke organisatie gebeurt die AI beoordeelt. Een pilot wordt “uitgerold”. De benchmark van een leverancier wordt “onze capability”. Een capability op een roadmap wordt een capability in een aanbestedingsantwoord. De herwaardering is het enige tegengif dat ik ken.

Richard Feynman zei het beter dan welke bewijsstandaard ook: het eerste principe is dat je jezelf niet voor de gek mag houden, en jij bent de makkelijkste om voor de gek te houden. De herwaardering is dat principe met een schema.

Hoe het de beslissing voedt

Het register beslist niet. Het ondersteunt een beslisrecord, met eisen, alternatieven, afwegingen, een eigenaar, acceptatietests en een reviewdatum. Het platform heeft er meer dan veertig. De taak van het register is ervoor te zorgen dat wanneer een beslisrecord “commodity, adopteren” zegt, het bewijs erachter hetzelfde zegt, met hetzelfde onderwerp en tijdsbereik, en dat iedereen de verwijzing kan volgen naar de onderbouwende passage in plaats van naar de naam van een repository.

Voor het build-versus-buy-antwoord zelf kwam het register uit op wat notities een en drie vanuit de architectuur betoogden: de runtime, de modellen, de gateways, de durable-execution-engine en de observability-stack zijn commodity of adopteren. De governance-ruggengraat is core, en niets in het veld was te koop dat die namens ons zou bezitten zonder de trust root te worden.

Wat ik nog niet kan bewijzen

Het register is een beslisinstrument, geen resultaat. Het heeft de architectuur eerlijker en trager gemaakt. Het is nog niet getest door het ding waarvoor het bestaat: een aanvechting bij een aanbesteding, een leverancier die beweert dat we een classificatie fout hadden, of een auditor die een verwijzing volgt en ontdekt dat die nergens naartoe leidt. De validators controleren structuur, onderwerpen, tijdsbereiken en vindplaatsen. Ze controleren niet of ik de passage goed heb gelezen.

Wat je hiermee doet

Heeft je organisatie een lijst met AI-capabilities, draai er dan één query op: zoek voor elke rij die “wij hebben” zegt het eigen artefact. Vind je dat niet, verander de rij dan in “het veld heeft” en noteer het gat. Kijk daarna hoeveel van je strategische claims het hebben overleefd. Dat getal is nuttiger dan welke roadmap ook.

Volgende en laatste notitie: de geschreven regels waaronder AI-codeeragents aan het platform mogen werken, en waarom validators detecteren maar nooit voorkomen.

Afgezien van de runtime, de modellen, de gateways, de execution engine en de observability-stack, wat heeft het veld ooit voor ons gebouwd? De ruggengraat. Het veld heeft de ruggengraat niet gebouwd.

Verwijzingen

De knipogen en citaten in dit stuk, met hun herkomst:

• Richard Feynman, “Cargo Cult Science”, Caltech commencement address (1974): the first principle is that you must not fool yourself.
• Monty Python’s Life of Brian (1979): “What have the Romans ever done for us?”