Hva krever API-first av designeren?

API-first krever at designeren tegner kontrakten før skjermbildet. Kontrakten består av fem ting: navn og beskrivelser, standardverdier, feilsvar, bekreftelser og hva systemet gjør med det det ikke forstår. En agent som bruker produktet, ser aldri skjermbildet. Agenten ser bare kontrakten, og agenten følger kontrakten bokstavelig.

Apps AS bygger produkter der agenter er en like vanlig bruker som mennesker. Artikkelen bygger på hvordan CMS-et i Munin, Apps AS' egen kundeplattform, er satt opp for publiseringsagenten som skriver utkastene på apps.no, og på oppsettet for utgående samtaler i Threll.ai, lest 12. oktober 2026.

Hva betyr API-first?

API-first betyr at funksjonene i et produkt bygges som et programmeringsgrensesnitt først, og at skjermbildene bygges oppå det samme grensesnittet etterpå. Alt et menneske kan gjøre i skjermbildet, kan et annet program gjøre gjennom API-et.

Begrepet er eldre enn agentene. Det nye er hvem som kaller API-et. Før var kalleren en utvikler som leste dokumentasjonen og skrev koden én gang. Nå er kalleren ofte en agent som leser beskrivelsen ved hvert kall, velger handling ut fra teksten og ikke spør noen når teksten er uklar.

Hvorfor er API-et nå designerens ansvar?

API-et er designerens ansvar fordi API-et er det eneste grensesnittet agenten møter. Et API formet etter databasen virket så lenge kalleren visste hvordan systemet var bygget. En agent vet ikke det, og agenten fyller hullene med gjetning.

Kaleb Pomeroy i sikkerhetsselskapet SpecterOps beskrev i juli 2026 hvordan teamet bak verktøyet BloodHound bygget om en MCP-server, altså serveren som gir agenter verktøy etter standarden Model Context Protocol. Den første versjonen speilet API-et. Den ferdige versjonen hadde noen få enkle kall bygget rundt det agenten prøvde å få til, og verktøy ble lagt tilbake bare der agentene viste et hull i arbeidsflyten. Framgangsmåten er designarbeid: observere bruk, fjerne valg og legge tilbake det som manglet.

Hvilke fem ting må designeren levere i et API-first-produkt?

Designeren må levere fem ting i et API-first-produkt. Hver av de fem har en motpart i skjermdesign som designeren allerede kan.

Det svarer til, på skjerm	Det designeren leverer i API-et	Eksempel fra Apps AS
Hjelpeteksten	Navn og beskrivelse på hver handling og hvert felt	Feltbeskrivelsene i artikkelsamlingen i Munin
Forhåndsvalget i et skjema	Standardverdien når et felt utelates	Standardspråket i CMS-et for apps.no
Feilmeldingen	Et feilsvar som sier hva kalleren gjør nå	Feilkodene for tekstendringer i Munin
Bekreftelsesdialogen	To operasjoner: forbered, så utfør	Utgående samtaler i Threll.ai
Valideringen	Hva systemet gjør med det det ikke kjenner	Ukjente blokktyper på artikkelsiden

Hvorfor er beskrivelsen av et felt designarbeid?

Beskrivelsen av et felt er designarbeid fordi beskrivelsen er det eneste agenten leser før den fyller ut feltet. Beskrivelsen gjør jobben en hjelpetekst, en plassholder og et eksempel gjør på en skjerm.

Beskrivelsene i artikkelsamlingen på apps.no er skrevet som instrukser. Feltet for alternativ tekst sier at teksten skal beskrive det som faktisk er i bildet, og ikke gjenta tittelen. Kildelisten sier at ordet «Link:» ikke skal stå foran lenkene, fordi merket ellers blir gjentatt støy i hver linje. Begge setningene stopper en feil som er lett å gjøre, før den skjer.

Den samme regelen gjelder kanaler. Kundeagenten i Munin har én beskrivelse per kanal. På SMS skal svaret være under 160 tegn og uten markdown. Designspesifikasjonen for SMS-kanalen er altså to setninger tekst.

Hvorfor er en standardverdi et designvalg?

En standardverdi er et designvalg fordi standardverdien bestemmer hva som skjer når kalleren ikke tar stilling. Et menneske ser forhåndsvalget i skjemaet. En agent som utelater et felt, ser ingenting.

CMS-et apps.no publiserer fra, har engelsk (en-US) som standardspråk. En norsk artikkel som opprettes uten språk, blir lagret som engelsk uten feilmelding. Publiseringsagenten på apps.no har derfor en egen regel om å oppgi språket ved hver oppretting. Regelen er en lapp over et designvalg. En standardverdi som kan gi feil resultat uten varsel, burde vært et obligatorisk felt.

Hva skal et feilsvar fortelle en agent?

Et feilsvar skal fortelle agenten hva den gjør nå. En feilmelding til et menneske kan være vag, fordi mennesket ser skjermen og prøver igjen. En agent har bare teksten i svaret.

Munin skiller mellom feil som krever ulik neste handling. Når agenten vil bytte ut en tekstbit og teksten ikke finnes, svarer CMS-et cms_replacement_no_match. Når teksten finnes flere steder, svarer CMS-et cms_replacement_ambiguous. Den første feilen betyr at agenten må lese artikkelen på nytt. Den andre betyr at agenten må ta med mer tekst rundt det som skal byttes ut. Hver oppdatering sendes også med versjonsnummeret agenten leste, slik at en endring et menneske har gjort i mellomtiden, ikke blir overskrevet.

Bildeverktøyet i Munin er designet for en kaller som prøver igjen. En identisk forespørsel innen 15 minutter gir det første bildet tilbake i stedet for å lage et nytt. En agent som tror kallet hang, lager dermed ikke to bilder og to regninger.

Hvorfor må handlinger som ikke kan angres, deles i to?

Handlinger som ikke kan angres, må deles i to operasjoner fordi agenten ellers både bestemmer og utfører i samme kall. På en skjerm er bekreftelsesdialogen designerens verktøy. I et API er verktøyet en forberedende operasjon som returnerer en sammenfatning og et engangsbevis, og en utførende operasjon som krever beviset.

Threll.ai, taleagentene Apps AS utvikler, bruker den modellen for utgående samtaler. Agenten forbereder samtalen og får tilbake en sammenfatning med hvilken agent som ringer, fra hvilket nummer, til hvilket nummer og med hvilket manus. Samtalen ringes først når noen bekrefter med beviset. Hvilke handlinger som bør deles slik, er gjennomgått i Hvilke prosesser tåler automatisering?

Hva skal systemet gjøre med det det ikke forstår?

Systemet skal si fra når det får noe det ikke forstår. Et skjema kan gjøre et ugyldig valg umulig. Et API får det kalleren sender, og må bestemme hva som skjer med resten.

Artikkelsiden på apps.no viser sju blokktyper. En blokktype siden ikke kjenner, hoppes over uten feilmelding, og innholdet forsvinner fra siden. Valget gjør siden robust, og valget gjør feilen usynlig for agenten som skrev blokken. Den samme kontrakten har to regler til som er laget med vilje: en tallblokk uten forklaring vises ikke i det hele tatt, og et markdown-sitat i brødteksten vises som en faktaboks og ikke som et sitat. Reglene virker bare fordi de står i beskrivelsen agenten leser.

Hva er igjen av skjermdesignet?

Skjermdesignet er igjen der et menneske skal godkjenne, følge med eller ta over. Den flaten brukes sjeldnere og betyr mer. Hvordan maskinflaten og menneskeflaten deler produktet mellom seg, står i Salesforce flyttet grensesnittet ut av produktet. Prisen må flytte etter. Hvordan API-first henger sammen med prismodellen, står i ankerartikkelen Arkitektur, design og pris er samme valg. Hvorfor tegningen er det billigste stedet å endre et teknologivalg, står i Design er der teknologivalget blir billig.

Send oss feltet som oftest blir fylt ut feil

Ta feltet i API-et deres som oftest blir fylt ut feil, og skriv ned beskrivelsen feltet har i dag. Send beskrivelsen og ett eksempel på en feil utfylling til hello@apps.no. Vi svarer med en ny beskrivelse, eller med at feltet heller burde vært obligatorisk.