docs: plain-text brief — goal + two approaches (MAF vs Claude Agent SDK) + learning goal

Framework-neutral narrative of what portfolio-optimiser aims to achieve and the
two hypothesised approaches to the same method. Claude Agent SDK paragraphs
corrected by the user: the SDK spans both emergent (one agent + subagents) and
explicit orchestration (hand-written or agent-authored workflow script with a
non-LLM validator gate). The real difference vs MAF is ready-made named
constructs vs building blocks — not emergent vs explicit.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fif1r1En5W542HbZV88yMH

docs/2026-06-24-two-approaches-brief.md

@@ -0,0 +1,13 @@
+# Hva vi vil oppnå — og to tilnærminger til det (hypoteser)
+
+*portfolio-optimiser · 2026-06-24 · MAF-varianten er delvis på plass; Claude Agent SDK-varianten er foreløpig en hypotese.*
+
+Vi vil bygge et generisk rammeverk som finner kostnadsbesparelser inni hvert enkelt prosjekt i en portefølje — ikke ved å flytte penger mellom prosjekter, men ved å lete internt i hvert av dem. Måten det skjer på er den samme uansett teknologi: flere AI-agenter samarbeider og utfordrer hverandre fram til forslag (én foreslår, en annen prøver å rive det ned — «maker-checker»), og så avgjøres den faktiske verdien av forslagene av en deterministisk validator som ikke er en språkmodell, men ren beregning. En fagperson vurderer resultatet, og systemet lærer av dommene over tid. Den metoden er kjernen, og den er uavhengig av hvilket agent-rammeverk vi kjører den på.
+
+Det vi nå vil finne ut, er hvordan den samme metoden ter seg på to ganske ulike fundamenter. Den første tilnærmingen bygger på Microsoft Agent Framework (MAF). Der får vi både agent-debatten og det blokkerende validator-steget mer eller mindre ferdig: rammeverket har egne, navngitte mønstre for hvordan agenter debatterer, og det lar oss legge inn et rent beregningssteg som en fast node midt i flyten, slik at ingenting går videre før validatoren har sagt sitt.
+
+Den andre tilnærmingen bygger på Claude Agent SDK. Der finnes ikke de samme navngitte debatt-mønstrene som i MAF. Rammeverket gir deg ikke et ferdig vokabular for hvordan agenter debatterer, men byggeklossene til å sette det sammen selv, og det spenner over et bredt spekter. I den ene enden har du én sterk, selvstendig agent som deler oppgaver ut til spesialiserte underagenter og finner veien selv. I den andre enden kan du orkestrere eksplisitt, enten ved å skrive et orkestreringsskript for hånd, eller ved å la agenten skrive det selv som en dynamisk workflow der skriptet holder loopen, forgreningene og mellomresultatene. Maker-checker-mønsteret får vi altså ikke som en navngitt primitiv, men vi kan komponere det. Uavhengige agenter kan vurdere hverandres funn adversarielt før noe rapporteres.
+
+Det blokkerende validator-steget har på samme måte to ruter. Vi kan tvinge det fram med en regel som stopper alt agenten prøver å gjøre helt til validatoren har kjørt, eller vi kan legge den rene beregningen som en fast gate inne i et workflow-skript, mellom agent-kallene og uten språkmodell i loopen. Den siste ligger tett opp til MAFs faste node i flyten. Forskjellen mot MAF handler derfor ikke om emergent mot eksplisitt, for SDK-en kan gjøre begge deler. Den handler om at MAF gir deg rekkefølgen som ferdige, navngitte konstruksjoner, mens SDK-en gir deg verktøy og gjerder og lar oss, eller Claude, tegne partituret selv. Foreløpig er dette en hypotese. Vi har ikke bygget det ennå, mens MAF-varianten allerede er delvis på plass.
+
+Læringsmålet er nettopp denne sammenligningen. Svært få kjenner begge rammeverkene godt nok til å si hvor de faktisk skiller lag i praksis, og den eneste ærlige måten å finne det ut på er å bygge det samme på begge og måle dem mot samme målestokk. Derfor lager vi én felles fasit — et sett syntetiske testtilfeller med kjente, forventede validator-svar — som begge implementasjonene må bestå. Når begge løser samme oppgave mot samme fasit, blir forskjellene reelle og målbare: hvor mye må vi selv bygge, hvor godt holder den deterministiske garantien, hva koster det, og hvilket fundament passer best til denne typen problem. Det er det vi vil sitte igjen med — ikke en teoretisk funksjonssammenligning, men erfart kunnskap om hva de to faktisk innebærer i praksis.