Det næste slag i SaaS står højere oppe end MCP

Model Context Protocol giver AI en fælles måde at oprette forbindelse til virksomhedssoftware på. Vrushali Paunikar, produktdirektør hos Carta, mener, at den større udfordring er at beslutte, hvad der skal ske, når forbindelsen er oprettet, og hvor stor en del af arbejdet der bør overlades til sprogmodellen.

I løbet af det seneste år er Model Context Protocol gået fra at være en forholdsvis ukendt teknisk standard til at blive en af de største idéer inden for virksomheds-AI.

MCP giver AI-applikationer en standardiseret måde at oprette forbindelse til ekstern software, få adgang til data og udføre handlinger på. I stedet for at hver softwarevirksomhed bygger en skræddersyet grænseflade til hver AI-model tilbyder MCP et fælles sprog.

Tænk på MCP som stikkontakten i væggen. Det er en fælles standard, der gør det muligt for enhver enhed at blive tilsluttet og få strøm. Det er smart, fordi standarden er åben og fungerer overalt, men en stikkontakt i sig selv gør ikke noget for dig. Du har stadig brug for et apparat.

Jeg formoder, at vi med tiden vil se tilbage på den nuværende begejstring for MCP på omtrent samme måde, som vi ser på API’ernes fremkomst. De var grundlæggende og ændrede måden, software blev udviklet på. Men med tiden blev forbindelsesmuligheder en forventet del af infrastrukturen snarere end selve produktet.

Store dele af SaaS-branchen behandler i øjeblikket AI-forbindelser, som om de var et færdigt produkt. Byg en MCP-server, gør de rette værktøjer og data tilgængelige, og lad modellen klare resten.

Til nogle anvendelser er det nok. Til mange arbejdsgange i virksomheder, især økonomiske, er det ikke.

MCP vinder kampen om forbindelseslaget

Standardisering ændrer allerede måden, AI-applikationer interagerer med software på. MCP understøttes af et voksende udvalg af større AI-platforme, hvilket gør det stadig mere realistisk for brugerne at arbejde med de samme underliggende systemer fra den AI-grænseflade, de foretrækker.

Men selvom interoperabilitet løser problemet med adgang, fortæller det ikke modellen, hvordan opgaven skal udføres.

Jeg bruger meget af min tid på at tænke over software, der bruges af investorer på private markeder og økonomiteams, hvor denne forskel bliver særlig tydelig.

Giv for eksempel et AI-system adgang til en privat fonds resultat- og porteføljedata, og der kan være flere måder at besvare det, der lyder som et ligetil spørgsmål.

Én tilgang kunne være at bruge den passende beregning. En anden kunne være at tage en genvej. En tredje kunne være at misforstå, hvad brugeren spørger om.

Brugeren bliver så nødt til både at være analytiker, promptingeniør og kvalitetskontrollør. Det er ikke den friktionsfri oplevelse, der blev lovet.

Produktet skal stadig have en holdning

Det er her, det næste lag i stakken bliver interessant. Hvis MCP er forbindelseslaget, ligger plugins og færdigheder oven på det og fortæller agenten, hvordan forbindelsen skal bruges til at løse en bestemt opgave.

I stedet for blot at give en model adgang til data og funktioner kan de samle instruktioner, arbejdsgange, deterministiske beregninger og grænseflader omkring dem.

Nogle gange kan det betyde, at man følger en fastlagt rækkefølge af handlinger. Andre gange kan det betyde, at man kører en deterministisk beregning eller et script i stedet for at bede en LLM om at finde svaret. I andre tilfælde kan resultatet være et regneark, en rapport eller en mindre applikation, der er udviklet specifikt til den pågældende arbejdsgang.

Ekspertisen ligger i produktet i stedet for udelukkende at være overladt til modellen.

Dokumentationen viser, at kombinationen virker. Google testede for nylig en AI-kodeagent, der kunne få adgang til Googles tekniske dokumentation via MCP. Derefter fik agenten yderligere opgavespecifikke instruktioner, der forklarede, hvordan den bedst kunne bruge oplysningerne. Ved at kombinere forbindelsen med disse instruktioner opnåede man en beståelsesprocent på 96,3 % i Googles evaluering, samtidig med at der blev brugt 63 % færre tokens pr. korrekt svar end ved almindelig promptning.

For SaaS-virksomheder ændrer det, hvor differentieringen ligger. Hvis alle applikationer kan gøre data tilgængelige gennem den samme åbne standard, bliver selve adgangen mindre særpræget. Det bliver mere værdifuldt at vide, hvordan adgangen kan omsættes til et pålideligt resultat.

Ikke alle opgaver bør overlades til modellen

Store sprogmodeller er probabilistiske systemer. Den fleksibilitet, der gør dem nyttige til skrivning, udforskning og ræsonnement, er mindre attraktiv i arbejdsgange, hvor nøjagtighed og reproducerbarhed er vigtige. Økonomi er et godt eksempel: Hvis man forventer, at den samme beregning giver det samme svar hver gang, bliver variation hurtigt et problem.

Finansiel software har i årtier bevæget sig i den modsatte retning. Revisionsspor, adgangsrettigheder, standardiserede beregninger og gentagelige processer findes, fordi ensartethed har værdi.

AI bør ikke forkaste de erfaringer. De stærkeste AI-produkter til virksomheder vil vide, hvornår en model skal have lov til at ræsonnere, og hvornår den skal begrænses. Probabilistiske systemer giver mening, når dømmekraft og fortolkning er nyttige. Deterministiske værktøjer giver mere mening, når der kræves præcision og reproducerbarhed.

Det samme princip gælder overalt, hvor det har store konsekvenser at få et forkert svar.

Hvor SaaS-differentieringen bevæger sig hen næste gang

Det lag, der bygges oven på MCP, er stadig langt mindre afklaret end MCP selv.

Der er opstået forskellige tilgange til plugins og færdigheder, men arbejdet med at gøre dem mere portable på tværs af AI-platforme er allerede i gang, så de ikke låses fast til ét enkelt økosystem.

SaaS-virksomheder bliver stadig nødt til at træffe valg, før alle standarder er på plads. Sådan har det altid været.

Alternativet er at stille en grænseflade til rådighed og lade kunderne selv sammensætte oplevelsen.

AI følger måske samme vej. Det bliver lettere for hver måned at forbinde en agent med virksomhedssoftware. Fordelen vil i stigende grad ligge i det, der sker bagefter: arbejdsgangene, styringen og domæneekspertisen, der viser agenten, hvordan den kan omsætte adgang til et pålideligt resultat.