AI-agent vs chatbot: vælg arkitektur efter handling og risiko
En chatbot er ofte nok, når brugeren stiller spørgsmål og selv udfører næste handling. En agent bliver relevant, når systemet skal vælge værktøjer, holde styr på processtatus og udføre kontrollerede handlinger. Vælg den mindst komplekse arkitektur, der løser opgaven.
De kriterier, der kan ændre valget
Læs rækken som et testspørgsmål. Tabellen er ikke en samlet vinderliste.
Primært mål
Samtale, svar, forklaring og forslag til en bruger.
At nå et mål gennem flere trin og eventuelt udføre handlinger.
Kontrolflow
Ofte request→response eller et relativt simpelt dialogflow.
Modellen kan vælge næste værktøj/handling inden for guardrails og exit-kriterier.
Tools
Kan bruge retrieval/værktøjer, men behøver ikke selv styre workflowet.
Tools er en central del af agentens evne til at hente data og handle.
Tilstand og hukommelse
Session-/samtalekontekst kan være nok.
Kræver ofte eksplicit opgavetilstand, checkpoints og kontrolleret memory.
Fejltilstande
Fejl rammer primært svaret og kan ofte rettes af brugeren.
Fejl kan propagere gennem værktøjskald og skabe ændringer i eksterne systemer.
Sikkerhed
Fokus på input/output, dataadgang og korrekt information.
Derudover rettigheder, prompt injection via værktøjer, budgets og blast radius.
Evaluering
Svarskvalitet, relevans og korrekthed kan ofte evalueres direkte.
Evaluer både slutresultat, værktøj trajectory, cost, latency og recovery.
Hvornår du vælger hvad
Når brugeren selv bør have kontrollen over næste handling.
Når dynamisk værktøjvalg/flertrinsarbejde skaber reel værdi og kan afgrænses sikkert.
Vægt kriterierne selv
Brug 1–5. Vægten er jeres prioritet; scoren bør komme fra jeres egen test.
En chatbot svarer; en agent kan vælge og handle
En chatbot er den enkleste arkitektur, når brugeren stiller et spørgsmål og selv beslutter næste skridt. En agent bliver relevant, når systemet skal vælge mellem værktøjer, arbejde over flere trin eller udføre en handling på brugerens vegne. Det ekstra ansvar gør agenten dyrere at teste, sikre og overvåge.
Start som chatbot, hvis svaret er slutproduktet
FAQ, intern viden og meget support kan løses med en god chatoplevelse, retrieval og klare kildehenvisninger. Der er ingen gevinst ved at give systemet autonom værktøjsadgang, hvis brugeren alligevel selv skal udføre handlingen bagefter. Mindre kompleksitet betyder færre fejltilstande.
Brug en agent, når næste handling ikke kan fastlåses på forhånd
En agent giver mening, når systemet eksempelvis skal vælge hvilken datakilde der er relevant, kombinere flere værktøjer eller fortsætte en researchopgave, indtil et mål er nået. Begræns værktøjssættet og definér stopkriterier. Jo mere frihed agenten får, desto mere skal den evalueres på hele forløbet – ikke bare slutsvaret.
Handlinger ændrer sikkerhedsmodellen
Så snart systemet kan sende, slette, købe, publicere eller ændre data, bør mindst mulige rettigheder, godkendelse, logs og idempotens ind i designet. En god tommelfingerregel er at gøre læsning let og irreversible skrivehandlinger svære. Hvis den regel føles som overkill for use casen, er en chatbot sandsynligvis nok.
Spørgsmål om emnet
Hvad er det korte svar på “AI-agent vs chatbot”?
Brug en chatbot når opgaven primært er dialog og svar. Brug agentarkitektur når systemet skal vælge handlinger og bruge værktøjer. Hvis du kun har brug for et enkelt opslag eller én fast handling, er et almindeligt workflow ofte enklere.
Hvornår er en chatbot nok?
Når værdien ligger i at svare, forklare eller finde viden, og brugeren selv kan tage næste handling. Så er ekstra værktøj-autonomi ofte unødvendig kompleksitet.
Hvad ændrer sig, når chatten får værktøjer med skriveadgang?
Sikkerhedsmodellen. Permissions, inputvalidering, logs, godkendelse og idempotens bliver en del af produktet, fordi systemet nu kan skabe sideeffekter.
Hvad bør jeg især undgå?
“Agent” er blevet et marketingord. Vurder kapabiliteter og sideeffekter, ikke etiketten.