Appar var till för att klicka på. Munin är inte det.

Varje SaaS-app jag använt de senaste femton åren var i grunden en teckning av en databas. Knappar motsvarade skrivningar. Listor motsvarade urval. Gränssnittet var produkten för att klickandet var det enda protokoll vi hade. Det antagandet håller tyst på att ta slut — inte för att designen blev sämre — den blev bättre, på sätt branschen borde vara stolt över. Det tar slut för att den billigaste operatören i systemet har slutat vara en människa.

När en agent kan anropa ett verktyg tiotusen gånger i timmen för några cent blir det att klicka sig igenom ett arbetsflöde en märklig sak att betala en människa för. Formuläret finns kvar. Skälet till det gör det inte.

Munin är byggt på vadet att det här är mer än en produktivitetsberättelse. Det är ett arkitektoniskt skifte. Nästa decennium av affärsprogramvara kommer inte att formges för dem som förr klickade «Skicka» — den kommer att formges för dem som avgör vilka utskick som är värda en människas namn längst ner. Det är färre av dem, och ytan de behöver är mindre, skarpare och nästan uteslutande övervakande.

Varför är användargränssnittet inte längre produkten?

För att gränssnittet bara någonsin var ett sätt att göra en databas redigerbar för hand, och handredigering har slutat vara det billiga alternativet. När en agent kan anropa ett verktyg tiotusen gånger i timmen för några cent har en sida vars syfte är att samla tangenttryck inget ekonomiskt skäl att existera. Gränssnittet överlever där omdömet bor, inte där skrivandet gjorde det.

SaaS arvsynd var att skärmen var specifikationen. Ville du veta vad systemet kunde göra öppnade du appen och tittade på knapparna. Fanns ett arbetsflöde inte på en skärm någonstans fanns det egentligen inte. API:er var exporter av gränssnittet, inte tvärtom — och integrationsmarknaden byggde sig själv, lönsamt, genom att limma ihop de andraklassens API:erna igen.

Det fungerade. Det fungerade så bra att ett helt yrke växte fram kring det: operatören som vet var man ska klicka. Kundtjänst, säljdrift, innehållsproduktion, utgående kommunikation — allt detta är yrken definierade av att kunna menystrukturen i sju olika SaaS-appar och veta vilken man ska öppna klockan 10.42 en tisdag. De duktiga blir snabba på det. De bästa slutar märka menyerna.

Problemet är att menyerna aldrig var det faktiska arbetet. De var gränssnittet till arbetet — och vi hade av misstag låtit det gränssnittet bli den kanoniska beskrivningen av vad företaget kan göra. Är det inte en knapp levererar vi det inte. Alla som försökt lägga till en enda förmåga utanför menyn i en mogen SaaS vet vad jag menar.

Använder AI-agenter ett gränssnitt eller ett API?

Ett API, varje gång. Givet valet mellan att rita upp ett formulär och att läsa en funktionssignatur väljer en agent signaturen — den räknar upp en verktygskatalog i stället för att skanna en skärm, och den blir inte trött eller distraherad halvvägs. Munin är byggt åt det hållet: verktygsytan är kanonisk, och varje gränssnitt inklusive vår egen instrumentpanel är en klient av den.

MCP-protokollet är den tråkiga, korrekta versionen av den här idén. Det är inte glamoröst. Det är HTTP för den nya anroparen. Att det är tråkigt är hela poängen — protokoll vinner när de slutar vara intressanta. Munin är MCP-först för att vi inte hittade något trovärdigt motargument: varje produktyta vi annars skulle rita ligger nedströms om en liten, stabil uppsättning verktygsanrop. Bygg verktygen först; ytorna faller ut av sig själva.

Det är inte detsamma som att «agenter ersätter gränssnitt». Gränssnitt är helt okej. Gränssnitt är, inom överskådlig framtid, ytan där människor fattar oåterkalleliga beslut och ytan där de ertappar agenter med att ha fel. Det som förändras är ordningen: gränssnittet definierar inte längre vad systemet kan göra. Det gör protokollet. Gränssnittet är en av flera klienter.

Hur ser en affärsapplikation ut när agenter driver den?

Tre saker förändras. Arbetsflödesbiblioteket flyttar ut ur gränssnittet och in i verktygskatalogen. Antalet sidor krymper, eftersom att rita upp en sida sällan är det billigaste sättet att göra något. Och granskningskön blir produkten — platsen där människor godkänner, redigerar eller avvisar arbete som agenter redan utkastat.

Mer i detalj:

• 01Arbetsflödesbiblioteket flyttar ut ur gränssnittet och in i verktygskatalogen. Det som en gång var «vad du kan göra på Kontakter-sidan» blir crm_* — en lista en människa kan läsa på tre minuter och en agent på tre millisekunder.
• 02Produktens yta krymper. Det finns dramatiskt färre sidor, eftersom det finns dramatiskt färre fall där att rita upp en sida är det billigaste sättet att göra något. Kvar blir en liten, skarp uppsättning övervakande vyer.
• 03Granskningskön blir produkten. Inte «inkorgen» — platsen där människor godkänner, redigerar eller avvisar arbetet agenter redan utkastat. Det är där företagets omdöme bor nu.

Inget av detta är fientligt mot design. Det är faktiskt vänligare än det som kom före. De flesta SaaS-instrumentpaneler jag använt hade varit bättre som fem skärmar än som femtio — och ännu bättre som fem skärmar plus en välnamngiven verktygskatalog. Beskärningen som kommer är på övertid.

Du kan se den tredje hända i en enda modul: CRM-posten som fyller i sig själv är en sida ingen längre besöker för att skriva in i, och en kö någon besöker för att besluta. Samma form styr utgående kommunikation som utkastar över natten och väntar på godkännande.

Vilka delar av SaaS-programvara överlever skiftet till agenter?

Datamodellen, identitetslagret, revisionsloggen, samtyckesstatusen och platsen där människor godkänner saker. De gjorde alltid verkligt arbete. Det som inte överlever är skrivandet: långa onboarding-flöden, överflödiga bekräftelserutor, inställningssidor som fanns bara för att exponera flaggor. Färre sidor, skarpare, och en post bakom dem alla.

Munins anspråk är små. Vi tycker inte att varje affärsapp bör ersättas. Vi tycker att apparna som rör kundposten — kunskap, konversationer, CRM, innehåll, utgående kommunikation, analys — bör dela en backend, exponera sig som verktyg och presentera en övervakande yta för det mänskliga team som äger arbetet. Inte för att apparna är dåliga. För att en kund som finns sex gånger är sex chanser att ha fel om dem.

Och vi tycker att det här bör vara öppet. Öppen kod, öppet protokoll. Inlåsning i datalagret är felmoden som gjorde det senaste decenniet av SaaS till ett synkprojekt. Vi försöker att inte upprepa den.

Om agenterna gör arbetet, vad återstår för människor?

Omdöme, och mer av det än förr. Arbetet flyttade uppströms snarare än försvann: vilken agent får vilka behörigheter, vilka arbetsflöden eskaleras till en människa, vilka förslag skickas automatiskt och vilka väntar över natten. Det är rollen Munin är byggt kring — operatören som befordrades ut ur menyn och in i beslutet.

Jag vill vara tydlig med att det här är den del jag tror missas i diskussioner om agentisk programvara. Det intressanta arbetet har inte flyttat ut ur företaget; det har flyttat sig inuti det. Det intressanta arbetet brukade vara klicket. Arbetet har inte krympt. Det har flyttat uppströms.

De som gör det arbetet är mestadels inte samma personer som förr klickade «Skicka». Vissa är det. Många är operatörer som befordrades ut ur menyn och in i omdömet. Munin-teamet är byggt på antagandet att det här är rollen som betyder mest nästa decennium — och att verktygen för den är vad vi borde bygga.

Vanliga frågor

Ersätter AI-agenter gränssnitten i affärsprogramvara? De ersätter datainmatningsdelarna av dem. Sidor som fanns för att samla tangenttryck förlorar sitt skäl att existera när ett verktygsanrop är billigare. Sidor där en människa fattar ett oåterkalleligt beslut, eller ertappar en agent med att ha fel, blir viktigare snarare än mindre viktiga. Vänta dig färre skärmar som gör mer följdrikt arbete.

Vad betyder «MCP-först» egentligen i en produkt? Att verktygskatalogen är den kanoniska ytan och att varje gränssnitt är en klient av den, inklusive leverantörens egen instrumentpanel. Alternativet — ett gränssnitt med ett agentlager fastskruvat bredvid — ger två system som glider isär. Munin exponerar hela plattformen på en MCP-ändpunkt, och instrumentpanelen anropar samma verktyg som en agent gör.

Behöver en agentisk plattform fortfarande ett gränssnitt? Ja, ett mindre. Människor behöver någonstans att godkänna oåterkalleliga åtgärder, granska vad agenterna föreslog och se postens tillstånd. Vad de inte längre behöver är en sida för varje skrivning. Designjobbet skiftar från att rita databasen till att formge granskningsytan.

Vad är en granskningskö? Listan över saker agenter utkastat och ännu inte gjort: ett sammanslagningsförslag, ett utgående mejl, en kunskapsartikel, ett innehållsutkast. Billigt, återkalleligt arbete utförs automatiskt; allt oåterkalleligt väntar på en människa. Det är ytan där ett företags omdöme faktiskt nedtecknas, vilket är varför vi behandlar den som produkten snarare än en inställningssida. Den andra hälften av att lita på en agent med posten är att kunna ångra det den skrev.

Vilka jobb absorberar agenterna först? De skrivformade: triagering av inkommande konversationer, taggning och titelsättning av trådar, berikning av en kontakt från en företagssajt, utkast till svar på en fråga ditt team redan besvarat en gång. Inget av det är omdöme. Allt av det är arbetet som förr skedde klockan 23 eller inte alls.

Är inte det här bara chattbotar fastskruvade på ett CRM? Nej — skillnaden är vilken sida som är kanonisk. En chattbot är en pryl framför en app vars verkliga yta fortfarande är gränssnittet. Munins verktyg är ytan, så en agent gör triagering, berikning och utkast direkt mot posten, och människan godkänner det som betyder något.

Om du hellre ser en övervakande yta än läser om en är Munin Cloud gratis att börja på, och verktygskatalogen är den faktiska produkten.

Appar var till för att klicka. Munin är inte det.