Sådan lader I agenter løse driftsopgaver med MCP

Det spørgsmål, de fleste ikke har stillet sig selv.
Hvilke opgaver er vi holdt op med at automatisere, fordi det aldrig betalte sig? Og er den beregning stadig rigtig?

Anders Kloster Nannerup
Senior Manager

I mange organisationer er der en kategori af manuelle driftsopgaver, der aldrig er blevet automatiseret – ikke fordi de er svære, men fordi klassiske integrationsprojekter var for dyre og for skrøbelige til at det kunne betale sig. Opgaverne bliver i stedet håndteret manuelt. De gentager sig. De binder tid. De skaber afhængighed af nøglepersoner. Og de er for sjældent synlige nok til, at nogen prioriterer at løse dem.

Det er den kalkule, som AI-agenter er ved at ændre.

Inden for det her område er en agent mest interessant når den kan udføre konkrete handlinger i organisationens systemer. Det kan være at oprette en bruger, ændre en rettighed, lukke en sag, starte en synkronisering, opdatere en pris på et produkt, eller hente en status på tværs af platforme. Her er Model Context Protocol - MCP - en vigtig brik. MCP gør det muligt at udstille de handlinger, agenten må bruge, på en sikker og kontrolleret måde.

Hvad er MCP?

MCP er en åben standard, der gør det muligt for AI-agenter og chatbots at udføre afgrænsede handlinger i virksomhedens systemer. I stedet for at bygge fulde integrationer udstiller man et sæt klart definerede handlinger eller tools – find en bruger, opdater en rettighed, hent en status. Agenten har kun adgang til det, der eksplicit er tilladt, og alle tool-kald logges og kontrolleres.

Den skjulte driftsomkostning

Et gennemgående mønster i drift- og platformteams er håndtering af brugere og rettigheder. Når en medarbejder skifter rolle, projekt eller team, skal adgange justeres på tværs af systemer – CMS, PIM, e-commerce platforme, supportværktøjer og interne administrationssystemer.

Opgaven er sjældent kompleks. Men den kræver en teknisk medarbejder, og den gentager sig.

En onboarding-proces der involverer tre systemer tager typisk en teknisk medarbejder 20–30 minutter. I en organisation med 50 onboardinger om måneden er det 25–37 timers teknisk tid. Hertil kommer fejl ved manuelle indtastninger, forsinkelser ved nøglepersonsfravær og den grundlæggende risiko ved rettigheder, der ikke er sat korrekt.

Det er altså en vedvarende friktion, der sjældent optræder på et dashboard, men er der hele tiden.

Med MCP kan denne type opgaver håndteres af en agent. For eksempel via Microsoft Teams, hvor en teknisk medarbejder kan interagere med agenten.

Prompten kunne være:

"Onboard denne nye medarbejder, han skal have adgang til system A, Y og Z."
"Samme rettigheder som David".

Agenten har derefter adgang til et begrænset sæt veldefinerede tools: find bruger, opdater rettighed, fjern adgang, log ændringen, som den anvender til at udføre opgaven. Resultatet er at den samme proces er nu gennemført på under to minutter. Agenten udfører kun de tool-kald(handlinger), den eksplicit er blevet autoriseret til at udføre, og intet andet – og rapporterer tilbage, når opgaven er fuldført.

Hvad kendetegner en løsning der holder i produktion

Mange MCP-løsninger fungerer i en prototype og fejler i drift. Tre principper adskiller de løsninger, der holder.

Handlinger bør svare til det, en erfaren medarbejder ville gøre.

Tool-kald, der direkte afspejler tekniske API-kald, tvinger agenten til at navigere i detaljer og rækkefølger, der er irrelevante for opgaven. Det øger fejlraten og gør løsningen dyr at vedligeholde.

Tools bør repræsentere klare forretningsbeslutninger med validering indbygget.

✅ + addAccessToSystem - afspejler direkte en beslutning, et menneske ville træffe, hvilket gør det nemt for agenten at vide, hvornår og hvorfor den skal anvendes.

✅ + onboardNewEmployee - repræsenterer en komplet, genkendelig forretningsopgave med en tydelig start og slutning.

❌ - UpdateUser - for vag til at være nyttig; agenten kan ikke pålideligt afgøre, hvornår dette er den rigtige handling, eller hvad den forventes at gøre.

Få og klart adskilte handlinger giver mere forudsigelig adfærd.

Overlappende handlinger er den stor kilde til ustabilitet. Hvis det ikke er åbenlyst, hvilken handling der gælder i en given situation, opfører agenten sig uforudsigeligt og bliver sværere at styre.

Et begrænset, entydigt handlingssæt er lettere at teste og vedligeholde.

✅ + revokeAccess - én handling, ét formål. Agenten vil altid vide, hvornår dette kald er det rigtige.

✅ +transferPermissionsFromUser - intentionen er eksplicit, og der er ingen anden handling, den kan forveksles med.

❌ -removeAccess / revokeAccess - to handlinger med identisk formål tvinger agenten til at vælge arbitrært. Over tid producerer dette inkonsistent adfærd, der er svær at fejlfinde.

❌ -updateUser (permissions: []) - at bruge en generisk opdateringshandling til at udtrykke en fjernelse skjuler intentionen. Agenten kan anvende den forkert, og det er næsten umuligt at auditere på en meningsfuld måde.

Agenter arbejder bedre med præcis information end med store mængder.

En agent, der præsenteres for for meget eller forkert kontekst, vil over tid producere dårligere resultater. Dette gælder både for et enkelt objekt - undgå unødvendige felter - og for lister. Undgå lister hvis du kan.

En god analogi er et menneske. Et menneske ville også have svært ved manuelt at gennemgå hundredvis af elementer på en liste, for at finde den rigtige. (uden værktøjer som Excel). Målrettede opslag fungerer langt bedre end brede forespørgsler.

Hvis yderligere detaljer nogle gange er nødvendige, er det bedre at eksponere et separat tool til dette formål frem for at inkludere det som standard.

✅ +getUserById - returnerer præcis det, der er nødvendigt for opgaven; ingen støj, ingen tvetydighed.

✅ +getActivePermissionsForUser - afgrænset til et specifikt formål, returnerer et rent og handlingsorienteret resultat.

❌ -getAllUsers - tvinger agenten til at gennemgå en liste for at finde det, den har brug for. Stor risiko for at agenten ikke finder et match, eller finder det forkerte.

❌ -getFullUserProfile - dumper alle tilgængelige attributter ind i konteksten, når kun ét eller to felter er relevante. Det forringer kvaliteten af agentens ræsonnement over tid og bruger unødig meget af det begrænsede kontekstvinude agenten har.

Governance stiller de samme krav

Governance stiller de samme krav til agenter som til menneskelige brugere: tydelig adgangsstyring, konsekvent logging og audit trail, og sikre stopmekanismer. Mangler disse mekanismer, er konsekvensen sjældent et dramatisk sammenbrud - men en gradvis erosion af sporbarhed og kontrol, der gør løsningen for usikker til produktion.

Hvornår er MCP ikke svaret.

MCP er ikke universelt. Det løser et specifikt problem – veldefinerede handlinger udført af AI – og det kræver, at opgaverne faktisk er veldefinerede.

MCP er typisk det forkerte valg, når:

Opgaven kræver kompleks forretningslogik og situationsvurdering. Hvis en erfaren medarbejder ville bruge tid på at vurdere konteksten, er MCP ikke den rigtige teknologi.

Datakvaliteten er lav. Agenter er afhængige af strukturerede, pålidelige data. Inkonsistente eller mangelfulde data fører til fejl, der er svære at opdage og rette.

Der ikke er klar ejerskab til at definere og vedligeholde handlingssættet. MCP-løsninger kræver løbende vedligeholdelse, efterhånden som systemer og processer ændrer sig. En person eller afdeling er nødt til at tage ejerskab over agenten og MCP serveren. Hvis ingen er ansvalig for at updatere og vedligeholde løsningen vil dens performance falde over tid.

Det er ikke argumenter for at undgå MCP – det er kriterier for at vurdere, hvornår en investering reelt giver mening.

Hvor starter man

MCP skaber hurtigst værdi på opgaver, der involverer manuelle trin på tværs af to eller flere systemer, udføres af tekniske medarbejdere selvom de ikke kræver teknisk vurdering, og sker med høj frekvens og lav forretningsmæssig risiko.

Brugeradministration, rettighedsjusteringer og statusopslag er gode eksempler. Tilføj 5% rabat på alle produkter i en bestemt ETIM klasse, eller luk alle supportsager der har været inaktive i 2 måneder er andre eksempler.

En typisk vej frem starter med at kortlægge de opgaver, organisationen holdt op med at automatisere - og vurdere, om kalkulen er ændret. Dernæst identificeres et afgrænset område med høj frekvens og lav risiko. Herefter defineres handlingssættet, den nødvendige governance sættes op, og løsningen sættes i drift.

Det er præcis det, vi kan hjælpe jer med – fra den indledende vurdering af hvilke processer der giver mening at automatisere (Advisory), til design og implementering af MCP-setup (Build), til drift og videreudvikling (Run). Ikke som en isoleret teknisk leverance, men som en del af en bredere indsats for at reducere den friktion, der kendetegner travl drift.