Hvordan en AI-agent fungerer trin for trin

En AI-agent fungerer trin for trin ved at modtage et mål, forstå konteksten, planlægge næste handling, bruge relevante værktøjer, kontrollere resultatet og gentage processen, indtil opgaven er løst eller bør stoppes. Den bør derfor ses som et kontrolleret feedback-loop, ikke som fri autonomi.

Hvad er en AI-agent i en trinvis proces?

En AI-agent er et AI-system, der kan arbejde gennem flere trin for at nå et mål. Den består typisk af en sprogmodel, instruktioner, adgang til udvalgte værktøjer og en form for tilstand, så den kan huske, hvad der allerede er sket i den aktuelle opgave.

Det centrale er, at agenten ikke kun svarer én gang. Den kan vurdere, om den mangler information, vælge et opslag, bruge et værktøj, læse resultatet og derefter beslutte næste skridt. Derfor adskiller den sig fra en almindelig tekstgenerator, der kun formulerer et svar ud fra den første forespørgsel.

En praktisk måde at forstå processen på er at se agenten som en arbejdsgang med beslutningspunkter. Mennesket definerer målet og grænserne. Agenten foreslår eller udfører de næste skridt inden for de grænser, den har fået gennem systemdesign, adgangsrettigheder og test.

Hvilke byggesten indgår i agenten?

De vigtigste byggesten er model, instruktioner, værktøjer, kontekst, hukommelse, kontrolregler og stopbetingelser. Modellen fortolker opgaven og vælger næste handling. Instruktionerne fortæller, hvad agenten må gøre, hvilke hensyn den skal tage, og hvornår den skal afvise eller spørge om mere information.

Værktøjer giver agenten mulighed for at gøre noget uden for selve tekstsvaret. Det kan være at søge i en vidensbase, hente data fra et CRM-system, køre en beregning, oprette en sag, læse en fil eller sende et forslag videre til en medarbejder. Uden værktøjer er agenten ofte tættere på en avanceret chatbot end på et handlingsorienteret system.

Kontekst og hukommelse gør, at agenten kan holde styr på målet, brugerens oplysninger, tidligere værktøjskald og delresultater. For en bredere introduktion til teknologien bag kunstig intelligens kan AI Mentors forklaring af hvad der definerer kunstig intelligens give et nyttigt grundlag.

Hvordan starter agenten med mål og kontekst?

Første trin er at omsætte brugerens ønske til et arbejdsbart mål. Hvis du beder en agent om at analysere en kundesag, skal den først afklare, hvad resultatet skal være: et svarudkast, en sagstype, en anbefalet handling, et datatjek eller en overdragelse til en person.

Derefter vurderer agenten, hvilken kontekst der er nødvendig. Det kan være brugerens besked, relevante dokumenter, kontooplysninger, politikker, tidligere trin i samtalen eller systemdata. En agent bør kun få den kontekst, der er nødvendig for opgaven. Bred adgang gør processen mere fleksibel, men også sværere at kontrollere.

Et godt starttrin indeholder også begrænsninger. Agenten bør vide, om den må handle selv, kun må foreslå, skal citere kilder, skal holde sig til godkendte dokumenter eller skal stoppe ved bestemte risici. Uden klare grænser kan agenten vælge en plausibel vej, som teknisk virker, men som ikke passer til organisationens ansvar eller dataregler.

Hvordan planlægger agenten næste skridt?

Når mål og kontekst er kendt, vælger agenten et næste skridt. Det kan være at svare direkte, stille et opklarende spørgsmål, hente viden, bruge et analyseværktøj, sammenligne to oplysninger eller sende opgaven videre. Planlægningen er ofte kort og løbende, ikke nødvendigvis en lang plan for hele opgaven fra starten.

Planen bør være tæt knyttet til tilgængelige værktøjer. En agent skal ikke bare tænke “find mere information”. Den skal kunne vælge et bestemt værktøj med et bestemt input, for eksempel et opslag i en godkendt vidensbase eller en forespørgsel i et begrænset datasæt.

Her opstår en vigtig forskel mellem en agent og et fast workflow. I et workflow er rækkefølgen typisk kodet på forhånd. I en agent vælger modellen i højere grad næste trin ud fra opgaven, værktøjsresultatet og de regler, den arbejder under. Det giver fleksibilitet, men kræver bedre logning, test og stopregler.

Hvordan bruger agenten værktøjer og data?

Værktøjsbrug er det trin, hvor agenten går fra sprog til handling. Den kan kalde en funktion, søge i et dokumentlager, hente en datapost, udfylde et formularudkast eller starte en beregning. Et værktøj bør være snævert beskrevet, så agenten ved præcist, hvad det kan, hvilket input det kræver, og hvad resultatet betyder.

Tre værktøjstyper går igen i praktiske løsninger:

• Dataværktøjer, der henter oplysninger fra dokumenter, databaser eller søgning.
• Handlingsværktøjer, der kan oprette, ændre eller sende noget i et eksternt system.
• Orkestreringsværktøjer, hvor en agent kan sende en delopgave til en anden specialiseret agent.

Jo mere et værktøj kan ændre i virkelige systemer, desto mere kontrol kræver det. Et læseværktøj til en vidensbase er normalt mindre risikabelt end et værktøj, der kan ændre en ordre, sende en besked eller opdatere en kundesag. Derfor bør de mest konsekvente handlinger ofte kræve menneskelig godkendelse.

Hvordan kontrollerer agenten resultatet efter hvert trin?

Efter et værktøjskald får agenten en observation tilbage. Observationen kan være et søgeresultat, en fejlbesked, et tal, en liste over dokumenter eller en bekræftelse på, at en handling er udført. Agenten bruger observationen til at vurdere, om den er tættere på målet, eller om næste trin skal ændres.

Denne del af processen er afgørende, fordi agenten ellers kan fortsætte på et forkert grundlag. Hvis et opslag returnerer for lidt data, bør agenten ikke skrive et sikkert svar. Den bør stille et opklarende spørgsmål, vælge et andet værktøj, forklare usikkerheden eller sende opgaven videre.

I tekniske systemer kaldes dette ofte miljøfeedback eller ground truth: agenten skal se, hvad der faktisk skete, ikke kun antage det. AI Mentors gennemgang af grounding af AI-modeller forklarer, hvorfor svar bliver mere kontrollerbare, når modellen forbindes med konkrete kilder og observationer.

Hvordan fungerer hukommelse og tilstand?

Hukommelse i en AI-agent betyder ikke nødvendigvis permanent hukommelse om brugeren. Det kan blot være en midlertidig tilstand i den aktuelle opgave: mål, deltrin, allerede brugte værktøjer, resultater, usikkerheder og åbne spørgsmål. Den tilstand hjælper agenten med ikke at gentage sig selv eller miste tråden.

Der findes også løsninger med længerevarende hukommelse, hvor agenten kan genbruge præferencer, arbejdsmønstre eller tidligere sagsinformation. Det kræver tydelig datastyring. Brugeren bør vide, hvad der gemmes, hvorfor det gemmes, hvor længe det gemmes, og hvordan forkerte eller forældede oplysninger håndteres.

For mange organisationer er den vigtigste hukommelse ikke personlig, men faglig. Det kan være dokumenter, politikker, produktdata, supportartikler eller embeddings i en søgbar struktur. Hvis agenten arbejder med semantisk søgning, kan en forklaring af hvad en vektordatabase er gøre det lettere at forstå, hvordan relevante tekststykker findes frem.

Hvornår stopper agenten eller spørger et menneske?

En agent bør have klare stopbetingelser. Den kan stoppe, når den har leveret et gyldigt svar, når en bestemt handling er godkendt, når den ikke finder tilstrækkeligt grundlag, når den rammer en maksimal mængde trin, eller når opgaven kræver ansvar, som systemet ikke bør automatisere.

Menneskelig overdragelse bør være en del af designet fra starten. Det kan være relevant ved økonomisk betydning, følsomme data, juridisk eller medicinsk indhold, tvivl om identitet, uklare kilder, gentagne fejl eller brugerinput, der forsøger at ændre agentens regler. Overdragelsen bør indeholde et kort resumé, brugt kontekst, delresultater og usikkerheder.

Stopbetingelser beskytter både brugeren og organisationen. De forhindrer, at agenten fortsætter med flere og flere forsøg, selv om datagrundlaget er svagt. De gør også drift billigere, fordi et agentloop uden grænser kan bruge unødigt mange modelkald, opslag og eksterne systemhandlinger.

Hvordan adskiller processen sig fra et fast workflow?

Et fast workflow følger en bestemt rækkefølge. Det er velegnet, når opgaven kan beskrives med stabile regler: modtag formular, kontroller felter, beregn resultat og send til godkendelse. En agent er bedre, når næste skridt afhænger af ustruktureret input, uklare undtagelser eller flere mulige værktøjer.

Den bedste løsning er ofte en kombination. Et system kan bruge et fast workflow til de kritiske trin og en agent til at forstå brugerens input, finde relevant viden eller forberede et forslag. Eksempler på mere afgrænsede anvendelser findes i AI Mentors gennemgang af AI-agenter til automatisering af kundeservice.

Hvilke fejl opstår typisk i agentloopet?

Fejl opstår ofte, når agenten misforstår målet, vælger det forkerte værktøj, læser et værktøjsresultat forkert, fortsætter uden sikkert grundlag eller udfører en handling, som burde have været godkendt. Fejlen kan blive større end i et almindeligt enkeltsvar, fordi den kan forplante sig gennem flere trin.

En typisk fejl er falsk sikkerhed. Agenten finder et delvist relevant dokument og skriver et svar, som lyder præcist, selv om dokumentet ikke dækker brugerens situation. En anden fejl er værktøjsoverlap, hvor flere værktøjer ligner hinanden, og agenten vælger et forkert opslag eller en forkert handling.

Der kan også opstå fejl, når eksternt indhold forsøger at påvirke agentens adfærd. Hvis agenten læser websider, dokumenter eller brugerindsendt tekst, skal systemet behandle indholdet som data, ikke som styrende instruktioner. Ellers kan agenten blive ledt væk fra sin oprindelige opgave.

Hvordan bør du vurdere en agent før drift?

Før drift bør du teste agenten på realistiske opgaver, ikke kun på pæne eksempler. Testmaterialet bør indeholde korte beskeder, lange beskeder, ufuldstændige oplysninger, modstridende kilder, irrelevante dokumenter, fejl i eksterne systemer og situationer, hvor det korrekte svar er at stoppe.

Evalueringen bør måle flere ting på én gang: om agenten forstår målet, vælger rigtigt værktøj, bruger kilder korrekt, markerer usikkerhed, holder sig til sine rettigheder, stopper ved risiko og leverer et output, som en person kan kontrollere. Hvis testen kun måler, om svaret lyder godt, overser den de vigtigste agentfejl.

For opgaver med analyse og rapportering er sporbarhed særligt vigtig. Agenten bør kunne vise datakilde, beregning, fravalg og usikkerhed, så en fagperson kan kontrollere resultatet. AI Mentors artikel om AI-agenter til dataanalyse og rapportgenerering uddyber, hvorfor agentens forklaring ikke må skjule datagrundlaget.

Hvilke sikkerheds- og datagrænser kræver agenten?

En AI-agent bør have mindst mulige rettigheder. Den skal kun kunne se de data og bruge de værktøjer, der er nødvendige for opgaven. Et system, der kan læse alt, skrive til flere systemer og sende beskeder uden godkendelse, har langt større risiko end en agent med snævre funktioner og tydelige stopregler.

Kontrollen bør ligge i applikationen omkring modellen. Det omfatter adgangsstyring, validering af værktøjsinput, logning af værktøjskald, menneskelig godkendelse ved risikable handlinger, versionsstyring af instruktioner og overvågning af fejl. Modellen bør ikke alene afgøre, om en handling er sikker nok.

OWASP beskriver overdreven handlefrihed som en central risikotype for LLM-baserede applikationer. NISTs ramme for AI-risikostyring peger samtidig på behovet for governance, måling og løbende håndtering af AI-risici. I praksis betyder det, at agentens trin skal kunne forklares, testes og afbrydes.

Hvordan ser processen ud fra start til slut?

En samlet agentproces kan beskrives som en række gentagne beslutninger. Tabellen viser en enkel version, som kan bruges til at forstå både teknisk design og praktisk kontrol.

Det vigtigste er, at hvert trin har en teknisk eller organisatorisk grænse. Agentens værdi kommer fra fleksibel vurdering i midten af processen. Sikkerheden kommer fra klare rammer omkring processen.

Hvilke kilder ligger til grund?

Artiklen bygger især på Anthropic Engineering om effektive agentiske systemer, OpenAIs praktiske guide til at bygge agents og OpenAI Agents SDK’s forklaring af agents som model, instruktioner, værktøjer og guardrails. Risikodelen er holdt op mod NIST AI Risk Management Framework og OWASP Top 10 for LLMs 2025.