Mere end halvdelen af de virksomheder, der de seneste seks måneder har kørt AI‑agenter, har set et svar leveret med fuld sikkerhed – men med en forkert konklusion. En ny VB Pulse‑undersøgelse, refereret af VentureBeat, peger på kontekst som den primære årsag. 57% har direkte kunnet spore fejlen til manglende eller modstridende forretningskontekst, og 31% siger, det skete mere end én gang i perioden. I drift er det alt andet end en bagatel.
Hvad undersøgelsen faktisk viser
VB Pulse‑undersøgelsen fra juni 2026, som VentureBeat gennemgår, bygger på svar fra 101 kvalificerede virksomheder med over 100 ansatte. Det er ikke et stort panel, men målgruppen er relevant. Tallene tegner et tydeligt mønster: 57% har oplevet selvsikre men forkerte agentsvar på grund af kontekst, og 31% oplevede gentagelser. Kilden fremhæver, at problemet ikke primært er modellen – det er den kontekst, agenterne får.
Metoden har begrænsninger: Der mangler detaljer om branche, geografi og agenttyper, og det påvirker generaliserbarheden. Som temperaturmåling er signalet dog klart: Kører man agenter uden et styret kontekstlag, øger man risikoen for fejl, der lyder rigtige uden at være det.
Den korte version af problemet
Det typiske set‑up: dokumentretrieval som standard, embeddings, en vektorbase – og afsted. Ifølge undersøgelsen er retrieval over dokumenter den mest udbredte måde at give forretningskontekst på for 38% af virksomhederne. Det holder, indtil det ikke gør: forældede PDF’er, uopdagede noter, afdelingsvise forskelle i KPI‑definitioner – og en agent, der svarer overbevisende ud fra noget, der var rigtigt sidste kvartal.
Hvad et agentisk kontekstlag egentlig er
VentureBeats gennemgang beskriver det som en styret, delt model af, hvad forretningsdata betyder. Bygget én gang, brugt på tværs. Pointen er, at agenter ikke selv skal udlede betydningen af salg, churn, CAC og andre nøglebegreber hver gang. De skal spørge et autoritativt lag – et lag, der også husker, hvor viden kommer fra, og hvornår det sidst blev opdateret.
Adoptionen halter
VentureBeat refererer et nøgletal fra undersøgelsen: 25% kører et agentisk kontekstlag i produktion. 34% bygger. 41% er ikke startet. Lovende, fordi idéen vinder indpas. Bekymrende, fordi tre ud af fire endnu ikke har en styret vej til at reducere fejl, de selv rapporterer.
Leverandørerne trækker i hver sin retning
VentureBeat oplister flere tilgange. Der er ikke én vinderarkitektur. DataHub bruger katalogmetadata og historik fra analytikeres forespørgsler som videnkilde og holder det levende frem for en statisk wiki. Microsoft Fabric IQ bygger en forretningsontologi, der kan spørges af enhver agent over MCP. Couchbase vil have agenthukommelse og retrieval tæt på kanten – ned i den operationelle database frem for et separat søgelag.
Pinecone Nexus kompilerer struktur ned i metadata før kørselstid og prioriterer forbygget logik. Snowflake kører to lag: Horizon Context til kundestyrede definitioner og Cortex Sense til kontekst, platformen selv udleder. Oracle går en anden vej med Unified Memory Core ved at folde vektor, graf og relationel data ind i én transaktionel motor for at undgå et separat synklag. Google lader Knowledge Catalog udlede semantisk kontekst fra brugsdata automatisk. VentureBeat noterer også, at AWS har en konteksttjeneste, der lærer af agenters faktiske brug. Samlet billede ifølge artiklen: divergens, ikke konvergens.
En konkret reference fra AWS
For de teknisk nysgerrige viser en AWS‑vejledning, hvordan man bygger et semantisk lag med Stardog oven på Amazon Aurora og Amazon Redshift og kører en agent på Amazon Bedrock AgentCore, der spørger ind i laget. Her fungerer Stardog som et meningslag over eksisterende databaser, så man kan besvare kunde‑360‑spørgsmål uden forudgående ETL.
Vejledningen beskriver også, at AgentCore pakker autentifikation, hosting og værktøjskredentialer i en managed service. Det gør start let, men indebærer også valg, man senere skal leve med. Der er ingen objektive benchmarks i posten, og den dækker ikke skalerbarhed eller omkostninger. Som referencearkitektur viser den dog, hvordan et styret kontekstlag kan udstilles til agenter via et kontrolleret API.
Hvorfor retrieval alene falder igennem i praksis
Dokumentretrieval er god til bred viden og dårlig til begreber, der skal tolkes ens hver gang. En KPI‑definition tåler ikke fri fortolkning, hvis svar skal være konsistente på tværs af teams. Dertil kommer driftens praktiske faldgruber: refreshrater, versionsstier, slettede dokumenter og noget så banalt som ikke‑unikke filnavne. Eller to næsten ens guides i Confluence, hvor kun den ene indekseres korrekt.
Konsekvensen mærkes, når en leder står med et forkert tal i et direktionsmøde, leveret med sikker stemme, fordi en agent svarede ud fra en gammel metrik. Efter sådan en hændelse afløses “plug‑and‑play” hurtigt af et mere grundlæggende spørgsmål: Hvem ejer sandheden?
Praktiske implementeringsspørgsmål
Et agentisk kontekstlag kræver styr på dataejerkæden. Hvem vedligeholder ontologien? Hvem versionerer metrikker? Hvem godkender ændringer? Uden klart ejerskab bliver laget hurtigt forældet. Derudover skal der være freshness‑regler: hvor gamle må kilder være, før agenten advarer eller falder tilbage til human‑in‑loop.
Provenance og audit‑trails er ikke pynt. De gør det muligt at spole et svar tilbage til præcise definitioner og dataversioner. Dertil real‑time monitorering og sanity‑checks – fx en simpel kontrol af, om en nøglemetrik pludselig hopper uden for forventet interval. Små greb, der forhindrer stille fejl i at glide igennem.
Drift og support i hverdagen
Et kontekstlag ændrer roller. Data stewards bliver synlige. Platformteams får nye SLO’er – ikke kun for latency og tilgængelighed, men også for kontekstkvalitet. Supportflowet skal fange “stille fejl”, hvor agenten producerer svar uden tekniske alarmer, men med forkert betydning. Det kræver et eskaleringsflow, hvor produktteams kan parkere en definition, rulle tilbage til en forrige version og genkøre kritiske svar.
Risici og usikkerheder
Leverandørlandskabet er fragmenteret, og Ingen arkitektur har vundet, som VentureBeat beskriver. Det skaber integrationsrisiko og potentielt lock‑in, især når kontekstlaget kobles tæt med hosting og auth som i AgentCore‑tilgangen. Der er også et velkendt tradeoff mellem performance og konsistens: Et stærkt styret lag kan give ekstra hop og latency. Det er ofte fint til beslutningsstøtte, men kan være en udfordring i kundesupport, der skal svare på få sekunder.
Spørgsmålet om “hvem ejer sandheden” kan ingen platform løse alene. Uden en intern beslutning om, hvor autoritative definitioner bor, og hvordan de ændres, ender laget som en pæn facade oven på den samme rod – og bliver forældet igen, blot dyrere.
Hvornår giver det mening at investere
Et kontekstlag betaler sig, når agenter skal løse opgaver, hvor databetydning skal være ens på tværs af brugere og tid. Tegn på, at tiden er inde: gentagne selvsikre fejl, KPI’er med komplekse eller ofte ændrede definitioner, mange retrieval‑misses i logs og et stigende behov for revisionsspor. Hvis agenter primært svarer på generiske brugervejledninger, er gevinsten mindre. Vent – men læg en vej ud.
Hvad man bør kigge efter hos leverandører
Bed om gennemsigtighed i traceability: Hvor hurtigt kan man fra et agentsvar gå til fuld provenance‑kæde? Sekunder, ikke timer. Spørg til latency under belastning – ikke kun P50, men også P95. Og hvordan ser exit ud? Kan man løfte ontologien ud uden at nedlægge hele platformen? VentureBeats billede af divergerende tilgange gør det ekstra vigtigt.
En realistisk handlingsplan
Kort sigte (0–6 uger): Kortlæg de 10–15 mest stillede forretningsspørgsmål, og udpeg metrikkerne, der driver svarene. Indfør simpel versionering af metrikdefinitioner i et delt repo. Sæt freshness‑alarmer på kilder med høj ændringsrate. Log agentforespørgsler, og mærk dem, der ikke kan besvares fra et styret lag.
Mellemlang sigte (1–3 måneder): Vælg en kontekstarkitektur, og implementer et første snit af en delt ontologi med provenance og API‑adgang. Læg en human‑in‑loop‑bane for højrisiko‑svar. Etabler SLO’er for kontekstkvalitet og sporbarhed. Mål tre KPI’er i piloten: reduktion i selvsikre fejl, tid til fuld traceability pr. svar og andelen af agent‑queries, der besvares fra det styrede lag.
Hvor det efterlader branchen nu
Der mangler uafhængige studier, der sammenligner arkitekturer på nøjagtighed, latency og vedligeholdelse. VB Pulse‑undersøgelsen er et øjebliksbillede med 101 virksomheder. AWS‑eksemplet er leverandørdrevet og uden benchmarks. Billedet er ikke komplet – men på tværs af kilderne er signalet konsistent: Problemet er konteksten, ikke modellen.
