En AI-agent er kun så pålidelig som de dokumenter, den henter sin
En AI-agent er kun så pålidelig som de dokumenter, den henter sin viden fra. Når flere agenter i samme virksomhed hver bygger deres egen adgang til virksomhedens data, ender man ikke med flere kanaler til den samme sandhed, men med flere forskellige sandheder. Det er den fælde, mange virksomheder er ved at gå i lige nu, og den bliver dyrere for hver agent, der sættes i drift.
Hver agent bygger sin egen vej ind i virksomhedens dokumenter
Når en organisation ruller den første AI-agent ud, virker det naturligt at give agenten sin egen pipeline til dokumenter, wikier og databaser. Det løser problemet hurtigt, og resultatet ser fornuftigt ud i starten. Problemet opstår, når agent nummer to, tre og fire kommer til. Hver ny agent bygger igen sin egen forbindelse til de samme kildesystemer, ofte med sin egen fortolkning af, hvilke dokumenter der er gyldige, hvilke der er forældede, og hvordan data skal struktureres før brug.
Resultatet er, at to agenter kan svare forskelligt på det samme spørgsmål, fordi de trækker på forskellige udgaver af virksomhedens viden. Den ene agent har måske indekseret en gammel prisliste, mens den anden bruger den aktuelle. Ingen har gjort noget forkert isoleret set, men samlet set underminerer det tilliden til, at agenterne overhovedet kan stoles på. Kompleksiteten vokser desuden ikke lineært med antallet af agenter, men eksponentielt, fordi hver ny pipeline lægger endnu et lag duplikeret arbejde oven på de eksisterende.
Et fælles vidensstyringslag erstatter det duplikerede arbejde
Løsningen er ikke flere pipelines, men et fælles lag, som alle agenter deler adgang til. Et sådant lag har typisk fire funktioner, der hver løser en del af problemet. Først en indtagsfunktion, der samler dokumenter fra de forskellige kildesystemer ét sted, så data ikke skal hentes forfra for hver agent. Dernæst en normaliseringsfunktion, der sikrer, at forskellige formater, versioner og strukturer bliver ensrettet, før noget bruges i en agent-samtale.
Det tredje lag er adgangsstyring: hvilke agenter må se hvilke data, og hvordan sikres det, at følsomme oplysninger ikke lækker på tværs af afdelinger, der ikke burde dele dem. Det fjerde lag er selve genfindingen, altså hvordan en agent finder det relevante uddrag af et dokument, når den skal svare på et konkret spørgsmål. Når disse fire funktioner ligger centralt i stedet for at blive genopfundet af hver agent, forsvinder både duplikeringen og den indbyggede risiko for, at agenter arbejder ud fra forskellige versioner af sandheden.
Fra isoleret context engineering til fælles infrastruktur
De seneste år har mange teams arbejdet med context engineering på agentniveau, altså at finjustere, hvilke informationer en enkelt agent får med i sin kontekst, for at forbedre svarkvaliteten. Det arbejde har værdi, men det løser kun halvdelen af problemet, hvis det foregår isoleret for hver agent. Man kan optimere konteksten for én agent perfekt og stadig have et fundamentalt problem, hvis den underliggende dokumentbase er inkonsistent på tværs af organisationen.
Jeg bygger og driver selv agentdriften hos Agent Enterprise, og der kører flere agenter side om side på den samme dokumentbase. Det tog mig ikke lang tid at opdage, at to af dem svarede forskelligt på et spørgsmål om et af vores egne produkter, fordi den ene havde indekseret en ældre version af en produktside og den anden en nyere. Jeg har ikke et pænt tal for, hvor tit den slags sker på tværs af virksomheder generelt, men jeg brugte selv en eftermiddag på at spore fejlen tilbage til, hvilken pipeline der havde hentet hvad. Den tekniske løsning virker først, når den organisatoriske del følger med: fælles ejerskab af dokumentkvalitet, ét sted at rette fejl, og en klar proces for, hvornår data er forældede. Uden det bliver context engineering en optimering af symptomer frem for årsagen.
Den naturlige udvikling er derfor at flytte arbejdet et niveau op, fra at optimere den enkelte agents kontekst til at bygge en fælles vidensplatform, som alle nuværende og fremtidige agenter trækker på. Det betyder ikke, at context engineering bliver overflødigt, men at det bliver langt mere effektivt, når det arbejder ovenpå ren, konsistent data i stedet for at kompensere for rod i kildesystemerne.
Man kan optimere konteksten for én agent perfekt og stadig have et fundamentalt problem, hvis den underliggende dokumentbase er inkonsistent på tværs af organisationen.
Konsekvensen for virksomheder med flere agenter i drift
For virksomheder, der allerede har flere AI-agenter kørende, er den vigtigste øvelse at kortlægge, hvor mange separate pipelines der reelt eksisterer, og hvor de overlapper. Ofte er overlappet større, end nogen i organisationen er klar over, fordi hver afdeling har bygget sin løsning uden at kende de andres. Det er her, gevinsten ved konsolidering er størst, både i form af reduceret vedligeholdelse og i form af mere konsistente svar på tværs af agenterne.
For virksomheder, der endnu kun har én eller to agenter i drift, er det billigste tidspunkt at etablere det fælles lag netop nu, før flere agenter og flere afdelinger har bygget sig fast i deres egne løsninger. Jo flere pipelines der allerede eksisterer, jo dyrere og mere politisk kompliceret bliver konsolideringen bagefter. Den virksomhed, der tænker vidensstyring som infrastruktur fra start, undgår at skulle rydde op i et voksende dokumentkaos, mens flere og flere forretningsprocesser afhænger af, at agenterne svarer rigtigt.