nOps FinOps-agent: 75% hurtigere med Bedrock

Den oprindelige version af Clara kørte på en Kubernetes-klynge, som nOps selv designede, skalerede og overvågede. Det er et arbejde, mange virksomheder kender: containerorkestrering, autoscaling-regler, netværkspolitikker, patching og incident-håndtering, alt sammen før man overhovedet kan tale om agentens faktiske funktionalitet. Med AgentCore overtager AWS runtime-laget, herunder skalering, isolation mellem sessioner og den løbende drift af selve agent-miljøet. Teamet bag Clara kunne derfor bruge langt mere af deres tid på selve FinOps-logikken, altså på at gøre agenten bedre til at analysere cloud-omkostninger, i stedet for at holde serverne kørende.

Det er en forskel, der ofte overses, når man sammenligner agent-platforme. Den tekniske kompleksitet i at bygge en agent, der kan ræsonnere over data, er sjældent det, der forsinker et projekt mest. Det er driften omkring den.

Den konkrete tidsbesparelse, nOps rapporterer, cirka 75 procent kortere vej til produktion, stammer altså ikke fra en smartere AI-model. Den stammer fra at fjerne det administrative og infrastrukturelle overhead, der normalt spiser måneder af enhver agentudrulning. For virksomheder, der overvejer at bygge egne AI-agenter, er det en vigtig skelnen: spørgsmålet er sjældent, om modellen er god nok. Det er, om organisationen har kapaciteten til at drifte infrastrukturen omkring den, måned efter måned, mens agenten er i produktion.

Det gælder især for FinOps-agenter som Clara, der arbejder kontinuerligt med skiftende cloud-priser, forbrugsmønstre og budgetgrænser. En agent, der overvåger omkostninger, skal selv være billig og stabil at drive. Ellers underminerer den sit eget formål.

Det interessante ved skiftet er, hvad nOps valgte at beholde. Governance omkring Claras data kører fortsat via Databricks Lakehouse Metric Views, som definerer, hvilke metrikker agenten må trække på, og hvordan de er struktureret. Det betyder, at teamet flyttede driftslaget, men lod datastyringen stå urørt. Det er en fornuftig arkitekturbeslutning: infrastruktur og governance er to forskellige problemer, og de behøver ikke løses af samme leverandør eller flyttes samtidig.

For virksomheder, der planlægger egne agent-projekter, er pointen overførbar. Man kan godt outsource driften af agent-runtime til en managed platform som AgentCore, uden at det kræver, at man også opgiver kontrollen over, hvilke data agenten må se og hvordan de er defineret. De to lag kan og bør designes uafhængigt af hinanden.

Vi ser i vores rådgivning ofte, at netop dette driftsoverhead er den reelle flaskehals, når danske virksomheder skal have agenter fra prototype til produktion. Kim Like, principal konsulent hos AI Enterprise, driver sammen med sit team større AI-projekter fra problemafklaring og planlægning til implementering og drift, og mønstret går igen på tværs af projekter.

For danske virksomheder, der allerede har agenter i drift eller overvejer at bygge dem, er nOps-casen et konkret argument for systematisk evaluering af agenter i produktion og for at adskille beslutningen om agent-logik fra beslutningen om, hvem der drifter runtime-laget. Managed platforme som AgentCore fjerner ikke behovet for solid governance, men de kan fjerne en stor del af det arbejde, der ellers forsinker produktionssætning uden at tilføre reel værdi til selve agenten. Det er en overvejelse, der er lige så relevant for en FinOps-agent som for enhver anden agent, der skal køre stabilt, dag ind og dag ud, i en virksomheds drift.