Kontekst, ikke kontroll
Hver regel i agentens prompt startet som en feil.
Noen så dårlig oppførsel, skrev en regel, gikk videre. En annen gjorde det samme. En tredje la til en «aldri gjør X» fordi modellen gjorde noe rart en tirsdag. Ingen slettet noe.
Seks måneder senere bruker agenten mer av sitt kontekstvindu på å navigere regelboken enn på å løse selve oppgaven.
Det er kontrolltenkning. Og jeg mener det er en av de største designfeilene team gjør når de bygger AI-agenter.
Et lite eksempel som avslører et større mønster
Vi støtte på et problem der en agent utløst av en planlagt oppgave stadig opprettet nye planlagte oppgaver fra innsiden av kjøringen. Uendelig rekursjon, men med reelle konsekvenser.
To måter å svare på.
Kontrollstil: Forby det. Skriv kode som blokkerer tidsplaner fra å opprette nye tidsplaner. Legg til en promptregel: «aldri opprett en tidsplan inne i en tidsplan.» Ferdig.
Kontekststil: Fortell agenten hva som faktisk skjer.
Du ble utløst av en planlagt oppgave kl. 3:00 AM Pacific tid. Tidsplan-ID: sched_29x8f. En planlagt kjøring er en isolert utførelse med et definert omfang brukeren opprinnelig godkjente. Å opprette en ny planlagt oppgave vil utvide dette omfanget utover den opprinnelige godkjenningen.
Den første tilnærmingen lapper én oppførsel. Den andre gir agenten en modell av situasjonen.
Nå kan den også resonnere rundt nærliggende spørsmål: Bør jeg sende en varsling kl. 3 AM? Bør jeg opprette en oppfølgingsprosess brukeren ikke eksplisitt ba om? Bør jeg endre noe som strekker seg utover den opprinnelige kjøringens omfang?
Ingen regel nødvendig. Agenten fant ut av det selv.
Mange team velger kontroll når de egentlig trenger kontekst.
Det samme skillet finnes inne i promptene
Dette handler ikke bare om systemnivå-håndheving. Skillet mellom kontekst og kontroll finnes også inne i promptene.
Kontekstbasert prompting: mest fakta, minimalt med meninger:
Du kjører fordi en planlagt oppgave utløste deg. Utløst kl. 3:00 AM Beijing tid. Oppgave-ID: sched_29x8f. Brukeren godkjente denne kjøringen for et spesifikt omfang.
Kontrollbasert prompting: meningspreget, foreskrivende:
Unngå å opprette tidsplaner. Du bør varsle brukeren med verktøy X. Aldri gjør Y med mindre Z.
Noen ganger er foreskrivende instruksjoner nyttige. Men ofte kompenserer de for manglende fakta. Og når du først begynner å kompensere slik, blir det fort en vane.
Hvordan prompts blir byråkrati
Dette er den dypere feilen.
Et team ser et problem og legger til en regel. Så en til. Og en til. Hver lapp løser et lokalt problem, men sammen skaper de et system fullt av prokser.
Bezos beskrev dette mønsteret i sitt 2016-aksjonærbrev: gode prosesser tjener deg slik at du kan tjene kundene. Men hvis du ikke er forsiktig, blir prosessen selve målet.
Det er akkurat det som skjer i agentsystemer.
Regelen er ikke målet. Regelen er en proxy for det utfallet du ønsker. Og prokser hoper seg opp. Én skaper spesialtilfeller som krever flere. Snart resonerer agenten gjennom lag på lag med akkumulerte instruksjoner, hver lagt til av en historisk grunn ingen helt husker.
I menneskelige organisasjoner blir dette byråkrati. I agentsystemer blir det en kjempestor prompt full av arrvev.
Fakta eldes. Meninger råtner.
Et faktum som «denne kjøringen ble utløst av en planlagt oppgave kl. 3 AM» er stabilt. Det forblir sant uansett hvilken modell som leser det: Claude, GPT, Gemini, eller hva som kommer neste kvartal.
En uttalelse som «du bør unngå å opprette undertidsplaner» er skjør. Den avhenger av tolkning. Den kan hjelpe i én situasjon og feile stille i en annen.
Når du bytter modell, er hver mening i prompten en potensiell landmine. Den nye modellen har andre resonnementstendenser, og din nøye kalibrerte «unngå» kan bety noe helt annet for den.
Men forankrede fakta om miljø, tillatelser, omfang og begrensninger har en tendens til å generalisere på tvers av modeller og spesialtilfeller. Derfor er fakta bedre byggemateriale.
Modellquirk-fellen
Dette kan være den mest snikende varianten av kontrollproblemet: team gjør midlertidige modellfeil til permanent systemstruktur.
En modell oppfører seg dårlig i et snevert tilfelle. Teamet legger til et rekkverk: en promptlapp, en kodekontroll, en rar gren som bare eksisterer for å stoppe én spesifikk feil.
Den lappen er et veddemål om at særheten vil vare. Det gjør den nesten aldri.
Tre måneder senere endres modellen. Den opprinnelige oppførselen forsvinner. Men lappen blir igjen. Ingen vil fjerne den, for kanskje var den der av en grunn.
Slik blir systemprompter til gammel kode.
Vi kjenner lett igjen faren når den beskrives abstrakt. Men i praksis er det å lappe Sonnet sine nåværende resonnementstendenser i prompt etter prompt det samme mønsteret i forkledning.
Å dokumentere stabil systematferd er verdifullt. Å lappe en modells resonnementstendenser er et hamsterhjul. Modellen vil endre seg raskere enn du kan vedlikeholde lappene dine.
En god test: Tillatelse nektet
Du ser skillet tydelig i verktøydiagnostikk. Når en agent får en tillatelsesfeil:
Kontrollstil:
TOKEN mangler. Kjør «zero permissions request gmail.send» for å fikse det.
Direkte, men agenten lærer ingenting. Neste gang den får en annen tillatelsesfeil, står den fast.
Kontekststil:
process.env.GMAIL_TOKEN → finnes zero connectors inspect gmail → tilkoblet zero permissions inspect gmail.send → nektet
Alternativer:
- Be om brukergodkjenning for gmail.send
- Bruk en allerede godkjent vei hvis en finnes
Agenten vet nå at tokenet finnes, koblingen fungerer, og den spesifikke tillatelsen er nektet. Den forstår systemets tilstand og kan resonnere rundt nye situasjoner regelmakeren aldri forutså.
Heuristikken
Dette er det jeg stadig vender tilbake til:
Hver gang du er i ferd med å skrive «ikke», «unngå» eller «aldri» i en prompt. Stopp. Spør: hvilket faktum kompenserer denne regelen for?
Ofte mangler det et faktum. Agenten forstår ikke hvilket miljø den er i, hva brukeren har godkjent, hvilke handlinger som er irreversible, eller hvorfor denne kjøringen skiller seg fra en vanlig chat.
Skriv ned det faktumet. Slett regelen.
Noen ganger vil du fortsatt ha begrensningen, spesielt rundt destruktive handlinger, pengeflyt eller sikkerhetsgrenser. Harde kontroller er fortsatt viktige.
Men mange promptregler er ikke reelle grenser. De kompenserer for manglende forståelse. Og det er akkurat de som hoper seg opp og råtner.
Målet
Målet er ikke en agent som pugger en sjekkliste.
Målet er en agent som forstår situasjonen godt nok til å ta gode beslutninger innenfor klare rammer.
Én filosofi kontrollerer atferd ved å stable regler. Den andre forbedrer atferd ved å gjøre verden forståelig.
Den første fører mot byråkrati. Den andre mot forståelse.
Bygg kontekst. Fjern arrvevet. Lever AI-agenter som kan tenke.
