AgentCore MCP-servere til business

Model Context Protocol (MCP) er blevet den de facto standard for, hvordan en AI-agent taler med eksterne datakilder og værktøjer. I stedet for at bygge en skræddersyet integration for hvert system agenten skal kunne læse fra, eksponerer man systemet som en MCP-server med et fast sæt kapabiliteter, som agenten kan forespørge på en ensartet måde.

AgentCore bygger videre på det princip ved at gøre selve opsætningen af disse konnektorer til en konfigurationsopgave frem for en udviklingsopgave. Man peger agenten på de datakilder, der skal være tilgængelige, definerer hvilke operationer der er tilladt, og AgentCore håndterer resten af kommunikationslaget. For en virksomhed med flere systemer i drift, et CRM, et ERP-system, en datawarehouse, betyder det, at man kan udvide en agents rækkevidde uden at genopbygge integrationslaget hver gang et nyt system skal med.

Det er en markant anden arbejdsgang end den, mange teams har måttet igennem de seneste par år, hvor hver ny datakilde krævede sin egen custom-kode og sin egen fejlhåndtering. Med en konnektor-baseret model bliver den slags arbejde standardiseret, og det er netop den standardisering, der gør det realistisk at drifte flere agenter på tværs af en virksomheds datalandskab uden at teamet drukner i vedligehold.

Det mest interessante ved AgentCores tilgang er ikke selve konnektorerne, men hvordan adgangskontrol håndteres. Når en agent forespørger data gennem en MCP-server, videreføres brugerens egne rettigheder, ikke en generisk agent-konto med bred adgang til alt.

Det lyder som en detalje, men det er den detalje, der afgør om en BI-agent kan gå i produktion i en virksomhed med reelle datasikkerhedskrav. En agent med sin egen brede serviceadgang er et sikkerhedsproblem i sig selv: den bliver et enkelt angrebspunkt med adgang til langt mere data, end nogen enkelt medarbejder normalt ville have. Når adgangen i stedet er bundet til den bruger, der stiller spørgsmålet, arver agenten præcis de begrænsninger, brugeren allerede har i de underliggende systemer. En sælger, der spørger agenten om kundedata, får kun svar inden for det, sælgeren selv har adgang til. En økonomimedarbejder, der spørger om finansielle nøgletal, får en anden afgrænsning.

Det betyder også, at governance-arbejdet ikke skal duplikeres. Virksomheder har typisk allerede investeret år i at få adgangsstyring rigtigt i deres kildesystemer, roller, grupper, rettighedshierarkier. Når agenten arver den struktur i stedet for at kræve sit eget parallelle regelsæt, undgår man den situation, hvor et sikkerhedshul i agentlaget underminerer arbejdet, der allerede er gjort andre steder i organisationen.

Den praktiske konsekvens af de foregående elementer, konnektorer, brugerbunden adgang og persistent hukommelse, er, at en medarbejder kan stille ét spørgsmål på almindeligt sprog og få et svar, der trækker fra flere systemer samtidig. "Hvordan udviklede vores marginer sig i sidste kvartal for de kunder, der også har en åben supportsag" er et spørgsmål, der normalt kræver at nogen manuelt kobler data fra økonomisystemet og supportsystemet sammen. Med en agent, der har adgang til begge via MCP, kan svaret komme direkte.

Det er den type spørgsmål, der historisk har krævet enten en dedikeret BI-analytiker eller et forudbygget dashboard, som nogen skulle have tænkt sig at bygge på forhånd. Værdien ved en agentisk tilgang er, at spørgsmålet ikke behøver at være forudset. Man behøver ikke bygge en rapport for hver tænkelig krydsning af data, agenten kan selv navigere til de relevante kilder og sammensætte svaret, når spørgsmålet stilles.

Det stiller til gengæld krav til, hvordan dataene i de underliggende systemer er struktureret og navngivet. En agent, der skal forstå, at "marginer" i økonomisystemet og "kunder" i supportsystemet refererer til de samme forretningsenheder, er afhængig af, at den underliggende datamodel giver den mulighed for at lave den kobling korrekt. Det er ikke noget MCP-laget løser i sig selv, det er stadig et modenhedsspørgsmål for den enkelte virksomheds datainfrastruktur.

Der er stor forskel på en agent, der kan svare flot på et forberedt spørgsmål i et møde, og en agent, der kan stå i produktion og besvare vilkårlige spørgsmål fra hele organisationen dag efter dag. Den forskel handler sjældent om selve sprogmodellen, den handler om integrationslaget, adgangsstyringen og driftssikkerheden omkring den.

Vi arbejder med større AI-projekter for danske virksomheder fra problemafklaring til drift, og det mønster går igen: den tekniske model er sjældent flaskehalsen. Det er evnen til at koble agenten sikkert til de systemer, der allerede findes, uden at skabe et parallelt adgangslag, der senere bliver et governance-problem. En arkitektur som AgentCores, hvor adgang følger brugeren, hukommelsen er persistent, og konnektorer er konfiguration frem for kode, adresserer netop det, der historisk har gjort BI-agenter svære at drifte i praksis.

For en teknisk beslutningstager, der overvejer at sætte en agentisk BI-løsning i drift, er den relevante øvelse derfor ikke kun at vurdere, om modellen kan svare rigtigt. Det er at kortlægge, hvilke datakilder agenten reelt skal have adgang til, hvordan adgangsstyringen i de kilder allerede er struktureret, og om den strukturen er ren nok til, at en agent kan arve den direkte. Det er det arbejde, der afgør, om en agent bliver en produktionsklar del af forretningen eller forbliver en demo, ingen tør sætte i drift.