Har du snakket med en leverandør som lover en "AI-agent" som løser kundeservice, bokføring eller innholdsproduksjon for deg, uten at du helt klarer å sette fingeren på hva det egentlig er du får? Du er ikke alene. Begrepet brukes i dag om alt fra en chatbot med litt bedre svar enn før, til systemer som selvstendig planlegger og utfører flere steg for å løse en oppgave. Forskjellen mellom disse er stor, og den er avgjørende for hvor godt løsningen faktisk vil fungere for det du trenger.

Hvorfor dette faktisk løser noe nytt

Automatisering er ikke noe nytt. Lenge før språkmodeller fantes, bygde man systemer som fulgte faste regler: hvis kunden skriver "hvor er pakken min", vis ordrestatus. Hvis feltet er tomt, vis feilmelding. Dette fungerer utmerket så lenge alt som kan skje er kartlagt på forhånd.

Problemet oppstår når virkeligheten ikke følger manuset. En kunde skriver "den skulle jo kommet i går, hva skjer" uten å nevne ordrenummer. En annen kombinerer to spørsmål i samme melding, eller formulerer seg på en måte det rigide regelverket aldri ble bygget for å gjenkjenne. Før var svaret enten å bygge stadig flere spesialtilfeller inn i regelverket, noe som til slutt blir uoversiktlig og skjørt, eller å sende alt som avviker fra normalen videre til et menneske.

Det en språkmodell tilfører, er evnen til å forstå og håndtere nettopp det uforutsette, uten at hvert mulig avvik må kodes inn på forhånd. Den kan tolke en uklar formulering, forstå hva kunden faktisk mener, og velge riktig handling ut fra situasjonen, ikke ut fra en liste av forhåndsdefinerte mønstre.

Dette er samtidig grunnen til at rammene rundt modellen er så viktige. En språkmodell som får frie tøyler til å tolke og handle, kan også tolke feil, velge feil verktøy, eller trekke en konklusjon som virker rimelig men er gal. Fleksibiliteten som gjør systemet nyttig, er den samme egenskapen som gjør det nødvendig med tydelige grenser.

To ting styrer i praksis hva en agent leverer. Det ene er hvilken informasjon den i det hele tatt har tilgang til: en agent bør kun se det den faktisk trenger for å løse akkurat denne oppgaven, ikke få fritt søk i alt et selskap måtte ha av data. Det andre er eksplisitte regler for hva den har lov til å gjøre og ikke gjøre, satt av de som bygger systemet, ikke overlatt til modellens egen vurdering. Skal den kunne sende en e-post på egen hånd, eller bare foreslå en? Skal den kunne innvilge en refusjon, eller bare flagge at en refusjon virker rimelig? Dette er ikke tekniske detaljer, det er selve kontrollmekanismen. Det er ikke et motsetningsforhold mellom fleksibilitet og kontroll, det er selve poenget: man bytter et system som aldri kan håndtere det uforutsette, mot et system som kan, forutsatt at noen med god forståelse av oppgaven har bestemt nøyaktig hva det får se og hva det får lov til å gjøre med det.

Fra ett språkmodell-kall til noe som kan handle

Den enkleste formen for AI i en applikasjon er ett enkelt kall til en språkmodell: du sender inn en tekst, får et svar tilbake, ferdig. Legg til at modellen kan hente informasjon (for eksempel søke i en database) eller bruke verktøy (for eksempel slå opp en ordrestatus), og du har det som gjerne kalles en "augmentert" modell. Dette er byggeklossen alt annet bygges videre på.

Anthropic, selskapet bak Claude, har satt et nyttig skille i sin egen forskning på temaet: workflows er systemer der språkmodeller og verktøy styres gjennom forhåndsdefinerte kodeløyper, mens agenter er systemer der språkmodellen selv styrer prosessen og bruken av verktøy underveis. Med andre ord: en workflow følger en oppskrift du har skrevet på forhånd. En agent får selv bestemme rekkefølgen og hvilke verktøy den bruker for å nå målet.

Dette er ikke bare en teknisk detalj. Det avgjør hvor forutsigbart systemet oppfører seg, hva det koster å drifte, og hvor mye tillit du må ha til at det tar riktige valg på egen hånd.

Deterministisk og probabilistisk, forklart med et eksempel

Se for deg en kunde som skriver til en nettbutikks chat: "Hvor er pakken min?" Det finnes to fundamentalt ulike måter å bygge et system som svarer på dette.

Den ene lar en språkmodell "gjette seg fram" til et svar basert på det den har lært generelt om verden. Det er en dårlig idé her, fordi modellen ikke faktisk vet hvor akkurat denne pakken befinner seg. Den kan høres overbevisende ut og likevel ta feil.

Den andre, og riktige, tilnærmingen er å skille de to oppgavene som faktisk ligger i spørsmålet. Å finne ut hvor pakken er, er et rent oppslag i en database eller mot et fraktsystem, noe kode kan gjøre presist og feilfritt hver eneste gang. Å formulere et hyggelig, forståelig svar til kunden basert på det oppslaget, er derimot noe en språkmodell er god på. Systemet gjør altså oppslaget deterministisk (kode, samme input gir alltid samme output) og formuleringen probabilistisk (språkmodellen, som varierer og resonnerer).

Dette er kjerneprinsippet i det som skiller en solid AI-agent fra en som virker smart i en demo, men blir upålitelig i produksjon: alt som kan løses med kode og faste regler, skal løses med kode. Språkmodellen brukes kun der oppgaven faktisk krever språkforståelse, resonnering eller generering av tekst.

Hva er en "harness"

Selve språkmodellen er bare motoren. Den kan ikke på egen hånd vite hvilke verktøy den har tilgang til, hvor mange ganger den skal prøve på nytt hvis noe feiler, eller når et menneske bør kobles inn før den går videre. Alt dette må bygges rundt modellen, og denne omkringliggende strukturen kalles gjerne en "harness".

En harness inkluderer typisk verktøyene modellen kan bruke, tydelig dokumentert slik at modellen forstår når og hvordan de skal brukes. Den inkluderer også grensene for hvor mange steg eller forsøk agenten får lov til å gjøre før den stopper og eskalerer til et menneske. Og den inkluderer logging, slik at det er mulig å gå tilbake og se nøyaktig hva agenten gjorde, i hvilken rekkefølge, og hvorfor et steg eventuelt feilet.

Uten en gjennomtenkt harness er selv en svært kompetent språkmodell upålitelig i produksjon. Med en god harness kan modellen håndtere sammensatte oppgaver innenfor trygge, kontrollerte rammer.

Pipelines og orchestratorer

Når en oppgave består av flere steg, som å hente informasjon, strukturere den, generere et utkast, og deretter kvalitetssikre resultatet, kalles denne kjeden av steg gjerne en pipeline. Hvert steg gjøres ferdig før neste starter, og hvert steg kan være enten deterministisk (kode) eller probabilistisk (språkmodell), alt etter hva oppgaven krever.

En orchestrator er komponenten som styrer denne flyten. Den holder oversikt over hvor langt en gitt oppgave har kommet, hva som skal skje neste, og hva som skal gjøres hvis noe feiler underveis. En viktig, men lite intuitiv detalj her: en robust orchestrator lagrer aldri fremdriften i eget minne. Alt om hvor langt en oppgave har kommet ligger i en database, slik at systemet kan fortsette akkurat der det slapp, selv om selve prosessen som kjørte forrige steg er avsluttet og borte. Dette er det som gjør systemer robuste mot tidsavbrudd og feil, i stedet for at hele oppgaven må startes på nytt fra scratch hver gang noe går galt underveis.

Anthropic beskriver flere konkrete mønstre for hvordan slike pipelines kan settes sammen, blant annet én der en sentral språkmodell bryter ned en oppgave og fordeler delene til flere "worker"-kall som løser hver sin del, og én der ett kall genererer et forslag mens et annet kall vurderer og gir tilbakemelding i en løkke før resultatet godkjennes.

Hvorfor dette skillet er viktig for deg som kunde

Når noen tilbyr deg en "AI-agent", er det verdt å spørre konkret: hvilke deler av dette er fast kode, og hvilke deler er overlatt til språkmodellen sin egen vurdering? Et system som lener seg tungt på at modellen skal "vite" ting den egentlig bare gjetter på, vil feile på uforutsigbare måter, og feilene er ofte vanskelige å oppdage før de har skjedd. Et system som er bygget med et bevisst skille mellom det som skal være forutsigbart og det som skal være fleksibelt, er langt mer robust, og det er langt lettere å feilsøke når noe likevel går galt.

Samme merkelapp, svært ulik verdi

Det er lett å tenke på "AI-agent" og "chatbot" som to faste kategorier, der alt som kalles det ene leverer omtrent samme type verdi. Slik er det ikke. Kompleksiteten i hvordan noe er bygget, og den kommersielle verdien det faktisk leverer, henger tett sammen, men de er ikke gitt av merkelappen alene.

En chatbot bygget på en systemprompt og enkel spørsmål-svar-logikk er raskt satt opp. Den krever lite domenekompetanse å bygge, fordi den i praksis bare sender brukerens spørsmål videre til en språkmodell og returnerer svaret. Problemet er at den arver alle svakhetene beskrevet tidligere i denne artikkelen: den kan ikke skille mellom det som bør være fast og pålitelig og det som krever resonnering, den har verken tilgang til riktig informasjon eller tydelige regler for hva den har lov til å gjøre, og den leverer derfor ofte overbevisende, men upresise svar. Enkel å bygge, men lav verdi i praksis.

En agent som faktisk er satt sammen med et bevisst skille mellom deterministisk og probabilistisk logikk, en gjennomtenkt harness, og tydelig kontrollerte verktøy og regler, er en helt annen sak å bygge. Det krever god forståelse av oppgaven den skal løse, av hvilken informasjon den trenger tilgang til, og av hvor grensene skal gå for hva den får lov til å gjøre selv. Dette tar mer tid og dypere kompetanse å få riktig, men det er også det som gjør at den faktisk leverer pålitelig verdi i produksjon, ikke bare i en demo.

Poenget er ikke at alt bør bygges så komplekst som mulig. Poenget er at "vi har en AI-agent" eller "vi har en chatbot" sier lite om hvor mye verdi løsningen faktisk gir. To systemer med samme merkelapp kan ligge langt fra hverandre i både kompleksitet og resultat, avhengig av hvor mye tanke som faktisk er lagt i hvordan de er satt sammen.

Slik bør en bedrift nærme seg dette i praksis

Start med det enkleste som faktisk løser oppgaven. Anthropic er selv tydelige på at man bør finne den enkleste løsningen som er mulig, og først øke kompleksiteten når det er nødvendig. Mange oppgaver trenger ikke en agent i det hele tatt, bare et enkelt, veldefinert kall til en språkmodell.

Skill deretter det som kan løses med kode fra det som faktisk krever resonnering. Alt som kan slås opp, beregnes eller valideres deterministisk, bør gjøres slik, ikke sendes til en språkmodell "for sikkerhets skyld".

Bygg en harness rundt kjernen før systemet settes i produksjon. Det betyr tydelig dokumenterte verktøy, satte grenser for antall forsøk, og et definert punkt der et menneske kobles inn dersom noe er usikkert eller kritisk.

Test i et isolert miljø før noe rulles ut mot ekte kunder eller ekte data, og sørg for at systemet logger nok til at du faktisk kan forstå hva som skjedde dersom noe feiler.

Avslutning

En AI-agent er ikke magi, og det er heller ikke én bestemt teknologi. Det er en måte å sette sammen fast, forutsigbar kode og en språkmodells fleksible resonnering på, der valget om hva som styres av hva, er den viktigste designbeslutningen i hele systemet. Jo tydeligere dette skillet er tenkt gjennom før noe bygges, jo mer pålitelig blir resultatet når det faktisk settes i drift.