Der er en ret ubekvem pointe i Towards AIs nyhedsbrev LAI #121. Den er næsten irriterende, fordi den er så genkendelig: jeres næste AI-system er sandsynligvis allerede gjort for komplekst, før det overhovedet er bygget. Det er deres formulering, ikke vores, men den rammer. Vi har siddet i nok møder til at kende scenen: whiteboardet er fyldt med bokse, pile og små kasser med ord som agent-router, planner, evaluator og memory-layer, mens ingen helt har fået sagt højt, hvad succes faktisk er.

Det er også her, LAI #121 rammer noget vigtigt. Nyhedsbrevet peger på, at mange produktionsproblemer starter allerede ved det tidlige valg mellem agent og workflow. Det lyder nørdet, men er i virkeligheden ret jordnært. Vælger man for meget autonomi for tidligt, får man sjældent mere værdi. Oftere får man flere fejlveje, sværere fejlfinding og et system, der ser godt ud i demoen og mindre godt ud en tirsdag morgen i drift.

Agent eller workflow

Lad os være ærlige. Mange ledelser siger, at de vil have agenter, når de i virkeligheden bare vil have færre manuelle trin. Der er en forskel. Et workflow er i praksis en fastlagt kæde af trin, hvor man ret præcist ved, hvad der skal ske og i hvilken rækkefølge. En agent er mere løs i kanten. Den får et mål, adgang til værktøjer og større spillerum til selv at vælge næste skridt.

LAI #121 formulerer det skarpt: spørgsmålet er agent eller workflow, og hvis man vælger forkert, begynder de fleste produktionshovedpiner der. Det er svært at være uenig. Hvis opgaven er forudsigelig, med klare regler og gentagne trin, er et workflow ofte stærkere end en agent. Ikke fordi det er flottere. Tværtimod. Men fordi det er lettere at styre, billigere at drive og langt nemmere at forklare, når noget går skævt.

Vi ser det ret konkret i dansk virksomhedsvirkelighed. En organisation vil måske automatisere håndtering af indkomne kundehenvendelser. Det lyder straks som noget, der kalder på en agent med værktøjer, adgang til CRM, søgning i dokumenter og måske en supervisor-agent ovenpå. Men når man skræller ambitionen ned, viser det sig tit, at behovet er mere kedeligt, og derfor mere interessant: klassificér henvendelsen, hent relevant politik, foreslå svar, send til godkendelse. Det er ikke et agentorkester. Det er et workflow med god disciplin.

Prisen på at starte for stort

Snillds vurdering er ret klar her. Vi er enige i hovedpointen fra både LAI #121 og den manuelle brief, der ligger bag historien: mange virksomheder planlægger eller bygger for komplekse AI-systemer, før de forstår det reelle forretningsbehov. Det kan lyde som en banal projektfejl, men i AI bliver den dyr hurtigt, fordi kompleksiteten smitter af på alt andet: test, dataflow, sikkerhed, logging, roller, ansvar og driftsmodel.

Og regningen kommer tidligt. Som tid tabt i afklaringer. Som penge brugt på integrationer, ingen bruger endnu. Som driftssikkerhed, der falder, fordi ingen rigtigt kan se, hvorfor systemet valgte vej A frem for B. Og måske mest irriterende: som forsinket værdiskabelse. Imens man bygger den store arkitektur, står den lille, nyttige forbedring stadig og venter ude i virkeligheden.

Det er også her, mange AI-projekter bliver lidt selvforelskede. Arkitekturen bliver et mål i sig selv. Vi har set workshops, hvor ordet autonomi blev brugt ti gange, før nogen nævnte fejlrate eller svartid. Det er et dårligt tegn. Hvis KPI’en stadig er uklar, er det sjældent tiden til at tegne fem agenter og tre feedback-loops.

Single-agent sweet spot

LAI #121 bruger et begreb, som faktisk er brugbart og ikke bare smart klingende: single-agent sweet spot. Altså det område, hvor én agent med de rigtige værktøjer kan løse et dynamisk problem uden, at systemet tipper over i unødig kompleksitet. Ikke som universel sandhed. Mere som en ædru tommelfingerregel.

I nyhedsbrevet beskrives også et kompleksitetsspektrum. Enkle, forudsigelige opgaver bør ofte løses med simple workflows. Dynamiske problemer kan i mange tilfælde klares af én agent med værktøjer. Først når der er reelle brudpunkter, giver det mening at gå videre til multi-agent-systemer. Det er egentlig befriende konkret. Ikke alt behøver en generalstab.

Hvornår er én agent nok? Når opgaven kræver lidt fleksibilitet, men stadig kan holdes inden for tydelige rammer. For eksempel hvis systemet skal vælge mellem få kendte værktøjer, opsummere materiale, slå op i afgrænsede kilder og foreslå en handling, som et menneske stadig kan godkende. Hvornår er én agent for meget? Når opgaven i bund og grund er deterministisk, og reglerne allerede er kendte. Så er agenten mest en dyr omvej.

Autonomi er et systemspørgsmål

En anden central pointe i LAI #121 handler om bias. Nyhedsbrevet rejser spørgsmålet, om bias bliver forstærket, når AI-agenter bliver mere autonome. Det spørgsmål bliver ofte håndteret alt for løst i debatten. Her er Towards AIs pointe mere præcis: Når autonomien stiger, skal bias ikke kun styres på modelniveau, men på systemniveau.

Det er vigtigere, end det lyder. For i praksis kommer mange skæve eller risikable udfald ikke kun fra selve modellen, men fra det system, modellen er sat ind i. Hvilke værktøjer har den adgang til. Hvilke data må den hente. Hvad må den beslutte selv. Hvornår kræves godkendelse. Hvad bliver logget. Hvilke handlinger er blokeret. Det er den slags, der afgør, om autonomi er brugbar eller bare uansvarlig.

Oversat til driftssprog handler det om hegn. Ikke flotte strategihegn, men rigtige hegn. Adgangskontrol. Beslutningsgrænser. Godkendelsestrin. Logging, så man kan se, hvorfor et svar eller en handling opstod. Menneske-i-loop, hvor det giver mening, ikke som ritual, men som konkret stopklods før irreversible ting sker. Det er mindre sexet end at tale om agentic AI. Til gengæld virker det.

RAG er et godt eksempel på samme fejl

LAI #121 lancerer også en ny sektion, AI Tip of the Day, og første råd handler om RAG-pipelines. Pointen er enkel og ret vigtig: evaluér retrieval og generation i to adskilte lag. For retrieval skal man måle, om relevant evidens faktisk blev hentet, for eksempel med recall@k og Mean Reciprocal Rank. For generation skal man måle, om svaret holder sig tro mod den hentede kontekst og faktisk besvarer spørgsmålet.

Det lyder teknisk, men problemet er meget menneskeligt. Mange teams blander de to fejltyper sammen. Hvis retrieval er dårlig, hjælper det ikke meget at finjustere prompten. Hvis retrieval er fin, men modellen ikke bruger materialet ordentligt, er det en anden fejl med en anden løsning. Uden den opdeling fejlsøger man i blinde. Og så står tre mennesker pludselig med tre forskellige forklaringer på det samme skæve svar.

Det er i grunden samme tema som i resten af historien. Når man ikke skiller tingene ad, vokser kompleksiteten hurtigere end forståelsen. Så begynder man at kompensere med flere lag, flere agenter og mere styring, før man har isoleret selve fejlen. Det svarer lidt til at skrue ekstra alarmer på et maskinrum, når man i virkeligheden bare ikke har fundet den løse ledning.

Hvad virksomheder bør gøre i stedet

Den praktiske konklusion er mindre dramatisk end hypebølgen, men mere nyttig. Start med en snæver MVP. Ikke den slags MVP, som i virkeligheden er et helt roadmap forklædt som pilot, men en reel, smal løsning med klare succesmål. Hvad skal blive hurtigere. Hvad skal blive mere præcist. Hvor meget mindre manuelt arbejde vil I faktisk fjerne. Hvis det ikke kan siges i almindelige sætninger, er projektet nok stadig for uklart.

Den manuelle brief er meget tydelig på samme punkt: vælg de enkleste modeller og integrationer, der løser kernen af problemet. Det råd lyder næsten for simpelt, men det er ofte det modne valg. Vi møder stadig en refleks, hvor nogen næsten skammer sig over at vælge en mindre avanceret løsning, som om den ikke er ambitiøs nok. Men modenhed i AI er ofte det modsatte. At vide, hvad man ikke skal bygge endnu.

Det betyder også, at man bør udskyde integrationer, som ikke er nødvendige for at bevise værdien. Ikke fordi integrationer er dårlige. Men fordi hver ekstra kobling åbner for flere fejl, mere sikkerhedsarbejde og mere drift. Hvis målet er at forbedre kvaliteten af interne svar fra supportteamet, behøver første version måske ikke adgang til alle systemer i huset. Måske er et afgrænset dokumentlager og et godkendt svarflow rigeligt. Mere end rigeligt i starten.

Det enkle skal stadig være robust

Her er det vigtigt ikke at romantisere den lille løsning. Simpelt er ikke det samme som skrøbeligt hjemmelavet. Hvis en smal MVP skal overleve mødet med virkeligheden, skal den bygges med nogle ret jordnære værn. Den manuelle brief peger på feature-flags, A/B-tests og løbende observability, og det er præcis den slags, der gør læring mulig uden at sætte hele driften på spil.

Feature-flags betyder, at man kan tænde og slukke funktioner uden dramatik. A/B-tests gør det muligt at sammenligne versioner på reel adfærd i stedet for mavefornemmelser. Observability lyder som et ord, der helst burde blive i serverrummet, men betyder bare, at man faktisk kan se, hvad systemet laver, hvor det fejler, hvad det koster, og om brugerne får mere værdi eller bare flere overraskelser. Det er ikke pynt. Det er værn mod at skalere kaos.

Derudover er der de lidt mindre synlige ting, som hurtigt bliver afgørende: governance, CI/CD for modeller, cost-aware arkitektur og menneske-i-loop, hvor risikoen kræver det. Vi har selv set, hvor hurtigt et ellers fornuftigt setup bliver uigennemskueligt, når modelversioner, prompts og retrieval-logik ændres uden ordentlig styring. Så sidder man der og diskuterer, om problemet startede i modellen, dataene eller orkestreringen. Ingen ved det helt. Kaffen bliver kold.

Den modne beslutning er ofte den mindst prangende

Det, der står tilbage efter LAI #121, er egentlig ikke et angreb på agenter. Det er mere et opgør med refleksen om, at mere autonomi automatisk er mere fremskridt. Nyhedsbrevet siger ikke, at multi-agent-systemer aldrig giver mening. Det siger, at man skal kende brudpunkterne, før man går derhen. Og den afvejning er vigtig, for der er stadig åbne spørgsmål om, hvornår en agent faktisk er bedre end et workflow i en konkret virksomhedssituation.

Vores egen vurdering er ret nøgtern. Den mest modne AI-beslutning i 2026 er ofte at skære ned, ikke bygge mere. At stoppe ved én agent. Eller ved ét workflow. Eller ved en helt almindelig integration uden agent overhovedet. Det lyder mindre futuristisk, ja. Men hvis målet er stabil drift og reel forretningsværdi, er det tit der, man finder det søde punkt.

Kilder

• LAI #121: The single-agent sweet spot nobody wants to admit
• LAI Games: Home
• Lambda Alpha International | Connecting professionals. Sharing …
• Chun-Ta Lai – Department of Biology – San Diego State University
• Learning for All Initiative (LAI) – Poverty Action Lab
• Dr. John Lai – Food and Resource Economics Department
• LAI International