##  [Ja eller nej, og ikke andet](/da/node/274)

    *Indsendt af Lennart den man, 7 sep 2026 - 10:39*

  [ ![Ja eller nej, og ikke andet](/sites/default/files/styles/max_1300x1300/public/2026-09/composite_0.png.avif?itok=nj-wSR3K)](/sites/default/files/2026-09/composite_0.png)

Der er to måder at give en AI-agent frie tøjler på, og de er begge forkerte.

Den ene er at lade den spørge om alt. Den bliver ignoreret inden for en uge. Når hver eneste handling kræver en godkendelse, holder mennesket op med at læse godkendelserne — man klikker ja, fordi man altid klikker ja. Det er ikke kontrol, det er en vane, der ser ud som kontrol.

Den anden er at lade den lade være med at spørge. Så kører den, indtil den gør noget, ingen ville have sagt ja til, og så er samtalen om AI i den virksomhed slut i to år.

Det rigtige sted ligger imellem: agenten arbejder, mennesket dømmer — men kun dér, hvor dommen faktisk betyder noget. Problemet er, at der ikke findes noget godt sted at lægge den dom. En mail bliver læst tre timer for sent. En Slack-besked drukner. Et dashboard skal man huske at åbne.

Jeg har brugt et par aftener på at bygge det sted. Det hedder janus, og det kan én ting.

## Formen

Et spørgsmål kommer ind over et API og lander som et kort på telefonen. Man stryger til højre for **ja**, til venstre for **nej**. Den, der spurgte, får svaret.

```
if (janus ask "Deploy til produktion?" --vent | get svar) == "ja" { deploy }

```

Det er hele appen. Der er ikke mere.

Man kan ikke skrive et spørgsmål i brugerfladen. Man kan ikke rette et. Man kan ikke slette et. **Brugerfladen er en dom, aldrig en forfatter.**

Den begrænsning er ikke et fravær af funktioner, jeg ikke nåede. Den er selve pointen, og den har et navn.

## BOSS: mennesket er chefen

Hvis mennesket kan skrive spørgsmålet, kan mennesket også skrive sig frem til det svar, det gerne vil have. Så er dommen ikke længere en dom — den er en forhandling med sig selv.

Ved at gøre appen ude af stand til at forfatte noget bliver rollefordelingen fysisk i stedet for aftalt. Agenten formulerer, hvad den vil gøre. Mennesket siger ja eller nej. Ingen af de to kan lave den andens arbejde, fordi der ikke er nogen knap til det.

Det er en forskel, enhver leder kender fra bestyrelseslokalet. En bestyrelse skriver ikke direktionens indstillinger om undervejs. Den godkender eller afviser dem — og netop dét tvinger direktionen til at formulere sig præcist, fordi der ikke er nogen sikkerhedsnet i form af en velmenende rettelse hen ad vejen. Beslutningsretten bliver skarp af at være smal.

Det samme sker her. En agent, der ved, at den kun får et ja eller et nej, stiller bedre spørgsmål. Den kan ikke sende noget vagt af sted og regne med, at mennesket nok skal præcisere det.

## Den ene skelnen, der betyder mest

Et ubesvaret spørgsmål giver `timeout` og et svar, der er `null` — aldrig `"nej"`.

Det ser ud som en teknisk detalje. Det er den vigtigste linje i hele projektet.

Hvis tavshed blev læst som et nej, ville systemet kunne træffe beslutninger på, at nogen ikke kiggede på deres telefon. En agent, der opgiver, fordi mennesket sad i et møde, har fået lov at fortolke en manglende beslutning som en beslutning. Det er præcis dén fejl, der gør, at folk ikke tør give agenter mandat.

Så: tavshed er ikke et afslag. Et script må hverken handle eller opgive på den. Det må vente, eller det må spørge igen senere, eller det må lægge opgaven fra sig og sige, at der mangler et svar. Alle tre er ærlige. »Han svarede ikke, så jeg gik ud fra nej« er ikke.

Der er en beslægtet regel: et spørgsmål besvares én gang. Svarer man igen, får man en fejl. Ikke fordi et menneske ikke må skifte mening — men fordi den, der spurgte, allerede har handlet på det første svar. Fortrydelse er en ny beslutning, ikke en rettelse af den gamle.

## KISS: hvad der ikke er i appen

Der er ingen brugerkonti. Ingen login. Ingen database med spørgsmål. Ingen node, intet fra npm. Notifikationen til telefonen bærer ingen data overhovedet — den siger kun »der er sket noget«, og appen henter selv, hvad der ligger og venter.

Det sidste var ikke dovenskab. Krypteringen af beskeden er valgfri i standarden, og ved at springe den over passerer der intet om spørgsmålet gennem Googles servere. **Det simple valg var også det sikre valg.** Det sker oftere, end folk tror.

Der er heller ingen tabel med spørgsmål. Der er kun en strøm af hændelser og en ren funktion, der folder dem til en tilstand. Vil man vide, hvad der er sket, spiller man strømmen om. Det er ikke et arkitekturmodeord — det er grunden til, at hele projektionen er 70 linjer, og at man kan smide hele cachen væk uden at miste noget.

Til gengæld er der én ting, der ikke kunne være simpel, og det er værd at kigge på.

## Der hvor det simple ikke rakte

Appen har en delt kode, som skal med på hvert kald. Det er en primitiv løsning, og jeg overvejede at lade være.

Grunden til, at den skulle med, er ikke fortrolighed. Spørgsmålene er ikke hemmelige. Grunden er, at janus findes for, at en agent kan **handle på svaret**. Et ubeskyttet svar er derfor ikke et læk — det er en fjernbetjening. En fremmeds »ja« til *»Deploy til produktion?«* bliver adlydt, som var det ejerens.

Det er den slags, KISS ikke må bruges som undskyldning for. Simpelt er en retning, ikke et alibi. Testen er, om det, man udelader, kan gøre skade — og forskellen på »nogen kan læse mine spørgsmål« og »nogen kan træffe mine beslutninger« er hele forskellen.

Bemærk i øvrigt, at koden ikke siger, *hvem* der svarede. Det er en bevidst handel: den lukker den åbne dør uden at lægge et helt sessionssystem ind i en app, hvis eneste pointe er ét stryg. Den dag et svar skal kunne føres tilbage til en navngiven person, holder handlen ikke længere. Så er det den dag, den skal ændres — ikke før.

## Hvad en virksomhed skal tage med

Det her er en lille app til privat brug. Mekanikken er ikke privat.

- **Giv agenten et mandat, ikke et spørgeskema.** Beslut på forhånd, hvad den må gøre selv, og hvad der kræver et menneske. En agent, der spørger om alt, bliver godkendt blindt.
- **Læg beslutningen dér, hvor mennesket faktisk er.** Ikke i et system, man skal huske at åbne. Kontrol, der kræver disciplin, er ikke kontrol.
- **Adskil det at formulere fra det at godkende.** Hvis den, der godkender, kan omskrive det, der godkendes, er godkendelsen ikke værd at have.
- **Tavshed er ikke et svar.** Byg aldrig et system, der læser en manglende beslutning som en beslutning. Det er den fejl, der koster tillid, og den koster den kun én gang.
- **Spørg, hvad der sker, hvis en fremmed svarer.** Er svaret »ingenting«, kan sikkerheden være løs. Er svaret »så deployer vi«, er beslutningen lige så følsom som en adgangskode.
- **Lad det simple vinde, indtil det gør skade.** Ikke længere, men heller ikke kortere.

## Til sidst

Diskussionen om AI-agenter i virksomheder handler næsten altid om, hvad agenten kan. Det er det mindst interessante spørgsmål. De kan allerede rigeligt.

Det interessante er, hvor beslutningsretten ligger, og om den ligger et sted, hvor den bliver brugt. En agent uden et menneske over sig er en risiko. Et menneske, der godkender alt uden at læse det, er den samme risiko med et ekstra klik foran.

Det, der virker, er et snævert mandat, en klar grænse og et sted, hvor grænsen kan passeres af et menneske, der faktisk kigger. Det behøver ikke være stort. I mit tilfælde er det et stryg til højre.

Se [Agenter](agenter) for arkitekturen omkring modellen, [Validering](validering) for princippet om lukkede kontrolloops, og [Lederskab](lederskab) for hvorfor mandatet er en ledelsesbeslutning og ikke en teknisk.