AI-agenter og MCP-servere: sådan kobler I sprogmodeller til de systemer, I allerede kører

Demoerne virker altid. Piloten, der opsummerede jeres dokumentation, var imponerende, prototypen, der besvarede supportspørgsmål, så klar ud, og så mødte den det rigtige CRM, den rigtige rettighedsmodel og de rigtige data og var pludselig ikke klar længere.

Det spring er arbejdet. Ikke modellen (modellen er den nemme del efterhånden), men alt det, der ligger mellem en sprogmodel og et system, der har holdninger til autentificering, rate limits, tenancy og hvem der må se hvad.

Det, vi bygger

MCP-servere til jeres interne systemer

Model Context Protocol er en åben standard for at eksponere værktøjer og data til AI-assistenter på en måde, der er ens på tværs af klienter. Den er blevet det praktiske svar på "hvordan lader vi en assistent bruge vores systemer uden at skrive en særskilt integration til hver enkelt assistent".

Vi bygger MCP-servere til produktion oven på det, forretningen faktisk kører på: jeres CRM, jeres sagssystem, jeres data warehouse, jeres interne API'er, jeres dokumentarkiv, jeres ERP. Ikke en demoserver med et hardkodet token: en med ordentlig autentificering, autorisation pr. bruger der respekterer de rettigheder, jeres systemer allerede håndhæver, multi-tenant-isolation, rate limiting, struktureret logning og en fejlflade, der fortæller modellen noget brugbart, når et kald fejler.

Skræddersyede AI-agenter og assistenter

Agenter, der løser en opgave hele vejen: triagerer en indgående kø, afstemmer to systemer der er uenige, skriver første udkast til et dokument som et menneske derefter godkender, eller kører en research-opgave på tværs af interne og eksterne kilder. Vi bygger dem med de kedelige dele inkluderet: genforsøg, timeouts, omkostningslofter, idempotens på alt der skriver, og et menneskeligt godkendelsestrin overalt hvor en handling er svær at fortryde.

Søgning i jeres eget indhold

RAG, gjort ordentligt: dokumentindlæsning og opdeling i chunks der respekterer struktur frem for tegnantal, embeddings og vektorsøgning, hybrid søgning med både nøgleord og semantik, fordi ren vektorsøgning misser eksakte match, reranking, og kildehenvisninger så et svar kan efterprøves. Plus den uglamourøse halvdel: at holde indekset opdateret, når de underliggende dokumenter ændrer sig, og at overholde adgangskontrollen, så søgningen aldrig viser et dokument, brugeren ikke selv kunne åbne.

Automatisering af arbejdsgange og backoffice

Ikke alt har brug for en agent. En stor del af det, virksomheder vil have ud af AI, er klassificering, udtræk og routing: læse en indgående mail og afgøre hvad den er, hive strukturerede data ud af et ustruktureret dokument, matche en beskrivelse mod en katalogpost. Det er billigere, mere pålideligt og lettere at evaluere end en agent, og når det er det rigtige svar, bygger vi det i stedet.

Evaluering, observability og guardrails

En AI-funktion uden evaluering er en funktion, ingen kan forbedre. Vi bygger testsæt ud fra jeres virkelige sager, måler mod dem ved hver ændring, tracer hvert kald med input, værktøjsbrug, latency og pris, og sætter grænser op, før en løbsk løkke finder jeres API-regning. Prompt injection er en reel risiko i samme øjeblik en agent læser indhold, den ikke kan stole på, og samtidig kan handle. Vi designer værktøjsgrænsen, så et ondsindet dokument ikke kan blive til en destruktiv handling.

Sådan arbejder vi med modeludbyderne

Vi er ikke bundet til én. Vi bygger mod Anthropics Claude-modeller, OpenAI, Google og open-weight-modeller, der kører på jeres egen infrastruktur, og vi designer integrationen, så modellen er en udskiftelig komponent. Hvilken I bør bruge afhænger af opgaven, den latency I har brug for, prisen pr. kald ved jeres volumen og (i stigende grad den afgørende faktor i Europa), hvor dataene må ligge.

For kunder med krav til datas placering deployer vi i EU-regioner eller kører selvhostet inferens på jeres eget hardware, og vi siger ærligt, hvor det koster jer noget på kapaciteten.

Hvad det ikke er

Vi er ikke et AI-strategihus. Vi holder ikke workshops om det transformative potentiale i noget som helst.

Vi bygger heller ikke en agent til et problem, der ikke har brug for en. En betragtelig del af de AI-projekter, vi bliver spurgt om, løses bedre med en veldefineret API-integration, et søgeindeks eller ved at rette det datakvalitetsproblem, der ligger nedenunder. At anbefale det koster os en større opgave og sparer jer for et system, I skulle vedligeholde.

Hvor det typisk betaler sig

Intern viden, der teknisk set er tilgængelig og praktisk set er uopnåelig: tusindvis af dokumenter spredt over en wiki, et fællesdrev og et sagssystem, hvor den, der ved hvilket ét der er det gældende, er på ferie.

Triagering i stor skala: supportkøer, skadesanmeldelser, indgående salg, ansøgningsgennemgang. Alt hvor et menneske i dag læser noget, afgør hvad det er, og sender det videre.

Systemer, der aldrig fik en integration: to værktøjer, der burde tale sammen, gør det ikke, og løsningen er en person med et regneark. En agent med MCP-adgang til begge er ofte en kortere vej end et formelt integrationsprojekt.

Dokumenttunge processer: kontrakter, fakturaer, specifikationer, indberetninger. Udtræk med et menneskeligt kontroltrin er allerede i dag pålideligt nok til at ændre økonomien i den slags processer.

Udviklerproduktivitet i jeres egen kodebase: interne værktøjer, hjælp til code review, testgenerering og MCP-servere, der giver teamets assistenter adgang til jeres byggesystem, jeres issue tracker og jeres logs.

Sådan forløber et samarbejde

Afdækning, en til to uger. Vi ser på den proces, I vil ændre, de systemer der er involveret, og hvordan dataene rent faktisk ser ud. Resultatet er en skriftlig vurdering af, hvad der er muligt, hvad det koster at drive pr. måned ved jeres volumen, og hvad fejlmulighederne er. Nogle gange lyder den: lad være med at bygge det her.

Proof of concept, tre til seks uger, mod virkelige data i et kontrolleret miljø. Pointen er ikke en demo. Det er et evalueringsresultat, I kan stole på, med en målt nøjagtighed mod sager, I selv har valgt.

Produktionsbyggeri, typisk otte til seksten uger, inklusive autentificering, autorisation, monitorering, evalueringsopsætning, omkostningsstyring og dokumentation. Deployet i jeres infrastruktur, i jeres repository, med jeres team involveret hele vejen.

Drift eller overdragelse. Enten overtager jeres team det med runbook og evalueringssuite, eller også driver vi det videre under en supportaftale. Modeller ændrer sig, prompts driver, og evalueringssuiten er det, der fortæller jer, når noget stille og roligt er blevet dårligere.

Teknologi

Python og TypeScript til agent- og MCP-arbejde; PostgreSQL med pgvector, Qdrant, Weaviate eller OpenSearch til søgning; AWS Bedrock, Azure OpenAI, direkte udbyder-API'er og selvhostet inferens med vLLM eller Ollama, hvor dataene ikke må forlade huset; tracing baseret på OpenTelemetry; og hvad end jeres eksisterende stak er på integrationssiden, for det er dér, arbejdet reelt ligger.

Ofte stillede spørgsmål

Hvad er en MCP-server, sagt enkelt?

En lille tjeneste, der eksponerer en kapabilitet (læse fra en database, oprette en sag, søge i jeres dokumenter), i et standardformat, som AI-assistenter forstår. Byg én, og enhver MCP-kompatibel assistent kan bruge den kapabilitet uden en særskilt integration til hver.

Skal vi bygge en MCP-server eller en almindelig API-integration?

Hvis én AI-assistent skal bruge ét system, er en direkte integration enklere. MCP tjener sig hjem, når flere assistenter eller flere teams skal bruge de samme systemer, når I vil have kapabiliteten tilgængelig for værktøjer, I endnu ikke har valgt, eller når I vil have ét sted, hvor rettigheder og revisionslogning bor.

Hvordan forhindrer I en agent i at gøre noget destruktivt?

I lag. Værktøjer, der skriver, er adskilt fra værktøjer, der læser, og skrivende værktøjer er afgrænset så snævert, som opgaven tillader. Alt uigenkaldeligt går gennem et menneskeligt godkendelsestrin. Hvert kald logges med sine argumenter. Og agenten kører med en serviceidentitet, der kun har de rettigheder, opgaven kræver, så skadesradius er afgrænset af jeres egen rettighedsmodel og ikke af prompten.

Hvad koster det at drive?

Det afhænger næsten udelukkende af volumen og af, hvor meget kontekst hvert kald bærer med sig. Vi regner på det i afdækningsfasen med rigtige tal, for forskellen mellem et design, der sender et helt dokument ved hver tur, og et der henter den relevante del, kan være en hel størrelsesorden i månedlig omkostning.

Kan det køre, uden at vores data forlader EU?

Ja. De store udbydere tilbyder EU-regioner, og open-weight-modeller kan køre på infrastruktur, I selv styrer. Der er som regel et kapabilitetsmæssigt afkald, og vi er konkrete om hvilket i stedet for at lade som om, der ikke er et.

Vores sidste AI-pilot nåede aldrig i produktion. Hvorfor skulle denne?

Som regel fordi piloten beviste, at modellen kunne løse opgaven, og aldrig rørte autentificering, rettigheder, fejlhåndtering, evaluering eller omkostninger, hvor de resterende halvfems procent af arbejdet ligger. Vi går ud fra, at modellen virker, og bruger opgaven på alt det andet.

Kom i gang

Beskriv den proces, I vil ændre, og de systemer den rører. Så siger vi, om en agent er det rigtige instrument, hvordan en realistisk første version ser ud, og hvad den koster at bygge og at drive.

Kontakt os for at aftale en teknisk afdækning.

Relaterede ydelser

Staff augmentation og outsourcing: AI-udviklere integreret i jeres team
Compliance med AI-forordningen: når det, I bygger, er omfattet
AWS cost optimization: inferens- og søgeworkloads har det med at overraske folk