Stardog har bygget et semantisk lag oven på Amazon Aurora og Amazon
Stardog har bygget et semantisk lag oven på Amazon Aurora og Amazon Redshift, der gør det muligt for en AI-agent at stille ét spørgsmål og få svar fra flere databaser samtidig, uden at data først skal flyttes eller kopieres. Agenten er bygget med Strands Agents, AWS' open source-framework til agentisk AI, og kører på Amazon Bedrock AgentCore, den administrerede driftsplatform, AWS lancerede tidligere i år til netop den slags opgaver.
Semantisk lag
Sådan binder det semantiske lag Aurora og Redshift sammen
Den tekniske kerne er en vidensgraf, der lægger sig oven på de eksisterende databaser som et fortolkningslag. I stedet for at flytte data fra Aurora og Redshift ind i et nyt, samlet lager, kortlægger Stardog begreberne på tværs af systemerne, kunde, ordre, produkt og lignende, til en fælles ontologi. Når agenten stiller et spørgsmål, oversætter laget spørgsmålet til de rigtige forespørgsler i hvert bagvedliggende system og samler svaret, før det går videre.
Det er en markant anden tilgang end den klassiske ETL-pipeline, hvor data først skal renses, transformeres og lægges i et data warehouse, før noget kan bruges. Her forbliver dataene, hvor de er. Det sparer den tid og risiko, der normalt følger med at bygge og vedligeholde synkroniseringsjob mellem systemer, og det betyder, at agenten altid arbejder på de aktuelle produktionsdata, ikke en forsinket kopi.
Agentens motor
Strands Agents og Bedrock AgentCore løser den drift, man ellers selv skulle bygge
Strands Agents er det lag, der giver agenten sin ræsonneringsevne: den fortolker en forespørgsel, vælger hvilke værktøjer og datakilder den skal bruge, og sammensætter et svar. Det, der gør opsætningen interessant, er, at agenten kører på Bedrock AgentCore i stedet for på infrastruktur, teamet selv skal drifte.
AgentCore løser de opgaver, der normalt spiser mest udviklertid i et agentprojekt: sessionshåndtering, hukommelse mellem kald, identitet og adgangsstyring til de systemer, agenten må tilgå, og skalering når belastningen stiger. Uden en administreret runtime skal et team selv bygge og vedligeholde den slags lag, før agenten overhovedet kan sættes i produktion. Med AgentCore er det driftsarbejde outsourcet til platformen, så udviklingen kan koncentrere sig om selve logikken i det semantiske lag og agentens evne til at stille de rigtige forespørgsler.
Fleksibel afvikling på EKS, ECS og Lambda giver frihed til at vælge infrastruktur
Opsætningen er ikke låst til én afviklingsmodel. Agenten kan køre på Amazon EKS for teams, der allerede har en Kubernetes-baseret infrastruktur, på Amazon ECS for en simplere container-drevet model, eller på AWS Lambda, hvor beregningen kun kører, når agenten faktisk bliver kaldt.
Den fleksibilitet betyder noget i praksis. Et team med svingende, uforudsigelig trafik kan vælge Lambda og kun betale for de faktiske kald. Et team med stabil, høj belastning og eksisterende driftsorganisation omkring Kubernetes kan i stedet vælge EKS uden at skulle bygge en helt ny driftsmodel op omkring agenten. Det semantiske lag og selve agentlogikken forbliver det samme, uanset hvilken afviklingsmodel man vælger, hvilket gør det til en arkitekturbeslutning, man kan tage uafhængigt af, hvordan man vil drifte resten af sin AWS-infrastruktur.
Det løser en konkret flaskehals for virksomheder med spredte produktionsdatabaser
Det er her, arkitekturen bliver relevant for danske virksomheder, der arbejder med agentisk AI i praksis. Vi ser gang på gang, at det største tidsspild i AI-projekter ikke ligger i selve modellen eller agentlogikken, men i at få adgang til data, der ligger spredt på tværs af flere systemer, ofte opbygget over år med forskellige teams, forskellige databaseteknologier og forskellige navngivningskonventioner for de samme forretningsbegreber.
Som principal konsulent hos AI Enterprise har jeg sammen med vores team drevet større AI-projekter fra problemafklaring til drift, og det mønster går igen: en agent, der skal svare på et forretningsspørgsmål, støder på en mur, fordi svaret kræver data fra et ordresystem og et kundesystem, der aldrig har talt sammen. Den klassiske løsning har været at bygge en ny, samlet datamodel, et projekt der ofte tager måneder og binder data fast i endnu et system, man skal vedligeholde.
Stardogs tilgang peger på et alternativ: byg fortolkningslaget, ikke endnu et datalager. For en virksomhed med flere produktionsdatabaser, der hver isoleret set fungerer fint, men aldrig er designet til at tale sammen, betyder det, at man kan sætte en agent i drift markant hurtigere, fordi man ikke først skal migrere eller konsolidere data, man blot skal beskrive, hvordan begreberne hænger sammen på tværs. Det er en anden slags investering end en traditionel data-platform, og for mange virksomheder en mere realistisk vej ind i agentisk AI, der rent faktisk kan arbejde på tværs af den infrastruktur, de allerede har.
En agent, der skal svare på et forretningsspørgsmål, støder på en mur, fordi svaret kræver data fra et ordresystem og et kundesystem, der aldrig har talt sammen.
Den klassiske løsning har været at bygge en ny, samlet datamodel, et
Den klassiske løsning har været at bygge en ny, samlet datamodel, et projekt der ofte tager måneder og binder data fast i endnu et system, man skal vedligeholde. Stardogs tilgang peger på et alternativ: byg fortolkningslaget, ikke endnu et datalager. For en virksomhed med flere produktionsdatabaser, der hver isoleret set fungerer fint, men aldrig er designet til at tale sammen, betyder det, at man kan sætte en agent i drift markant hurtigere, fordi man ikke først skal migrere eller konsolidere data, man blot skal beskrive, hvordan begreberne hænger sammen på tværs. Det er en anden slags investering end en traditionel data-platform, og for mange virksomheder en mere realistisk vej ind i agentisk AI, der rent faktisk kan arbejde på tværs af den infrastruktur, de allerede har. Samme mønster ses hos computer vision-agenter der forbinder til MCP, hvor et standardiseret lag løser en lignende adgangsudfordring.