Nästa strid inom SaaS börjar ovanför MCP

Model Context Protocol ger AI ett gemensamt sätt att ansluta till företagsprogramvara. Vrushali Paunikar, produktchef på Carta, menar att den större utmaningen är att avgöra vad som händer efter att anslutningen har upprättats och hur mycket av arbetet som bör överlåtas åt språkmodellen.

Under det senaste året har Model Context Protocol gått från att vara en relativt obskyr teknisk standard till en av de största idéerna inom företags-AI.

MCP ger AI-applikationer ett standardiserat sätt att ansluta till extern programvara, komma åt data och utföra åtgärder. I stället för att varje programvaruföretag bygger ett skräddarsytt gränssnitt för varje AI-modell erbjuder MCP ett gemensamt språk.

Tänk på MCP som eluttaget i väggen. Det är en gemensam standard som gör att alla enheter kan anslutas och få ström. Det är utmärkt eftersom standarden är öppen och fungerar överallt, men ett eluttag i sig gör inget för dig. Du behöver fortfarande en apparat.

Jag misstänker att vi så småningom kommer att se tillbaka på dagens entusiasm för MCP ungefär på samma sätt som vi ser på API:ernas framväxt. De lade grunden och förändrade hur programvara byggdes. Men med tiden blev uppkoppling en förväntad infrastruktur snarare än själva produkten.

Stora delar av SaaS-branschen behandlar för närvarande AI-uppkoppling som om den vore en färdig produkt. Bygg en MCP-server, gör rätt verktyg och data tillgängliga och låt modellen ta hand om resten.

För vissa användningsområden räcker det. För många arbetsflöden i företag, särskilt inom finans, gör det inte det.

MCP tar hem segern på anslutningslagret

Standardisering förändrar redan hur AI-applikationer samverkar med programvara. MCP stöds av ett växande antal stora AI-plattformar, vilket gör det allt mer realistiskt för användare att arbeta med samma underliggande system från det AI-gränssnitt de själva föredrar.

Men även om interoperabilitet löser åtkomstproblemet talar den inte om för modellen hur arbetet ska utföras.

Jag ägnar mycket av min tid åt att fundera på programvara som används av investerare på privata marknader och finansteam, där den här skillnaden blir särskilt tydlig.

Om ett AI-system till exempel får tillgång till en privatfonds resultat- och portföljdata kan det finnas flera sätt att besvara det som verkar vara en enkel fråga.

Ett sätt kan vara att använda den lämpliga beräkningen. Ett annat kan vara att ta en genväg. Ett tredje kan vara att missförstå vad användaren frågar efter.

Användaren tvingas då att vara både analytiker, prompttekniker och kvalitetskontrollant. Det här är inte den friktionsfria upplevelse som utlovats.

Produkten måste fortfarande ta ställning

Det är här nästa lager i teknikstacken blir intressant. Om MCP är anslutningslagret ligger pluginer och färdigheter ovanpå det och talar om för agenten hur den ska använda anslutningen för att utföra en viss uppgift.

I stället för att bara göra data och funktioner tillgängliga för en modell kan de samla instruktioner, arbetsflöden, deterministiska beräkningar och gränssnitt kring dem.

Ibland kan det innebära att följa en fastställd sekvens av åtgärder. Ibland kan det innebära att köra en deterministisk beräkning eller ett skript i stället för att be en LLM räkna ut svaret. I andra fall kan slutresultatet vara ett kalkylblad, en rapport eller en mindre applikation som utformats särskilt för det arbetsflödet.

Expertisen finns i produkten i stället för att helt överlåtas åt modellen.

Det finns belägg för att kombinationen fungerar. Google testade nyligen en AI-kodningsagent som kunde komma åt den tekniska dokumentationen via MCP och därefter fick ytterligare uppgiftsspecifika instruktioner om hur informationen bäst skulle användas. Kombinationen av anslutningen och instruktionerna gav en godkännandegrad på 96,3 % i Googles utvärdering, samtidigt som den krävde 63 % färre token per korrekt svar än standardpromptning.

För SaaS-företag förändrar det här var differentieringen ligger. Om varje applikation kan göra data tillgängliga genom samma öppna standard blir själva åtkomsten mindre särskiljande. Det blir mer värdefullt att veta hur åtkomsten kan omsättas i ett tillförlitligt resultat.

Alla uppgifter bör inte överlåtas åt modellen

Stora språkmodeller är probabilistiska system. Den flexibilitet som gör dem användbara för skrivande, utforskande och resonemang är mindre attraktiv i arbetsflöden där noggrannhet och repeterbarhet är viktiga. Finans är ett bra exempel: om någon förväntar sig att samma beräkning ska ge samma svar varje gång blir variation snabbt ett problem.

Finansiell programvara har i årtionden utvecklats i motsatt riktning. Revisionsspår, behörigheter, standardiserade beräkningar och repeterbara processer finns eftersom konsekvens är värdefullt.

AI bör inte kasta bort de lärdomarna. De starkaste AI-produkterna för företag kommer att veta när de ska låta en modell resonera och när de ska begränsa den. Probabilistiska system passar när omdöme och tolkning är användbara. Deterministiska verktyg passar bättre när precision och repeterbarhet krävs.

Samma princip gäller överallt där kostnaden för ett felaktigt svar är hög.

Var nästa differentiering inom SaaS sker

Det lager som byggs ovanpå MCP är fortfarande betydligt mindre etablerat än MCP självt.

Olika sätt att hantera insticksprogram och färdigheter har vuxit fram, men arbetet pågår redan med att göra dem mer portabla mellan AI-plattformar i stället för att låsa dem till ett enda ekosystem.

SaaS-företag måste ändå fatta beslut innan alla standarder har satt sig. Så har det alltid varit.

Alternativet är att tillhandahålla ett gränssnitt och låta kunderna själva sätta ihop upplevelsen.

AI kan följa samma väg. Det blir månad för månad enklare att koppla en agent till företagsprogramvara. Fördelen kommer i allt högre grad att ligga i det som händer sedan: arbetsflödena, kontrollmekanismerna och domänkunskapen som visar agenten hur den ska omvandla åtkomst till ett tillförlitligt resultat.