Amazon går målrettet efter context-laget. Under AWS Summit i New York annoncerede virksomheden tre komponenter til en samlet context intelligence-stack med AWS Context som midtpunktet. Ifølge AWS skal Context automatisk bygge en videngraf af eksisterende data, kombinere semantisk søgning med graf-reasoning og – det nye – blive klogere af, hvordan agenter faktisk bruger den. En reel forskydning i feltet. Ikke bare endnu en søgetjeneste.
Der er et men: AWS Context er annonceret som “coming soon” i AWS’ egen blog, ikke generelt tilgængelig endnu. Samtidig er Amazon S3 Annotations gjort generelt tilgængelig, og skill assets i AWS Glue Data Catalog er lanceret i preview, ifølge VentureBeat. Med andre ord: vejen er lagt, men ikke alt er i produktion i dag.
Hvad der er nyt – og hvorfor det betyder noget
Det mest markante er arkitektur-premissen: at en enterprise-videngraf ikke skal genopfindes manuelt, hver gang et nyt datasæt eller en ny regel dukker op. AWS siger, at grafen lærer over tid, hvilke kilder og forbindelser der giver korrekte svar i praksis. Som Swami Sivasubramanian formulerede det fra scenen i NYC: “Your agents now get smarter without you having to rebuild anything from scratch.” Kilden er VentureBeat, der refererer keynoten.
Hidtil har mange virksomheder håndbygget deres context-lag: specialscripts, semantiske mapper, en wiki ved siden af. Begge kilder – AWS’ blog og VentureBeat – beskriver markedet som præget af skræddersyede løsninger uden en standardiseret tjeneste, der også vedligeholder grafen løbende. Hvis AWS lykkes, kan time-to-value blive kortere, og mængden af manuel re-kuration falde betragteligt.
Hvad er AWS Context helt konkret
Ifølge AWS’ blog er Context en ny service, der automatisk kortlægger relationer på tværs af eksisterende data og bygger en videngraf med forretningsregler og domæneviden, som agenter kan spørge i runtime. Den kombinerer semantisk søgning med reasoning på grafniveau og stiller de afledte relationer til rådighed for agenter gennem agentiske søge-API’er.
Stacken består af tre lag, der føder hinanden: Amazon S3 Annotations (GA), hvor man kan vedhæfte rig forretningskontekst direkte til objekter; Glue Data Catalog skill assets (preview), der knytter domæneviden, runbooks og brugsmønstre til katalogiserede data; og så selve AWS Context, der syntetiserer det hele til en graf. VentureBeat og AWS beskriver det samstemmende – med mere markedsramme hos VentureBeat og mere API-nære detaljer hos AWS.
Hvordan grafen bliver til og forbedres
Her går AWS længere end klassisk datakatalog. Tjenesten inferrer relationer på tværs af tabeller, kolonner og kilder: hvad kolonner betyder, hvordan kilder hænger sammen, hvilke der er autoritative. Den foreslår forbindelser, business rules og begreber. Over tid lærer den, hvilke dele af grafen der leverer pålidelige svar, og hvilke kilder der oftest rammer rigtigt – en pointe VentureBeat fremhæver med reference til AWS’ udmeldinger.
Vigtigt: mennesker er stadig i loopet. Data stewards kan i AWS Management Console gennemgå de foreslåede relationer, promovere dem til produktion og vedhæfte definitioner og brugsregler. Det ligner en kurateret “promotion gate”, ikke fri leg. Der er en god grund – grafer kan tage fejl, især i domæner med homonymer, gamle forkortelser eller kolonner genbrugt til nye formål.
Sikkerhed, arverettigheder og compliance
VentureBeat skriver, at hver forespørgsel mod Context arver den kaldende brugers IAM- og Lake Formation-rettigheder. Det betyder, at agenters opslag i grafen er underlagt eksisterende identitets- og adgangsmodeller. Det lyder måske prosaisk, men i praksis er det afgørende: audit bliver muligt uden at opfinde en ny, parallel adgangskontrol til agentlaget.
AWS fremhæver også, at metadata udgives i Apache Iceberg-format på S3 Tables og kan forespørges via Athena, Redshift, Spark eller enhver Iceberg-kompatibel motor. Med andre ord: ikke en lukket datasilo. For drift og compliance peger det mod reviserbarhed, versionering med snapshots og muligheden for at sammenholde “før og efter” i grafens udvikling. Man forstår lettelsen hos en data steward, der har kæmpet med proprietære eksportformater.
Integration og interoperabilitet i den virkelige verden
Begge kilder peger på understøttelse af tredjepartskataloger, så kontekst fra systemer uden for AWS kan trækkes ind. Derudover kan agenter tilgå grafen via agentiske søge-API’er og MCP-kompatible værktøjer på tværs af Bedrock AgentCore, EKS eller andre MCP-rammer. Oversat til arkitektur: det er muligt at køre agentik på Kubernetes, holde modeller og tools adskilt, men stadig hente kontekst fra Context.
Mange virksomheder sidder med en blanding af Confluence-viden, ServiceNow-konfigurationer, on-prem databaser og partnerdata. Integrationerne bliver sjældent smukke. At AWS lover tredjepartsforbindelser er positivt – men friktionen afhænger af, hvilke kataloger der faktisk har first-class connectors, og hvor meget mapping man stadig selv skal lave.
Hvad ændrer sig i forhold til klassisk context-lag
Traditionelt har teams bygget et semantisk lag oven på datalagre: manuelt beskrevne entiteter, relationer og regler. Styrken: præcision og forklarbarhed. Svagheden: tung løbende vedligehold. AWS’ tilgang forskyder tyngden mod automatisk inferens, løbende læring fra brug og en promotion-proces i konsollen. Det kan forkorte POC’er, fordi man undgår at håndtegne halvdelen af grafen før første agent kan svare fornuftigt.
Men der følger usikkerheder med. En selvlærende graf kan skabe “spøgelsesrelationer”, hvis feedback-signalerne er svage eller biasede. Og hvem definerer “korrekt”, når forretningen skifter praksis? Her er kilderne tyndere: hverken AWS’ blog eller VentureBeat beskriver detaljeret, hvilke signaler, vægte eller kvalitetsmål algoritmerne bruger. Det bør adresseres før produktion.
Praktiske konsekvenser for implementering
En nøgtern første fase ligner et proof-of-value på et afgrænset domæne. Trin for trin: vælg 2–3 vigtige datasæt i S3 eller Lake Formation, annotér nøgleobjekter i S3 Annotations, tilføj et par skill assets i Glue (runbooks, kendte spørringsmønstre), lad Context bygge første udkast til grafen og kør agentforespørgsler gennem Bedrock AgentCore eller en MCP-kompatibel ramme. Mål præcisionen på svar og hvor ofte promotion-gaten ændrer grafen.
Roller betyder noget. En data steward bør have ret til at godkende relationer, vedhæfte forretningsdefinitioner og rulle tilbage ved fejl. Versionering af relationer bør være en disciplin helt for sig – navngivning, datoer, change notes. Test- og fallback-mønstre er ikke pynt: hvis en promotion gør svarene dårligere, skal man kunne skifte tilbage hurtigt, mens man undersøger hvorfor.
Drift og vedligehold – det usynlige arbejde
Selvlærende lyder driftfrit. Det er det sjældent. En graf, der opdaterer sig ud fra brug, kræver opsyn: metrikker for svarpræcision, dækning af kilder, fejlprocenter i promotion, andel relationer med forklarbarhed. Alarmer, når kilder bliver “dominante” uden at være autoritative. En månedlig reviewrunde, hvor stewards vurderer, om inference stadig rammer forretningslogikken, er ikke overkill.
Opsigtsfejl kommer. Forestil dig, at en fejlbehæftet datakilde midlertidigt ser “korrekt” ud, fordi den bliver brugt meget i en travl periode. Uden solide guardrails – og human-in-the-loop – kan grafer cementere midlertidige sandheder. Her er AWS’ promotion-gate et vigtigt værn. Men monitorering af de underliggende signaler er lige så vigtig. Det er ikke tydeligt i kilderne, hvilke dashboards AWS leverer ved launch.
Hvad der virker – og hvad der mangler
Styrkerne er synlige: mindre manuel re-kuration, kortere vej fra rå data til brugbar kontekst, arvet sikkerhedsmodel med IAM og Lake Formation, og metadata i Iceberg, der spiller pænt med eksisterende værktøjer. VentureBeat og AWS er enige her. Kombineret med S3 Annotations og Glue skill assets kan organisationer læsse mere viden ind, før agenten spørger. Det er klogt design.
Begrænsningerne er også klare: manglen på detaljer om algoritmerne bag læringen, fraværet af uafhængige benchmarks eller kundecases i kilderne, og usikkerhed om prisstrukturen. Desuden: domænespecifik kompleksitet (regler i pharma, finans, energi) kræver forklarbarhed og revision. Hvor meget manuel kuratering skal der til i praksis for at opfylde juridiske krav? Det er endnu åbent.
Konkurrence og lock-in
Markedet for context-laget er varmt. Snowflake taler om Horizon Context og Cortex Sense. Microsoft presser på med Fabric IQ og en semantisk ontologi. Redis og Pinecone løser andre stykker af kontekstproblemet – henholdsvis runtime-optimering og task-specifik kompilering af artefakter. AWS’ fordel er lav friktion for kunder, der allerede bor i S3, Glue og Lake Formation.
Men prisen for lav friktion kan være lock-in. Når grafen, promotion-workflows og agentintegrationer er bundet til AWS’ identitetsmodel, er det dyrere at flytte. Iceberg-publicering dæmper risikoen – data og metadata er ikke fanget bag proprietære API’er – men operationaliseringen (regler, promotion-historik, agenter) er stadig AWS-særheder. Ikke nødvendigvis en dealbreaker, men et bevidst valg.
Tre POC-hypoteser værd at teste
Kundeservice-assistent: Indlæs vidensartikler via S3 Annotations, link produktkoder til politikker i Glue skill assets, lad Context inferere relationer. KPI’er: first-contact resolution, gennemsnitlig svartid, andel svar med reference til autoritativ kilde. Succes, hvis FCR stiger 10–15 procent uden flere eskalationer.
Finansrapportering: Knyt kontoplan, rapportskabeloner og valideringsregler som skill assets, annotér historiske rapporter i S3. Mål: tid til kvartals-close, andel forespørgsler der svarer med korrekt periodisering. Succes, hvis tid til afstemning falder, og fejl i mapping mellem konti og rapportlinjer går ned.
IT-ops knowledge base – den tørre, men nyttige
Træk runbooks og hændelseslogs ind, lad Context lære mønstre for root cause. KPI’er: mean time to resolve, procent svar med præcis runbook-reference, andel fejldiagnoser. Succes, hvis MTTR falder 20 procent i pilotens skala. Ikke glamourøst, men det mærkes i driften.
Spørgsmål CTO\/CISO bør stille før en proof-of-value
- Hvordan versioneres og rulles grafrelationer tilbage ved regressions i svar?
- Hvilke signaler driver læringen – klik, løste opgaver, menneskelig feedback – og kan vægte justeres?
- Kan alle promotion- og forespørgselsaktiviteter auditeres på identitet og tid, også på tværs af agenter?
- Hvordan håndteres datakilder uden for AWS – hvilke tredjepartskataloger er officielt understøttet ved launch?
- Hvordan ser omkostningsmodellen ud ved skalering – lagring af metadata, forespørgsler, promotion-arbejdsgange?
- Hvilke SLO’er\/SLA’er gælder for konsistens mellem Iceberg-publicering og agenters runtime-synlighed?
- Kan grafens inference forklares maskinelt – “hvorfor” denne relation – til brug i regulerede domæner?
- Hvordan sandboxer man agenter, så deres feedback ikke forurener grafen på tværs af forretningsenheder?
Reporterens vurdering
Det her ligner et rigtigt skridt fra AWS. Ikke bare mere RAG med flere vektorer, men en satsning på et vedligeholdt, styrbart kontekstlag. Kombinationen af IAM\/Lake Formation-arv og Iceberg-metadata er velovervejet, og promotion-gaten er et sundt modspil til ordet “selvlærende”.
Konklusion – og de næste skridt
Start småt, men målbart. Vælg et domæne med tydelige, autoritative kilder. Annotér, tilføj få, men vigtige skill assets, lad Context bygge – og mål. Indfør promotion-gates og versionering fra dag ét. Hold øje med driftsmetrikker, især svarpræcision og auditbarhed. Hav en klar plan for, hvad der sker, hvis læringen løber skævt. Forskellen mærkes først, når man sidder med det i hænderne.
Kilder og næste skridt for dækning
Kilder i artiklen er AWS’ officielle blog om context intelligence (aws.amazon.com\/blogs\/machine-learning\/…) og VentureBeats rapport fra AWS Summit NYC. Begge kilder bekræfter tre produkter i en samlet stack, en kommende AWS Context-tjeneste, GA for S3 Annotations og preview for Glue skill assets, samt at forespørgsler arver IAM\/Lake Formation-rettigheder og at metadata udgives i Apache Iceberg.
Der mangler stadig uafhængige hands-on-tests, benchmarks af inference-kvalitet i enterprise-scenarier, detaljer om læringsalgoritmerne og prisbilledet. Næste journalistiske skridt bør være interview med produktteamet bag Context, tidlige kundepiloter og en praktisk test, hvor grafens versionering og rollback bliver presset i en kontrolleret fejl-øvelse.
