Tænkt eksempel · Teknisk forklaringsmodel
Agentens anatomi
En leverandør skriver en mail på seks linjer. En vigtig komponent bliver tre dage forsinket, og det er sådan set hele beskeden.
Problemet er bare, at en forsinkelse på tre dage sjældent nøjes med at være tre dage. Den kan brede sig ind i produktionsplanen, videre til lageret og derfra over i en kundeleverance, indtil et menneske pludselig sidder med seks linjers mail og en halv arbejdsdag foran sig.
Hvilke ordrer bliver ramt? Findes komponenten et andet sted? Kan man bruge en anden? Kan produktionen flyttes? Og hvis den kan, hvem må så egentlig beslutte det?
Det er omtrent her, en AI-agent bliver interessant. Og det er også et meget godt sted at skille den ad.
Kredsløbet gentager sig, indtil modellen svarer.
- Input — Opgave — Kontekst
- Kontekst — Modelkald — Model
- Model — svarer — Output
- Model — kalder et tool — Validering
- Validering — Mandat — Handling
- Handling — Tool / MCP — Eksterne systemer
- Eksterne systemer — Ny kontekst — Kontekst
Peg på en del af tegningen for at se, hvad den gør.
Forestil dig først agenten helt uden pynt: ingen hukommelse, ingen værktøjer og ingen adgang til virksomhedens store samling af regler, dokumenter og gode intentioner. Bare en sprogmodel og en opgave:
En komponent bliver tre dage forsinket. Find ud af, hvad vi skal gøre.
Modellen kan læse mailen, forstå problemet og sandsynligvis også komme med nogle ganske fornuftige forslag. Men den ved ikke, hvilke ordrer komponenten indgår i, og det er en temmelig væsentlig mangel, hvis den skal gøre andet end at gætte kvalificeret.
Så den må spørge nogen, der ved det. I dette tilfælde er “nogen” et system.
Agenten laver et opslag i virksomhedens ordredata, men inden det bliver udført, bliver handlingen kontrolleret: Må agenten overhovedet se de oplysninger? Hvis svaret er ja, bliver opslaget sendt af sted, og systemet svarer.
Her sker noget vigtigt. For svaret er ikke slutningen på agentens arbejde. Det er bare noget nyt, den har fået at vide.
Resultatet bliver lagt tilbage i konteksten sammen med resten af sagen, og modellen får lov at se på problemet igen. Det er i grunden agentens bevægelse: Se. Vurder. Gør noget. Se igen.
Ikke én meget stor tanke, men en række mindre vurderinger, hvor resultatet af den ene bliver udgangspunktet for den næste.
Det ville selvfølgelig være bekvemt, hvis adgang til virksomhedens systemer var nok. Det er det ikke. Man bliver heller ikke indkøber af at få et login til indkøbssystemet.
Agenten mangler noget, der minder om faglig metode: en idé om, hvordan man plejer at gribe netop denne type arbejde an. Det kan blandt andet ligge i en skill, som beskriver fremgangsmåden: Find først de berørte ordrer. Undersøg konsekvenserne. Se efter alternativer. Kontroller, om alternativerne faktisk kan bruges. Saml derefter et forslag.
Både arbejdet og det, agenten producerer undervejs, kan blive gemt i et arbejds- og resultatlager. Det kan være mellemresultater, filer, analyser eller andre artefakter, som skal kunne bruges senere i samme opgave.
Nu opdager agenten eksempelvis, at den manglende komponent faktisk findes på et andet lager.
Så er problemet vel løst.
Det ville være dejligt.
Der findes nemlig en særlig type fejl, som både mennesker og maskiner er ret gode til: Man finder noget, der ser rigtigt ud, og stopper med at lede.
Lagersystemet fortæller ganske rigtigt, at komponenten ligger på en hylde 200 kilometer væk. Men et lagersystem ved først og fremmest noget om lagre; det ved ikke nødvendigvis særlig meget om, hvilke komponenter der er godkendt til hvilke maskiner.
Oplysningen “vi har en komponent” er derfor ikke en konklusion. Den er en observation.
Agenten tager observationen med tilbage i sit loop. Nu ved den mere end før, men netop fordi den ved mere, er der opstået et nyt spørgsmål: Kan komponenten faktisk bruges?
For at svare på det får agenten adgang til virksomhedens viden: manualer, retningslinjer, produktdokumentation og andre kilder, som ellers lever i PDF'er, mapper, SharePoint-sites og i hovedet på den kollega, alle plejer at spørge.
Den kan også have hukommelse. Ikke hukommelse på samme måde som et menneske, men muligheden for at tage relevante erfaringer og observationer fra tidligere arbejde med ind i en ny opgave.
Ingen af delene gør nødvendigvis selve sprogmodellen mere intelligent. De gør dens arbejde mindre tilfældigt, og det er i praksis en ret vigtig forskel.
Agenten slår nu komponenten op i den tekniske dokumentation. Den ligner den rigtige del, har næsten de samme specifikationer og står endda i samme produktfamilie.
Den er bare ikke godkendt til maskinen.
Så går sagen tilbage gennem kredsløbet igen: ny oplysning, ny vurdering, nyt forsøg.
Det kan virke omstændeligt, hvis man forestiller sig, at kunstig intelligens først og fremmest skal være en maskine, der svarer meget hurtigt. Men agentens styrke ligger ikke nødvendigvis i at nå hurtigere frem til det første plausible svar. Den skal kunne arbejde sig frem til et svar, der holder.
Efter nogle omgange finder agenten måske en brugbar løsning. Produktionen kan flyttes, en anden komponent kan fremskaffes, eller der kan bestilles en hasteforsendelse.
Nu ændrer problemet karakter.
Hidtil har agenten mest haft brug for at læse, forstå og slå op. Nu skal den måske også handle. Den har med andre ord fået brug for hænder, og hænder er en lidt farligere opfindelse.
Så længe agenten bare læste dokumenter og hentede data, kunne den tage fejl. Når den får adgang til at flytte en ordre, booke transport, skrive til leverandøren eller ændre en produktionsplan, som 40 mennesker møder ind til næste morgen, kan den også gøre noget ved sin fejltagelse.
Derfor er spørgsmålet ikke længere bare, hvad agenten kan gøre. Mindst lige så vigtigt er det, hvad den må gøre.
Det beskriver dens mandat.
Må den selv booke en hasteforsendelse under 5.000 kroner? Skal en produktionschef godkende en omlægning? Findes der situationer, hvor agenten ikke skal være kreativ eller forsøge sig frem, men ganske enkelt stoppe og sende sagen videre til et menneske?
Rundt om mandatet ligger dens guardrails: de tekniske og operationelle grænser, som ikke blot bør bero på, at modellen husker en instruktion. Agenten må måske ikke hente bestemte data, gennemføre bestemte handlinger uden godkendelse eller fortsætte, når særlige betingelser er opfyldt.
Det er let at blive optaget af, hvor meget handlekraft man kan give en agent. En stor del af det egentlige designarbejde består i at beslutte det modsatte: hvor dens handlekraft skal slutte.
Lad os sige, at agenten til sidst finder en løsning. En hasteforsendelse bliver bestilt, produktionen fortsætter, og kunden mærker ingenting.
Det er et godt resultat.
Men mandag morgen spørger økonomidirektøren, hvorfor virksomheden brugte 18.000 kroner på at flyve en komponent ind. Så er “det virkede som en god idé på daværende tidspunkt” ikke et særligt tilfredsstillende revisionsspor.
Når en agent arbejder på vegne af en virksomhed, skal dens handlinger derfor kunne rekonstrueres. Hvilke oplysninger brugte den? Hvilke systemer slog den op i? Hvad forsøgte den at gøre? Hvilke handlinger blev godkendt, hvilke blev stoppet, og hvad producerede den undervejs? I nogle systemer er det også relevant at kunne se, hvad forløbet kostede i model- og systemforbrug.
Derfor bliver agentens arbejde logget, så man bagefter kan følge dens færden.
Ikke fordi nogen nødvendigvis har lyst til at læse hele historien.
Men fordi nogen skal kunne.
Vi begyndte med en sprogmodel og gav den en opgave. Da den manglede oplysninger, gav vi den adgang til systemer. Da adgang til systemerne ikke var nok, beskrev vi den arbejdsform, den skulle følge, og gav den adgang til virksomhedens viden og relevante erfaringer.
Så begyndte den at handle, og dermed måtte vi også beslutte, hvad den havde lov til. Til sidst sørgede vi for, at arbejdet kunne gemmes og efterprøves.
Nu er tegningen næsten foldet helt ud.
Sprogmodellen sidder stadig et sted i midten, og den er vigtig. Men det er fristende at kigge på modellen og tro, at det er dér, agenten bor.
Det gør den ikke helt.
Agenten opstår snarere i forbindelserne mellem tingene: mellem det, den ved, og det, den mangler at vide; mellem en observation og det næste spørgsmål; mellem et system, den kan bruge, og en handling, den har lov til at udføre.
Og mellem en mail på seks linjer og den lange række af små beslutninger, der skal til, før nogen faktisk har løst problemet.
Det er mindre magisk end forestillingen om en digital medarbejder, der bare klarer det hele.
Til gengæld minder det lidt mere om arbejde.
Den samme tegning som øverst, med alt det på, de fire niveauer lagde til.
Kredsløbet gentager sig, indtil modellen svarer.
Fra modelkald til godkendt kontekst
Agentens anatomi forklarer løkken. Pluginarkitekturen viser den konkrete sikkerhedsgrænse omkring CSL’s interne CRM- og Legal-workflows.
Sådan arbejder vi med AI‑agenter i CSL