Apper var til for å klikke på. Munin er ikke det.

Enhver SaaS-app jeg har brukt de siste femten årene var, i bunn og grunn, en tegning av en database. Knapper svarte til skriving. Lister svarte til utvalg. Grensesnittet var produktet fordi klikking var den eneste protokollen vi hadde. Den forutsetningen er stille i ferd med å ta slutt — ikke fordi design ble dårligere — det ble bedre, på måter bransjen bør være stolt av. Det tar slutt fordi den billigste operatøren i systemet har sluttet å være et menneske.

Når en agent kan kalle et verktøy ti tusen ganger i timen for noen få cent, blir det å klikke seg gjennom en arbeidsflyt en underlig ting å betale et menneske for. Skjemaet er der fortsatt. Grunnen til det er det ikke.

Munin er bygget på veddemålet om at dette er mer enn en produktivitetshistorie. Det er et arkitektonisk skifte. Det neste tiåret med forretningsprogramvare blir ikke designet for folkene som før klikket «Send» — det blir designet for folkene som avgjør hvilke utsendelser som er verdt et menneskes navn nederst. Det er færre av dem, og flaten de trenger er mindre, skarpere og nesten utelukkende overvåkende.

Hvorfor er brukergrensesnittet ikke lenger produktet?

Fordi grensesnittet bare noensinne var en måte å gjøre en database redigerbar for hånd på, og håndredigering har sluttet å være det billige alternativet. Når en agent kan kalle et verktøy ti tusen ganger i timen for noen få cent, har en side hvis formål er å samle tastetrykk ingen økonomisk grunn til å eksistere. Grensesnittet overlever der dømmekraften bor, ikke der tastingen gjorde det.

SaaS' arvesynd var at skjermen var spesifikasjonen. Ville du vite hva systemet kunne gjøre, åpnet du appen og så på knappene. Var en arbeidsflyt ikke på en skjerm et sted, fantes den egentlig ikke. API-er var eksporter av grensesnittet, ikke omvendt — og integrasjonsmarkedet bygde seg selv, lønnsomt, ved å lime de andrerangs API-ene sammen igjen.

Det virket. Det virket så godt at en hel profesjon vokste fram rundt det: operatøren som vet hvor man skal klikke. Kundestøtte, salgsdrift, innholdsproduksjon, utgående kommunikasjon — alt dette er profesjoner definert av å kunne menystrukturen i syv forskjellige SaaS-apper og vite hvilken man skal åpne klokka 10.42 på en tirsdag. De gode blir raske på det. De beste slutter å legge merke til menyene.

Problemet er at menyene aldri var det faktiske arbeidet. De var grensesnittet til arbeidet — og vi hadde ved et uhell latt det grensesnittet bli den kanoniske beskrivelsen av hva selskapet kan gjøre. Er det ikke en knapp, leverer vi det ikke. Alle som har prøvd å legge til en eneste kapasitet utenfor menyen i en moden SaaS, vet hva jeg mener.

Bruker AI-agenter et grensesnitt eller et API?

Et API, hver gang. Gitt valget mellom å tegne opp et skjema og å lese en funksjonssignatur, velger en agent signaturen — den teller opp en verktøykatalog i stedet for å skanne en skjerm, og den blir ikke trett eller distrahert halvveis. Munin er bygget denne veien: verktøyflaten er kanonisk, og hvert grensesnitt inkludert vårt eget dashbord er en klient av den.

MCP-protokollen er den kjedelige, korrekte versjonen av denne idéen. Den er ikke glamorøs. Den er HTTP for den nye kalleren. At den er kjedelig, er hele poenget — protokoller vinner når de slutter å være interessante. Munin er MCP-først fordi vi ikke fant noe troverdig motargument: hver produktflate vi ellers ville tegnet, ligger nedstrøms for et lite, stabilt sett verktøykall. Bygg verktøyene først; flatene faller ut av seg selv.

Det er ikke det samme som at «agenter erstatter grensesnitt». Grensesnitt er helt greit. Grensesnitt er, i overskuelig framtid, flaten der mennesker tar irreversible beslutninger og flaten der de tar agenter i å ta feil. Det som endrer seg, er rekkefølgen: grensesnittet definerer ikke lenger hva systemet kan gjøre. Det gjør protokollen. Grensesnittet er én av flere klienter.

Hvordan ser en forretningsapplikasjon ut når agenter drifter den?

Tre ting endrer seg. Arbeidsflytbiblioteket flytter ut av grensesnittet og inn i verktøykatalogen. Antallet sider krymper, fordi å tegne opp en side sjelden er den billigste måten å gjøre noe på. Og godkjenningskøen blir produktet — stedet der mennesker godkjenner, redigerer eller avviser arbeid agenter allerede har skrevet utkast til.

Mer detaljert:

• 01Arbeidsflytbiblioteket flytter ut av grensesnittet og inn i verktøykatalogen. Det som en gang var «hva du kan gjøre på Kontakter-siden», blir crm_* — en liste et menneske kan lese på tre minutter og en agent på tre millisekunder.
• 02Produktets flate krymper. Det finnes dramatisk færre sider, fordi det finnes dramatisk færre tilfeller der å tegne opp en side er den billigste måten å gjøre noe på. Det som blir igjen, er et lite, skarpt sett med overvåkende visninger.
• 03Godkjenningskøen blir produktet. Ikke «innboksen» — stedet der mennesker godkjenner, redigerer eller avviser arbeidet agenter allerede har skrevet utkast til. Det er der selskapets dømmekraft bor nå.

Ingenting av dette er fiendtlig mot design. Det er faktisk vennligere enn det som kom før. De fleste SaaS-dashbordene jeg har brukt, ville vært bedre som fem skjermer enn som femti — og enda bedre som fem skjermer pluss en velnavngitt verktøykatalog. Beskjæringen som kommer, er på overtid.

Du kan se den tredje skje i én enkelt modul: CRM-posten som fyller seg selv ut er en side ingen lenger besøker for å taste inn i, og en kø noen besøker for å bestemme. Samme form styrer utgående kommunikasjon som skriver utkast over natta og venter på godkjenning.

Hvilke deler av SaaS-programvare overlever skiftet til agenter?

Datamodellen, identitetslaget, revisjonsloggen, samtykkestatusen og stedet der mennesker godkjenner ting. De gjorde alltid reelt arbeid. Det som ikke overlever, er tastingen: lange onboarding-løp, overflødige bekreftelsesvinduer, innstillingssider som fantes bare for å eksponere flagg. Færre sider, skarpere, og én post bak dem alle.

Munins påstand er smal. Vi mener ikke at enhver forretningsapp bør erstattes. Vi mener at appene som berører kundeposten — kunnskap, samtaler, CRM, innhold, utgående kommunikasjon, analyse — bør dele et bakstykke, eksponere seg som verktøy, og presentere én overvåkende flate for det menneskelige teamet som eier arbeidet. Ikke fordi appene er dårlige. Fordi en kunde som finnes seks ganger, er seks sjanser til å ta feil om vedkommende.

Og vi mener dette bør være åpent. Åpen kode, åpen protokoll. Innlåsing på datalaget er feilmodusen som gjorde det siste tiåret med SaaS til et synkroniseringsprosjekt. Vi prøver å ikke gjenta den.

Hvis agentene gjør arbeidet, hva er igjen å gjøre for mennesker?

Dømmekraft, og mer av den enn før. Arbeidet flyttet oppstrøms snarere enn å forsvinne: hvilken agent får hvilke tillatelser, hvilke arbeidsflyter eskaleres til et menneske, hvilke forslag sendes automatisk og hvilke venter over natta. Det er rollen Munin er bygget rundt — operatøren som ble forfremmet ut av menyen og inn i beslutningen.

Jeg vil være tydelig på at dette er delen jeg tror blir oversett i diskusjoner om agentisk programvare. Det interessante arbeidet har ikke flyttet ut av selskapet; det har flyttet seg inni det. Det interessante arbeidet pleide å være klikket. Arbeidet har ikke krympet. Det har flyttet oppstrøms.

Folkene som gjør det arbeidet, er stort sett ikke de samme som før klikket «Send». Noen av dem er det. Mange av dem er operatører som ble forfremmet ut av menyen og inn i dømmekraften. Munin-teamet er bygget på antakelsen om at dette er rollen som betyr mest det neste tiåret — og at verktøyene for den er det vi burde bygge.

Ofte stilte spørsmål

Erstatter AI-agenter grensesnittene i forretningsprogramvare? De erstatter dataregistreringsdelene av dem. Sider som fantes for å samle tastetrykk, mister grunnen til å eksistere når et verktøykall er billigere. Sider der et menneske tar en irreversibel beslutning, eller tar en agent i å ta feil, blir viktigere snarere enn mindre viktige. Vent færre skjermer som gjør mer konsekvensrikt arbeid.

Hva betyr «MCP-først» egentlig i et produkt? At verktøykatalogen er den kanoniske flaten og at hvert grensesnitt er en klient av den, inkludert leverandørens eget dashbord. Alternativet — et grensesnitt med et agentlag skrudd på ved siden av — gir to systemer som driver fra hverandre. Munin eksponerer hele plattformen på ett MCP-endepunkt, og dashbordet kaller de samme verktøyene som en agent gjør.

Trenger en agentisk plattform fortsatt et grensesnitt? Ja, et mindre et. Mennesker trenger et sted å godkjenne irreversible handlinger, gjennomgå hva agentene foreslo, og se tilstanden til posten. Det de ikke lenger trenger, er en side for hver skriving. Designjobben skifter fra å tegne databasen til å designe godkjenningsflaten.

Hva er en godkjenningskø? Lista over ting agenter har skrevet utkast til og ikke gjort ennå: et sammenslåingsforslag, en utgående e-post, en kunnskapsartikkel, et innholdsutkast. Billig, reversibelt arbeid utføres automatisk; alt irreversibelt venter på et menneske. Det er flaten der selskapets dømmekraft faktisk nedtegnes, og derfor behandler vi den som produktet snarere enn en innstillingsside. Den andre halvdelen av å stole på en agent med posten er å kunne angre det den skrev.

Hvilke jobber absorberer agentene først? De tasteformede: triagering av innkommende samtaler, merking og titulering av tråder, berikelse av en kontakt fra et firmanettsted, utkast til svar på et spørsmål teamet ditt allerede har besvart én gang. Ingenting av det er dømmekraft. Alt av det er arbeidet som før skjedde klokka 23 eller ikke i det hele tatt.

Er ikke dette bare chatboter skrudd på et CRM? Nei — forskjellen er hvilken side som er kanonisk. En chatbot er en dings foran en app hvis egentlige flate fortsatt er grensesnittet. Munins verktøy er flaten, så en agent gjør triagering, berikelse og utkast direkte mot posten, og mennesket godkjenner det som betyr noe.

Hvis du heller vil se en overvåkende flate enn å lese om en, er Munin Cloud gratis å starte på, og verktøykatalogen er det egentlige produktet.

Apper var til for å klikke. Munin er ikke det.