## [Løkken hængte sig selv, nu står kampen mellem grafen og loggen](/da/node/280) *Indsendt af Lennart den ons, 16 sep 2026 - 11:01* [ ![Løkken hængte sig selv, nu står kampen mellem grafen og loggen](/sites/default/files/styles/max_1300x1300/public/2026-09/composite_6.png.avif?itok=8PUXBQZ1)](/sites/default/files/2026-09/composite_6.png) For et år siden var de fleste AI-agenter bygget som en løkke. Spørg modellen, kald et værktøj, læg svaret tilbage i samtalen, spørg igen. Det virkede fint i en demo, der tog tredive sekunder. Så begyndte agenterne at få rigtige opgaver. Opgaver, der tager en time, kalder fem systemer ud af huset og skal vente på, at et menneske siger god for noget. Og løkken holdt ikke. Den havde hele sin tilstand i hukommelsen, så en genstart slettede arbejdet, og en agent, der ventede to dage på en godkendelse, var en proces, der skulle holdes i live i to dage. [Går den ned på trin syv](https://docujai.com/da/node/278), er alt væk. Løkken hængte sig selv i sin egen enkelhed. Tilbage står to former, og de bygger på to forskellige idéer om, hvem der bestemmer. Den ene hedder orkestrering, den anden koreografi. ## Orkestrering: Dirigenten Et orkester har en dirigent. Musikerne ved ikke nødvendigvis, hvornår de andre spiller. Det behøver de ikke, for dirigenten ved det og giver tegn. Sådan fungerer grafen. En motor kender hele forløbet som et kort: Først hentes kundens sag, så klassificeres den, så går den enten til et automatisk svar eller til en medarbejder. Hver station får et kald fra motoren, gør sit arbejde og afleverer resultatet tilbage. Stationerne kender ikke hinanden. De kender kun motoren. Det har to store fordele. Man kan tegne forløbet, og tegningen er rigtig, fordi motoren kører efter den. Og man kan altid svare på spørgsmålet «hvor står sagen nu?», fordi én ting ved det. Ulempen er den samme som fordelen. Alt går gennem dirigenten. Skal der et nyt trin ind, skal kortet ændres. Skal et andet system bruge resultatet, skal motoren lære at kalde det. Og forstår man ikke motoren, forstår man ikke systemet. ## Koreografi: Danserne En dans har ingen dirigent. Hver danser kender sin del og reagerer på det, de andre gør. Når partneren træder frem, træder man tilbage. Sådan fungerer loggen. Der er ingen motor. Når noget sker, skrives det som en hændelse: «Sag modtaget». Klassificeringen lytter efter den slags hændelser, gør sit arbejde og skriver en ny: «Sag klassificeret som reklamation». Reklamationsbehandlingen lytter efter netop den. Ingen har bestilt noget hos nogen. Alle reagerer på det, der står i loggen. Fordelen er, at systemet kan vokse uden at nogen skal spørges. Vil økonomi gerne have besked om alle reklamationer over 10.000 kroner, bygger man en ny lytter. Ingen eksisterende del skal ændres, og ingen af dem ved, at den nye findes. Og fordi hændelserne står i loggen, kan man [spole tilbage og spille dem igennem igen](https://docujai.com/da/node/279). Ulempen er, at ingen har overblikket. Forløbet findes, men det står ikke noget sted. Det opstår af, hvem der lytter efter hvad. Spørger kunden, hvor langt sagen er nået, skal svaret samles fra loggen. Og der er en særlig fejl, man kun ser i koreografi: To dele, der reagerer på hinandens hændelser, kan ende i en ring, som ingen har tegnet, fordi ingen har tegnet noget. ## Reaktive workflows: At vente uden at koste noget Det tredje begreb bliver ofte blandet sammen med de to andre, men det svarer på et andet spørgsmål. Orkestrering og koreografi handler om, hvem der styrer. Reaktive workflows handler om, hvad der sætter et trin i gang. Et almindeligt forløb spørger: Er der sket noget? Nej. Er der sket noget nu? Nej. Nu? Det er polling, og det er den måde, de fleste integrationer stadig virker på. Et reaktivt forløb gør det omvendte. Det sover, indtil der sker noget, og vågner af selve hændelsen. Forskellen betyder mest præcis dér, hvor AI-agenter er svagest: Når der skal ventes på et menneske. En godkendelse kan komme om fem minutter eller på mandag. Et forløb, der spørger hvert tiende sekund, bruger ressourcer hele weekenden. Et reaktivt forløb koster ingenting, mens det venter, og reagerer i samme øjeblik, svaret kommer. Jeg har selv bygget det for nylig. Når jeg stryger ja på telefonen i [janus](https://docujai.com/da/node/274), bliver svaret skrevet som en hændelse. [En lytter på min Mac abonnerer på dem](https://docujai.com/da/node/277) og sætter udgivelsen i gang. Der er stadig en poller som sikkerhedsnet, hvis forbindelsen falder. Men normalvejen er, at en hændelse bliver til en handling. Reaktive workflows passer naturligt til koreografi, hvor alt i forvejen er hændelser. Men de kan også findes i en graf, hvor en station står stille og venter på en hændelse udefra, før motoren går videre. ## Kampen ender uafgjort Det mest interessante er, hvad der sker med de værktøjer, der vinder frem. De blander. De motorer, man bruger til lange, pålidelige forløb, ser ud som orkestrering udefra. Der er en dirigent, og forløbet kan læses som almindelig kode eller en graf. Men under overfladen skriver de hvert trin ned som en hændelse. Går maskinen ned, spiller motoren hændelserne igennem, indtil den er tilbage, hvor den slap. Dirigenten har en log under armen. Og de fleste systemer, der er bygget som koreografi, får før eller siden en lille dirigent til de forløb, hvor nogen skal kunne svare på, hvor sagen står. Ordren følger dansen, men betalingen har en dirigent. Så spørgsmålet er sjældent grafen eller loggen. Det er, hvor meget af hver, og hvor grænsen går. ## Hvad en virksomhed skal tage med Du skal ikke vælge arkitektur. Men du skal kunne genkende, hvad du bliver tilbudt, og stille de spørgsmål, der afslører det. - **Hvem kender forløbet?** Er svaret «motoren», er det orkestrering. Så skal I have nogen, der forstår motoren, og I skal spørge, hvad der sker, når den er nede. - **Hvad skal der til for at tilføje et trin?** Skal kortet ændres og testes forfra, eller kan man bygge en ny lytter ved siden af? Det første er tryggere, det andet er hurtigere. - **Hvor står sagen lige nu, og hvem kan se det?** I koreografi er det et spørgsmål, der skal bygges et svar til. Glemmer man det, er det første, kundeservice opdager. - **Hvad koster det at vente på et menneske?** Kører der noget hele weekenden for at se, om chefen har svaret, er forløbet ikke reaktivt, og det bliver dyrere, jo flere godkendelser I lægger ind. - **Bliver hændelserne gemt?** Uanset form. Det er dem, der gør det muligt at genstarte, forklare sig og spole tilbage, og de kan ikke skabes bagefter. Løkken er ikke død. Den er stadig det rigtige til korte, ensartede opgaver, hvor det koster ingenting at starte forfra. Men så snart en agent skal vente, genstarte eller stå til regnskab, er det grafen og loggen, der er tilbage. Og de fleste gode systemer ender med lidt af begge. Se [Agenter](agenter) for arkitekturen omkring modellen og [Arkitektur](arkitektur) for det tekniske fundament.