Sådan fungerer AI-agenter: teknologi og algoritmer forklaret

AI-agenter fungerer ved at kombinere en sprogmodel med mål, kontekst, værktøjer og en kontrolsløjfe, der vurderer næste handling. Teknologien gør det muligt at løse flertrinsopgaver, men den kræver klare grænser, datakontrol, test og menneskelig godkendelse, når handlinger kan påvirke systemer eller mennesker.

Hvad er en AI-agent i teknisk forstand?

En AI-agent er et softwarebaseret system, der kan modtage et mål, fortolke kontekst, vælge en næste handling og bruge et eller flere værktøjer for at komme tættere på målet. I moderne generativ AI er kernen ofte en stor sprogmodel, men agenten er mere end selve modellen. Den består også af instruktioner, adgangsregler, dataforbindelser, hukommelse, værktøjer og en mekanisme, der afgør, om opgaven er færdig.

Det adskiller en agent fra en almindelig chatbot. En chatbot svarer typisk på en enkelt brugerbesked. En agent kan derimod arbejde over flere trin: læse en fil, udlede en plan, slå oplysninger op, kalde et API, kontrollere resultatet og fortsætte, hvis målet ikke er nået. Det gør teknologien relevant for opgaver, hvor svaret ikke kan gives sikkert i én isoleret modelkald.

Begrebet bygger på den bredere forståelse af kunstig intelligens som systemer, der kan behandle input og generere beslutningsstøtte, anbefalinger eller handlinger. Agentens særlige kendetegn er graden af handlingsrum: den får ikke kun lov til at formulere tekst, men også til at påvirke et digitalt miljø gennem kontrollerede værktøjer.

Hvilke komponenter består en AI-agent af?

En praktisk AI-agent kan forklares som en samling af komponenter, der hver løser en tydelig opgave. Sprogmodellen fortolker målet og producerer forslag til næste trin. Orkestreringen holder styr på rækkefølge, kontekst og stopbetingelser. Værktøjerne forbinder agenten til data, systemer eller funktioner. Kontrollerne begrænser, hvad agenten må gøre.

Når komponenterne skilles klart ad, bliver agenten lettere at teste og fejlfinde. Hvis alle beslutninger, værktøjer og rettigheder blandes sammen i én uigennemsigtig proces, bliver det sværere at afgøre, om en fejl skyldes modellen, data, et API, et dårligt værktøjsdesign eller manglende kontrol.

Hvordan omsætter agenten et mål til handlinger?

En agent arbejder normalt i en gentagen løkke. Først fortolker den målet og den tilgængelige kontekst. Derefter vælger den en handling, kalder eventuelt et værktøj og modtager et resultat fra omgivelserne. Til sidst vurderer den, om resultatet er nok, eller om næste trin skal udføres. Denne løkke fortsætter, indtil stopreglen aktiveres.

Et simpelt eksempel kan være en agent, der skal finde afvigelser i en salgsrapport. Den kan først identificere relevante kolonner, derefter beregne ændringer, derefter slå en forklaring op i en intern vidensbase og til sidst formulere en kort rapport. Hvert trin afhænger af resultatet fra det forrige, og agenten bør kunne standse, hvis datagrundlaget er uklart.

Det tekniske nøglepunkt er, at modellen ikke bare genererer slutsvaret. Den bruges som beslutningsmotor for, hvilken handling der skal ske nu. Derfor bør værktøjsresultater, fejlbeskeder og mellemtrin være skrevet i et format, modellen kan fortolke stabilt. Uklare værktøjsnavne, tvetydige felter eller skjulte antagelser øger risikoen for forkerte handlinger.

Hvilken rolle spiller sprogmodeller, embeddings og kontekst?

Sprogmodellen giver agenten evnen til at forstå instruktioner, skrive planer, tolke værktøjsresultater og formulere svar. I mange systemer er modellen en GPT-lignende transformer, som er trænet til at forudsige og producere tekst ud fra store mængder data. En teknisk indføring i GPT-modeller forklarer, hvorfor samme grundteknologi kan bruges til både dialog, analyse og kodehjælp.

Embeddings bruges ofte, når agenten skal finde relevant viden i dokumenter, produktdata eller supportmateriale. En embedding omdanner tekst til talrepræsentationer, så systemet kan finde semantisk beslægtet indhold. Det gør det muligt at hente kontekst, som modellen ikke nødvendigvis kender fra træningen, men retrieval er ikke en garanti for sandhed. Dårlige kilder, forældede data eller for brede søgeresultater kan stadig føre agenten forkert.

Kontekstvinduet sætter en praktisk grænse for, hvor meget information agenten kan have med i hvert modelkald. Derfor må agenten vælge, komprimere og prioritere. For meget irrelevant kontekst kan forringe præcisionen, mens for lidt kontekst kan få modellen til at udfylde huller med usikre antagelser. God agentarkitektur handler derfor lige så meget om kontekststyring som om modelvalg.

Hvordan bruger AI-agenter værktøjer og API’er?

Værktøjer er agentens forbindelse til verden uden for modellen. Et værktøj kan være en søgning, en databaseforespørgsel, en beregning, en filoperation, en kalenderhandling eller et kald til et eksternt system. I praksis eksponeres mange værktøjer gennem API’er, hvor agenten sender strukturerede parametre og modtager et struktureret svar.

Tool use kræver klare kontrakter. Værktøjet bør beskrive, hvilke felter det forventer, hvilke handlinger det udfører, hvilke fejl det kan returnere, og hvilke rettigheder det har. Hvis et værktøj både kan læse, oprette, ændre og slette data, bør agenten normalt ikke få hele funktionssættet, hvis opgaven kun kræver læseadgang. Små, specifikke værktøjer er lettere at kontrollere end store, åbne værktøjer.

Når en agent kalder et API, bør resultatet ikke automatisk blive til en ny handling. Et robust system validerer output, håndterer tomme svar, genkender fejl og skelner mellem observation og beslutning. Hvis en agent eksempelvis læser en ordrestatus, er det en observation. Hvis den ændrer ordrestatus, er det en handling med konsekvens og bør ofte kræve eksplicit godkendelse.

Hvordan arbejder planlægning, feedback og hukommelse sammen?

Planlægning hjælper agenten med at opdele et mål i mindre trin. Feedback fortæller, om hvert trin virkede. Hukommelse holder styr på, hvad agenten allerede har gjort, og hvilke oplysninger der stadig er relevante. Uden disse tre elementer bliver agenten let en serie isolerede modelkald, hvor hver ny handling mangler en stabil forbindelse til det samlede mål.

Der findes flere niveauer af hukommelse. Kort opgavehukommelse kan være de seneste værktøjsresultater i samme forløb. Sessionshukommelse kan bevare tilstand på tværs af en samtale. Langtidshukommelse kan gemme brugerpræferencer eller organisatorisk viden, men den kræver strengere styring, fordi den kan indeholde persondata, forretningsoplysninger eller forældede beslutninger.

Feedback bør komme fra omgivelserne, ikke kun fra modellens egen vurdering. Testresultater, valideringsregler, databasekvitteringer og menneskelig gennemgang giver agenten mere pålidelige signaler end en intern selvvurdering. Det er grunden til, at agentopgaver ofte egner sig bedst, når der findes klare succeskriterier: en test består, et felt valideres, et dokument opfylder krav, eller en bruger godkender næste trin.

Hvad er forskellen på en workflow-agent og en autonom agent?

Et workflow er en fastlagt proces, hvor koden bestemmer rækkefølgen. Modellen kan udfylde enkelte trin, men den vælger ikke frit, hvordan hele forløbet skal gennemføres. En autonom agent får større råderum til selv at vælge trin, rækkefølge og værktøjer inden for de grænser, systemet har sat.

Forskellen er ikke akademisk. Hvis opgaven altid følger samme mønster, er et workflow ofte mere forudsigeligt, billigere og lettere at teste. Det gælder eksempelvis klassificering af henvendelser, standardiseret dokumentudtræk eller faste godkendelsesflows. Hvis opgaven derimod kræver dynamisk problemløsning, ukendt antal trin eller kombination af flere kilder, kan en agent være mere passende.

Du kan bruge denne tommelfingerregel: jo mere konsekvens en handling har, jo mere bør processen være eksplicit. En agent kan godt foreslå, prioritere og forberede, mens selve beslutningen ligger i et workflow eller hos et menneske. Den kombination giver fleksibilitet uden at give modellen ubegrænset kontrol.

Hvilke algoritmiske mønstre bruges i praksis?

AI-agenter bruger sjældent én enkelt algoritme. De kombinerer mønstre fra sprogmodellering, søgning, planlægning, klassifikation, retrieval, evaluering og optimering. I nogle systemer er agenten primært en orkestreringsløkke omkring en sprogmodel. I andre indgår klassiske algoritmer til rangering, regler, rutevalg eller prioritering af handlinger.

Et centralt mønster er at skifte mellem ræsonnement, handling og observation. Forskningsarbejdet bag ReAct beskrev netop et mønster, hvor en model kan veksle mellem at tænke over næste trin og handle mod et eksternt miljø. I praksis betyder det, at agenten ikke kun svarer ud fra intern viden, men også kan hente ny information, prøve et værktøj og justere planen.

Andre mønstre er routing, hvor input sendes til den rette specialist; evaluator-optimizer, hvor et resultat vurderes og forbedres i en løkke; og retrieval-augmented generation, hvor modellen får relevante kilder ind i konteksten. I nogle miljøer kan reinforcement learning bruges til at træne beslutningsstrategier, men mange nutidige LLM-agenter i kontor- og softwareopgaver styres i stedet af regler, værktøjsdesign, evalueringer og modelkald.

Hvorfor opstår fejl, loops og hallucinationer i agentforløb?

Fejl i AI-agenter opstår ofte, fordi et forkert mellemtrin får konsekvenser i næste trin. En almindelig sprogmodel kan give et upræcist svar. En agent kan derimod bruge det upræcise svar til at kalde et værktøj, ændre data eller fortsætte i en forkert retning. Derfor kan små usikkerheder blive forstærket, hvis systemet ikke validerer observationer og beslutninger.

Loops opstår, når agenten ikke kan afgøre, at den er færdig, eller når værktøjsresultater ikke giver et klart signal. Den kan gentage søgninger, omskrive samme plan eller forsøge at løse en blokering med flere modelkald. Stopregler, maksimalt antal trin, fejlklassifikation og tydelige returnerede statuskoder gør sådanne forløb lettere at afbryde.

Hallucinationer er særligt problematiske, når agenten skal handle. En forkert antagelse om et kundenummer, en policy, en pris eller et filnavn kan føre til fejl i et eksternt system. Derfor bør agenten ikke behandle genereret tekst som dokumenteret fakta. Emnet hænger tæt sammen med AI-hallucination, men i agentarkitektur er konsekvensen større, fordi output kan blive til handling.

Hvordan kontrolleres sikkerhed, adgang og menneskelig godkendelse?

Sikkerhed i AI-agenter starter med at begrænse, hvad agenten kan gøre. Et system bør ikke give adgang til flere værktøjer, bredere data eller højere rettigheder end nødvendigt. Hvis agenten kun skal læse produktinformation, bør den ikke kunne ændre databasen. Hvis den kun skal foreslå en mail, bør den ikke kunne sende mailen uden godkendelse.

Adgang bør håndhæves uden for modellen. Det betyder, at downstream-systemer, API’er og databaser selv kontrollerer rettigheder, brugeridentitet og tilladte operationer. Modellen kan foreslå en handling, men den bør ikke være den eneste instans, der afgør, om handlingen er tilladt. Det reducerer skaden, hvis modellen misforstår input eller påvirkes af manipuleret indhold.

Human-in-the-loop er ikke bare et dekorativt lag. Det bør bruges ved irreversible, dyre, følsomme eller regulerede handlinger. Eksempler er sletning af data, udbetalinger, eksterne beskeder, ændring af rettigheder, ansættelsesrelaterede beslutninger eller behandling af personfølsomme oplysninger. For lavrisikoopgaver kan logging og efterkontrol være nok, men handlingens konsekvens bør bestemme graden af menneskelig kontrol.

Hvornår giver en AI-agent mere mening end en almindelig chatbot?

En AI-agent giver mest mening, når opgaven kræver både forståelse og handling. Det kan være analyse af flere filer, opdatering af et internt system, fejlsøgning på tværs af logs, udarbejdelse af en rapport med kildedata eller håndtering af en kundesag, hvor agenten skal hente ordredata og foreslå næste procestrin. Her er en statisk chatbot ofte for begrænset.

En chatbot er derimod ofte nok, når opgaven handler om forklaring, idéudvikling, opsummering eller svar på spørgsmål ud fra et afgrænset vidensgrundlag. Hvis brugeren selv kan tage næste handling, er der ikke nødvendigvis grund til at give systemet adgang til værktøjer. Mere autonomi bør kun tilføjes, når den løser et konkret problem, som ikke kan håndteres lige så godt med et enklere mønster.

En praktisk beslutning kan begynde med tre spørgsmål: Skal systemet handle i eksterne systemer? Er antallet af trin ukendt på forhånd? Kan resultatet testes eller godkendes undervejs? Hvis svaret på alle tre er ja, kan en agentarkitektur være relevant. Hvis svaret primært handler om tekstsvar, er en almindelig samtaleløsning ofte mere stabil.

Hvordan bør en organisation teste en AI-agent før drift?

Test af AI-agenter bør dække mere end svarkvalitet. Du bør teste værktøjskald, rettigheder, fejltilstande, stopregler, datakilder, logging, omkostninger og brugeroplevelse. En agent kan virke imponerende i en demo, men stadig være uegnet til drift, hvis den ikke håndterer tomme API-svar, langsomme systemer, modstridende oplysninger eller manglende adgang.

• Definér opgavens tilladte handlinger og forbudte handlinger.
• Kør tests med realistiske data, inklusive fejl, tvetydigheder og ufuldstændige input.
• Kontrollér at værktøjer kun har laveste nødvendige rettigheder.
• Mål hvor ofte agenten kalder værktøjer unødigt eller gentager trin.
• Indfør manuel godkendelse for handlinger med økonomisk, juridisk, sikkerheds- eller persondatamæssig konsekvens.
• Log beslutninger, værktøjskald og fejl på en måde, der kan revideres bagefter.

Risikostyring bør også være en del af livscyklussen efter lancering. Datakilder ændrer sig, modeller opdateres, og brugere finder nye måder at formulere opgaver på. Derfor bør agenten overvåges med faste evalueringsdata, versionsstyring af værktøjer, klare rollback-muligheder og periodisk gennemgang af hændelser.

Hvad betyder AI-agenters arkitektur for danske virksomheder?

For danske virksomheder ligger den praktiske værdi sjældent i fuld autonomi. Den ligger oftere i kontrolleret automatisering af dele af en arbejdsgang: indsamling af information, klargøring af beslutningsgrundlag, udfyldning af udkast, sammenstilling af data eller forberedelse af sager til menneskelig vurdering. Agenten bør designes omkring konkrete arbejdsopgaver, ikke omkring et generelt ønske om mere automatisering.

Hvis agenten behandler kundedata, medarbejderdata, kontrakter eller interne dokumenter, bør dataadgang og formål være tydeligt afgrænset. Det er ikke nok at spørge, om modellen kan løse opgaven. Du bør også vide, hvilke systemer den kan tilgå, hvilke handlinger den kan udføre, hvem der hæfter for beslutningen, og hvordan fejl opdages.

Derfor bør teknologien indføres gradvist. Start med læse- og analyseopgaver, hvor agenten producerer forslag. Tilføj skrive- eller handlingsrettigheder, når datakvalitet, evalueringsmetode, adgangsstyring og godkendelsesflow er dokumenteret. På den måde bliver agenten et kontrolleret lag i arbejdsprocessen frem for en uafgrænset digital aktør.

Hvilke kilder ligger til grund?

Den tekniske beskrivelse bygger blandt andet på OpenAIs dokumentation for Agents SDK, som beskriver agenter, værktøjer, handoffs, guardrails, sessions og human-in-the-loop. Den arkitektoniske skelnen mellem faste workflows og mere autonome agents bygger på Anthropics artikel Building effective agents.

De algoritmiske mønstre er kontrolleret mod forskningspaperet ReAct: Synergizing Reasoning and Acting in Language Models. Afsnittene om risikostyring og kontrol bygger desuden på NIST AI Risk Management Framework og OWASPs beskrivelse af Excessive Agency i LLM-baserede systemer.