Hva er en KI-agent, og hva har API og MCP med den å gjøre?

Fra svar til handling

Tenk deg at en medarbeider vil ha hjelp med en reiseregning. En chatbot kan forklare reisereglene. Skal den også hente bestillingen, fylle ut skjemaet og sende det til godkjenning, trenger den verktøy som kan utføre disse oppgavene.

En KI-agent kan bruke slike verktøy og velge neste steg ut fra resultatet. Den kan for eksempel hente reisen, oppdage at en kvittering mangler og be medarbeideren laste den opp før den lager utkastet.

Hvor selvstendig agenten arbeider, varierer fra løsning til løsning. Det må avtales hvilke handlinger den kan utføre selv, og når den skal be et menneske om hjelp eller godkjenning.

API: forbindelsen til bedriftssystemet

Et API er et grensesnitt programvare bruker for å be om data eller handlinger. Et reisesystem kan for eksempel tilby funksjoner for å hente en bestilling eller lagre et utkast. Integrasjonen må sende opplysningene i riktig format og ha nødvendig tilgang.

Vi kan lage ett verktøy som henter brukerens egne reiser, og et annet som oppretter et utkast. Applikasjonen bruker innloggingen til å avgjøre hvem forespørselen gjelder, og kontrollerer tilgangen ved hvert kall. Modellen får ikke velge en annen brukers identitet.

For en fast prosess kan vanlig programkode være nok: hent data, kontroller felter og send videre. En modell er mest interessant der oppgaven faktisk krever tolkning av språk, ustrukturert informasjon eller valg mellom mulige fremgangsmåter.

MCP: en felles måte å tilby verktøy på

MCP står for Model Context Protocol. Det er en protokoll for å koble KI-applikasjoner til blant annet verktøy og datakilder. En MCP-server beskriver hva den tilbyr, slik at en kompatibel KI-applikasjon kan oppdage og bruke funksjonene.

Serveren kan selv snakke med et eksisterende API. Da kan flyten være: KI-applikasjon → MCP-verktøy → reisesystemets API. Resultatet går tilbake samme vei. MCP erstatter verken språkmodellen eller systemet som eier dataene.

Direkte API-kall kan være tilstrekkelig for én enkel integrasjon. MCP er særlig nyttig når flere KI-applikasjoner skal kunne bruke de samme funksjonene, uten at vi bygger en egen kobling for hver av dem.

Kontrakter som programvaren håndhever

En teknisk kontrakt beskriver hvilke felt et verktøy tar imot, hvilke verdier som er tillatt, og hva det skal returnere. For en reiseregning kan dato, valuta og beløp ha bestemte formater. Programvaren kontrollerer forespørselen og stopper den hvis kravene ikke er oppfylt.

Et korrekt format gjør ikke opplysningene sanne. Et beløp kan være et gyldig tall og likevel være feil. Derfor må vi også kontrollere hvem som har tilgang, hvor opplysningene kommer fra og om handlingen er tillatt i den aktuelle situasjonen.

Hvordan RAG og MCP henger sammen

RAG handler om å hente informasjon som kan støtte et svar. MCP handler om hvordan en applikasjon kobles til verktøy og data. Et MCP-verktøy kan utføre et RAG-søk, men en MCP-integrasjon trenger ikke bruke RAG.

Skal agenten forklare en reiseregel før den lager utkastet, kan vi kreve gode nok kildetreff før den svarer. Retten til å sende inn reiseregningen kontrolleres separat. Et relevant dokument gir ingen fullmakt til å handle.

Når vi tester løsningen, må vi derfor kontrollere både at forklaringen stemmer med kildene og at agenten bare utfører tillatte handlinger.

Brukeren godkjenner før innsending

Et godt sted å begynne er å la agenten hente opplysninger og lage et utkast. Medarbeideren får se beløp, mottaker og vedlegg før innsending. Godkjenningen gjelder akkurat det som er vist; endrer agenten noe, må brukeren godkjenne på nytt.

Når brukeren ser hva som skjer, blir feil også enklere å oppdage. En uventet utgift eller en manglende kvittering bør ikke skjules bak en generisk tilbakemelding. Vi avtaler hva løsningen gjør ved manglende data, avbrudd og feil fra bedriftssystemet.

Vi kan gi agenten flere oppgaver etter hvert som den er prøvd ut. Hver utvidelse krever en ny vurdering av tilganger, godkjenning og hva som kan gå galt.

Dere skal kunne overta løsningen

Ved en skreddersydd leveranse fra EPM får kunden den kundespesifikke koden, dokumentasjonen og nødvendige tilganger. Tredjepartskomponenter beholder sine lisenser. Dokumentasjonen skal vise dataflyten, integrasjonene, driftsoppsettet og hvilke tester som brukes ved endringer.

Dere betaler for modell, søk og drift fra egne leverandørkontoer, uten påslag fra EPM. Utvikling og oppfølging avtales separat. Med kode, dokumentasjon og tilganger på plass kan dere følge kostnadene og la en annen utvikler overta arbeidet.