Det neste slaget i SaaS starter over MCP

Model Context Protocol gir KI en felles måte å koble seg til bedriftsprogramvare på. Vrushali Paunikar, produktsjef i Carta, mener den større utfordringen er å avgjøre hva som skal skje etter at forbindelsen er opprettet, og hvor mye av jobben som bør overlates til språkmodellen.

I løpet av det siste året har Model Context Protocol gått fra å være en relativt lite kjent teknisk standard til å bli en av de største ideene innen KI for næringslivet.

MCP gir KI-applikasjoner en standardisert måte å koble seg til ekstern programvare på, få tilgang til data og utføre handlinger. I stedet for at hvert programvareselskap bygger et spesialtilpasset grensesnitt for hver KI-modell, tilbyr MCP et felles språk.

Se for deg MCP som stikkontakten i veggen. Det er en felles standard som gjør at alle enheter kan kobles til og få strøm. Det er praktisk fordi standarden er åpen og fungerer overalt, men en stikkontakt gjør ingenting for deg alene. Du trenger fortsatt et apparat.

Jeg tror vi en dag vil se tilbake på dagens begeistring for MCP på omtrent samme måte som vi ser på fremveksten av API-er. De la grunnlaget for utviklingen og endret måten programvare ble bygget på. Men etter hvert ble tilkoblingsmuligheter forventet infrastruktur snarere enn selve produktet.

Mye av SaaS-bransjen behandler for tiden KI-tilkobling som om det var et ferdig produkt. Bygg en MCP-server, gjør de riktige verktøyene og dataene tilgjengelige, og la modellen ta det derfra.

For noen bruksområder er det nok. For mange arbeidsprosesser i næringslivet, særlig innen finans, er det ikke nok.

MCP vinner på tilkoblingslaget

Standardisering er allerede i ferd med å endre hvordan KI-applikasjoner samhandler med programvare. MCP støttes av stadig flere store KI-plattformer, noe som gjør det stadig mer realistisk for brukerne å arbeide med de samme underliggende systemene fra det KI-grensesnittet de foretrekker.

Men selv om samvirking løser tilgangsproblemet, forteller det ikke modellen hvordan jobben skal utføres.

Jeg bruker mye av tiden min på å tenke på programvare som brukes av investorer i private markeder og finansteam, der dette skillet blir særlig tydelig.

Hvis et KI-system for eksempel får tilgang til resultat- og porteføljedata for et privat fond, kan det finnes flere måter å svare på det som høres ut som et enkelt spørsmål.

Én tilnærming kan bruke den riktige beregningen. En annen kan ta en snarvei. En tredje kan misforstå hva brukeren ber om.

Brukeren blir dermed nødt til å være litt analytiker, litt instruksjonsutformer og litt kvalitetskontrollør. Dette er ikke den friksjonsfrie opplevelsen som ble lovet.

Produktet må fortsatt ha en mening

Det er her det neste laget i teknologistakken blir interessant. Hvis MCP er tilkoblingslaget, ligger programtillegg og ferdigheter over det og forteller agenten hvordan den skal bruke forbindelsen til å løse en bestemt oppgave.

I stedet for bare å gjøre data og funksjoner tilgjengelige for en modell kan de samle instruksjoner, arbeidsflyter, deterministiske beregninger og grensesnitt rundt dem.

Noen ganger kan det innebære å følge en fastlagt rekke handlinger. Andre ganger kan det bety å kjøre en deterministisk beregning eller et skript i stedet for å be en stor språkmodell finne svaret. I andre tilfeller kan sluttresultatet være et regneark, en rapport eller et lite program som er laget spesielt for den arbeidsflyten.

Kompetansen ligger i produktet, i stedet for å overlates helt til modellen.

Dokumentasjonen viser at kombinasjonen fungerer. Google testet nylig en KI-kodeagent som kunne få tilgang til den tekniske dokumentasjonen via MCP. Deretter fikk agenten flere oppgavespesifikke instruksjoner som forklarte hvordan den best kunne bruke denne informasjonen. Ved å kombinere forbindelsen med disse instruksjonene oppnådde man en beståttandel på 96,3 % i Googles evaluering, samtidig som man brukte 63 % færre token per riktig svar enn med standard instruksjoner.

For SaaS-selskaper endrer dette hvor konkurransefortrinnet ligger. Hvis alle applikasjoner kan gjøre data tilgjengelige gjennom den samme åpne standarden, blir selve tilgangen mindre særpreget. Det blir mer verdifullt å vite hvordan tilgangen kan omsettes til et pålitelig resultat.

Ikke alle oppgaver bør overlates til modellen

Store språkmodeller er probabilistiske systemer. Fleksibiliteten som gjør dem nyttige til skriving, utforsking og resonnering, er mindre attraktiv i arbeidsflyter der nøyaktighet og gjentakbarhet er viktig. Finans er et godt eksempel: Hvis noen forventer at den samme beregningen skal gi det samme svaret hver gang, blir variasjon raskt et problem.

Finansprogramvare har brukt flere tiår på å bevege seg i motsatt retning. Revisjonsspor, tillatelser, standardiserte beregninger og gjentakbare prosesser finnes fordi konsekvens er verdifullt.

KI bør ikke forkaste disse erfaringene. De beste KI-produktene for næringslivet vil vite når de skal la en modell resonnere, og når de skal begrense den. Probabilistiske systemer passer når skjønn og tolkning er nyttig. Deterministiske verktøy passer bedre når det kreves presisjon og gjentakbarhet.

Det samme prinsippet gjelder overalt der det kan få store konsekvenser å gi feil svar.

Hvor SaaS-differensiering tar veien videre

Laget som bygges oppå MCP, er fortsatt langt mindre etablert enn MCP selv.

Det har dukket opp ulike tilnærminger til programtillegg og ferdigheter, men arbeidet med å gjøre dem mer overførbare mellom AI-plattformer er allerede i gang, slik at de ikke låses til ett enkelt økosystem.

SaaS-selskaper må fortsatt ta valg før alle standardene er på plass. Det har de alltid måttet.

Alternativet er å gjøre et grensesnitt tilgjengelig og overlate til kundene å sette sammen opplevelsen selv.

AI kan følge samme vei. Det blir enklere for hver måned å koble en agent til bedriftsprogramvare. Fordelen vil i stadig større grad ligge i det som skjer videre: arbeidsflytene, kontrollene og domenekunnskapen som viser agenten hvordan den skal omgjøre tilgang til et pålitelig resultat.