Apps var til at klikke på. Munin er ikke det.

Enhver SaaS-app, jeg har brugt de seneste femten år, dybest set var en tegning af en database. Knapper svarede til skrivninger. Lister svarede til udvælgelser. Grænsefladen var produktet, fordi klikkeriet var den eneste protokol, vi havde. Den antagelse er stille ved at slutte — ikke fordi designet blev dårligere — det blev bedre, på måder branchen bør være stolt af. Det slutter, fordi den billigste operatør i systemet er holdt op med at være et menneske.

Når en agent kan kalde et værktøj ti tusind gange i timen for få cent, bliver det at klikke sig gennem et arbejdsflow en mærkelig ting at betale et menneske for. Formularen er der stadig. Grunden til den er det ikke.

Munin er bygget på væddemålet om, at det her er mere end en produktivitetshistorie. Det er et arkitektonisk skifte. Det næste årti med forretningssoftware bliver ikke designet til dem, der før klikkede »Send« — det bliver designet til dem, der afgør, hvilke udsendelser der er et menneskes navn værd nederst. Der er færre af dem, og den flade, de har brug for, er mindre, skarpere og næsten udelukkende overvågende.

Hvorfor er brugergrænsefladen ikke længere produktet?

Fordi grænsefladen kun nogensinde var en måde at gøre en database redigerbar i hånden, og håndredigering er holdt op med at være den billige mulighed. Når en agent kan kalde et værktøj ti tusind gange i timen for få cent, har en side, hvis formål er at samle tastetryk, ingen økonomisk grund til at eksistere. Grænsefladen overlever der, hvor dømmekraften bor, ikke der hvor tastningen gjorde det.

SaaS' arvesynd var, at skærmen var specifikationen. Ville du vide, hvad systemet kunne, åbnede du appen og kiggede på knapperne. Var et arbejdsflow ikke på en skærm et sted, fandtes det ikke rigtig. API'er var eksporter af grænsefladen, ikke omvendt — og integrationsmarkedet byggede sig selv, profitabelt, ved at lime de andenrangs API'er sammen igen.

Det virkede. Det virkede så godt, at et helt fag voksede frem omkring det: operatøren, der ved, hvor man skal klikke. Kundeservice, salgsdrift, indholdsproduktion, udgående kommunikation — alt dette er fag defineret ved at kunne menustrukturen i syv forskellige SaaS-apps og vide, hvilken man skal åbne klokken 10.42 en tirsdag. De dygtige bliver hurtige til det. De bedste holder op med at bemærke menuerne.

Problemet er, at menuerne aldrig var det faktiske arbejde. De var grænsefladen til arbejdet — og vi havde ved et uheld ladet den grænseflade blive den kanoniske beskrivelse af, hvad virksomheden kan. Er det ikke en knap, leverer vi det ikke. Alle, der har prøvet at tilføje en eneste evne uden for menuen i en moden SaaS, ved, hvad jeg mener.

Bruger AI-agenter en grænseflade eller et API?

Et API, hver gang. Givet valget mellem at tegne en formular og at læse en funktionssignatur vælger en agent signaturen — den tæller et værktøjskatalog op i stedet for at scanne en skærm, og den bliver ikke træt eller distraheret halvvejs. Munin er bygget den vej rundt: værktøjsfladen er kanonisk, og enhver grænseflade inklusive vores eget dashboard er en klient af den.

MCP-protokollen er den kedelige, korrekte version af den idé. Den er ikke glamourøs. Den er HTTP for den nye kalder. At den er kedelig er hele pointen — protokoller vinder, når de holder op med at være interessante. Munin er MCP-først, fordi vi ikke kunne finde et troværdigt modargument: enhver produktflade, vi ellers ville tegne, ligger nedstrøms for et lille, stabilt sæt værktøjskald. Byg værktøjerne først; fladerne falder ud af sig selv.

Det er ikke det samme som, at »agenter erstatter grænseflader«. Grænseflader er helt fine. Grænseflader er i overskuelig fremtid den flade, hvor mennesker træffer uigenkaldelige beslutninger, og den flade, hvor de tager agenter i at tage fejl. Det, der ændrer sig, er rækkefølgen: grænsefladen definerer ikke længere, hvad systemet kan. Det gør protokollen. Grænsefladen er én af flere klienter.

Hvordan ser en forretningsapplikation ud, når agenter driver den?

Tre ting ændrer sig. Arbejdsflowbiblioteket flytter ud af grænsefladen og ind i værktøjskataloget. Antallet af sider skrumper, fordi det sjældent er den billigste måde at gøre noget på at tegne en side. Og godkendelseskøen bliver produktet — stedet hvor mennesker godkender, redigerer eller afviser arbejde, som agenter allerede har lavet udkast til.

Mere detaljeret:

• 01Arbejdsflowbiblioteket flytter ud af grænsefladen og ind i værktøjskataloget. Det, der engang var »hvad du kan gøre på Kontakter-siden«, bliver crm_* — en liste et menneske kan læse på tre minutter og en agent på tre millisekunder.
• 02Produktets flade skrumper. Der er dramatisk færre sider, fordi der er dramatisk færre tilfælde, hvor det at tegne en side er den billigste måde at gøre noget på. Tilbage bliver et lille, skarpt sæt overvågende visninger.
• 03Godkendelseskøen bliver produktet. Ikke »indbakken« — stedet hvor mennesker godkender, redigerer eller afviser det arbejde, agenter allerede har lavet udkast til. Det er der, virksomhedens dømmekraft bor nu.

Intet af dette er fjendtligt over for design. Det er faktisk venligere end det, der kom før. De fleste SaaS-dashboards, jeg har brugt, ville være bedre som fem skærme end som halvtreds — og endnu bedre som fem skærme plus et velnavngivet værktøjskatalog. Beskæringen, der kommer, er for længst forsinket.

Du kan se den tredje ske i ét enkelt modul: CRM-posten, der udfylder sig selv, er en side, ingen længere besøger for at taste i, og en kø, nogen besøger for at beslutte. Samme form styrer udgående kommunikation, der laver udkast natten over og venter på godkendelse.

Hvilke dele af SaaS-software overlever skiftet til agenter?

Datamodellen, identitetslaget, revisionsloggen, samtykkestatussen og stedet, hvor mennesker godkender ting. De lavede altid reelt arbejde. Det, der ikke overlever, er tastningen: lange onboarding-forløb, overflødige bekræftelsesvinduer, indstillingssider der kun fandtes for at eksponere flag. Færre sider, skarpere, og én post bag dem alle.

Munins påstand er snæver. Vi mener ikke, at enhver forretningsapp bør erstattes. Vi mener, at de apps, der rører kundeposten — viden, samtaler, CRM, indhold, udgående kommunikation, analyse — bør dele en backend, eksponere sig som værktøjer og præsentere én overvågende flade for det menneskelige team, der ejer arbejdet. Ikke fordi apps'ene er dårlige. Fordi en kunde, der findes seks gange, er seks chancer for at tage fejl om vedkommende.

Og vi mener, dette bør være åbent. Åben kode, åben protokol. Lås-ind i datalaget er den fejltilstand, der gjorde det seneste årti med SaaS til et synkroniseringsprojekt. Vi prøver ikke at gentage den.

Hvis agenterne laver arbejdet, hvad er der så tilbage til mennesker?

Dømmekraft, og mere af den end før. Arbejdet flyttede opstrøms snarere end at forsvinde: hvilken agent får hvilke rettigheder, hvilke arbejdsflow eskaleres til et menneske, hvilke forslag sendes automatisk, og hvilke venter natten over. Det er den rolle, Munin er bygget omkring — operatøren, der blev forfremmet ud af menuen og ind i beslutningen.

Jeg vil være tydelig om, at det her er den del, jeg tror bliver overset i diskussioner om agentisk software. Det interessante arbejde er ikke flyttet ud af virksomheden; det har flyttet sig inde i den. Det interessante arbejde plejede at være klikket. Arbejdet er ikke skrumpet. Det er flyttet opstrøms.

De, der laver det arbejde, er for det meste ikke de samme, som før klikkede »Send«. Nogle er. Mange er operatører, der blev forfremmet ud af menuen og ind i dømmekraften. Munin-teamet er bygget på antagelsen om, at det er den rolle, der betyder mest det næste årti — og at værktøjerne til den er det, vi burde bygge.

Ofte stillede spørgsmål

Erstatter AI-agenter grænsefladerne i forretningssoftware? De erstatter dataindtastningsdelene af dem. Sider, der fandtes for at samle tastetryk, mister deres grund til at eksistere, når et værktøjskald er billigere. Sider, hvor et menneske træffer en uigenkaldelig beslutning eller tager en agent i at tage fejl, bliver vigtigere snarere end mindre vigtige. Forvent færre skærme, der laver mere konsekvensrigt arbejde.

Hvad betyder »MCP-først« egentlig i et produkt? At værktøjskataloget er den kanoniske flade, og at enhver grænseflade er en klient af det, inklusive leverandørens eget dashboard. Alternativet — en grænseflade med et agentlag skruet på ved siden af — giver to systemer, der driver fra hinanden. Munin eksponerer hele platformen på ét MCP-endepunkt, og dashboardet kalder de samme værktøjer som en agent.

Har en agentisk platform stadig brug for en grænseflade? Ja, en mindre. Mennesker har brug for et sted at godkende uigenkaldelige handlinger, gennemgå hvad agenterne foreslog, og se postens tilstand. Det, de ikke længere har brug for, er en side per skrivning. Designopgaven skifter fra at tegne databasen til at designe godkendelsesfladen.

Hvad er en godkendelseskø? Listen over ting, agenter har lavet udkast til og endnu ikke gjort: et sammenlægningsforslag, en udgående mail, en videnartikel, et indholdsudkast. Billigt, reversibelt arbejde udføres automatisk; alt uigenkaldeligt venter på et menneske. Det er fladen, hvor en virksomheds dømmekraft faktisk nedskrives, og derfor behandler vi den som produktet snarere end en indstillingsside. Den anden halvdel af at stole på en agent med posten er at kunne fortryde, hvad den skrev.

Hvilke job absorberer agenterne først? De tasteformede: triagering af indgående samtaler, tagging og titulering af tråde, berigelse af en kontakt fra et firmawebsted, udkast til svar på et spørgsmål, dit team allerede har besvaret én gang. Intet af det er dømmekraft. Alt af det er det arbejde, der før skete klokken 23 eller slet ikke.

Er det her ikke bare chatbots skruet på et CRM? Nej — forskellen er, hvilken side der er kanonisk. En chatbot er en dims foran en app, hvis egentlige flade stadig er grænsefladen. Munins værktøjer er fladen, så en agent laver triagering, berigelse og udkast direkte mod posten, og mennesket godkender det, der betyder noget.

Hvis du hellere vil se en overvågende flade end læse om en, er Munin Cloud gratis at starte på, og værktøjskataloget er det egentlige produkt.

Apps var til at klikke på. Munin er ikke det.