Kontext, inte kontroll
Varje regel i din agents prompt började som en bugg.
Någon såg ett dåligt beteende, skrev en regel och gick vidare. Någon annan gjorde samma sak. En tredje person lade till ett "gör aldrig X" eftersom modellen gjorde något konstigt en tisdag. Ingen tog bort något.
Sex månader senare ägnar agenten mer av sitt kontextfönster åt att navigera sin regelbok än åt att tänka på den faktiska uppgiften.
Det är kontrolltänkande. Och jag anser att det är ett av de största designmisstagen team gör när de bygger AI-agenter.
Ett litet exempel som avslöjar ett större mönster
Vi stötte på ett problem där en agent som utlösts av en schemalagd uppgift fortsatte att skapa nya schemalagda uppgifter inifrån körningen. Oändlig rekursion, men med verkliga konsekvenser.
Två sätt att svara.
Kontrollstil: Förbjud det. Skriv kod som blockerar scheman från att skapa scheman. Lägg till en promptregel: "skapa aldrig ett schema inuti ett schema." Leverera det.
Kontextstil: Berätta för agenten vad som faktiskt händer.
Du utlöstes av en schemalagd uppgift kl. 3:00 AM Pacific time. Schema-ID: sched_29x8f. En schemalagd körning är en isolerad exekvering med ett definierat omfång som användaren ursprungligen godkände. Att skapa en ny schemalagd uppgift skulle utöka det omfånget bortom det ursprungliga godkännandet.
Det första tillvägagångssättet lappar ett beteende. Det andra ger agenten en modell av situationen.
Nu kan den resonera kring närliggande frågor också: Ska jag skicka en avisering kl. 3 AM? Ska jag skapa en uppföljningsprocess som användaren inte uttryckligen bett om? Ska jag ändra något som sträcker sig bortom den ursprungliga körningens omfång?
Ingen regel behövs. Agenten räknade ut det själv.
Många team väljer kontroll när de egentligen behöver kontext.
Samma skillnad syns i promptar
Det handlar inte bara om systemnivåns efterlevnad. Skillnaden mellan kontext och kontroll finns även i promptar.
Kontextstil i promptar: mestadels fakta, minimala åsikter:
Du körs på grund av en schemalagd uppgift. Utlöst kl. 3:00 AM Beijing time. Uppgifts-ID: sched_29x8f. Användaren godkände denna körning för ett specifikt omfång.
Kontrollstil i promptar: åsiktsdriven, föreskrivande:
Undvik att skapa scheman. Du bör meddela användaren med verktyg X. Gör aldrig Y om inte Z.
Ibland är föreskrivande instruktioner användbara. Men ofta kompenserar de för saknade fakta. Och när du väl börjar kompensera på det sättet blir det beroendeframkallande.
Hur promptar blir byråkrati
Detta är det djupare felmönstret.
Ett team ser ett problem och lägger till en regel. Sedan en till. Och en till. Varje regel lappar ett lokalt problem, men tillsammans skapar de ett system fullt av proxies.
Bezos beskrev detta mönster i sitt 2016-brev till aktieägarna: en bra process tjänar dig så att du kan tjäna kunder. Men om du inte är försiktig blir processen själva saken.
Det är exakt vad som händer i agentsystem.
Regeln är inte saken. Regeln är en proxy för det resultat du vill ha. Och proxies ackumuleras. En skapar undantag som kräver fler. Snart resonerar agenten genom lager av ackumulerade instruktioner, var och en tillagd av någon historisk anledning som ingen längre minns.
I mänskliga organisationer blir detta byråkrati. I agentsystem blir det en gigantisk prompt full av ärrvävnad.
Fakta åldras. Åsikter ruttnar.
Ett faktum som "denna körning utlösts av en schemalagd uppgift kl. 3 AM" är stabilt. Det förblir sant oavsett vilken modell som läser det: Claude, GPT, Gemini, vad som än lanseras nästa kvartal.
Ett påstående som "du bör undvika att skapa underscheman" är skört. Det beror på tolkning. Det kan hjälpa i en situation och tyst misslyckas i en annan.
När du byter modell är varje åsikt i din prompt en potentiell mina. Den nya modellen har andra resonemangstendenser, och din noggrant kalibrerade "undvik" kan betyda något helt annat för den.
Men förankrade fakta om miljö, behörigheter, omfång och begränsningar tenderar att generaliseras över modeller och undantagsfall. Därför är fakta bättre byggmaterial.
Modellquirk-fällan
Detta kan vara den mest lömska versionen av kontrollproblemet: team gör ständigt tillfälliga modellfel till permanent systemstruktur.
En modell beter sig dåligt i ett smalt fall. Teamet lägger till ett skydd: en promptlapp, en kodkontroll, en konstig gren som bara finns för att stoppa ett specifikt felmönster.
Den lappen är ett vad om att egenheten kommer att bestå. Det gör den nästan aldrig.
Tre månader senare ändras modellen. Det ursprungliga beteendet försvinner. Men lappen finns kvar. Ingen vill ta bort den, för kanske fanns den där av en anledning.
Så blir systempromptar till legacy-kod.
Vi kan lätt känna igen faran när den beskrivs abstrakt. Men i praktiken är det samma mönster att lappa Sonnets nuvarande resonemangstendenser i prompt efter prompt.
Att dokumentera stabilt systembeteende är värdefullt. Att lappa en modells resonemangstendenser är ett ekorrhjul. Modellen kommer att förändras snabbare än du kan underhålla dina lappar.
Ett bra testfall: Åtkomst nekad
Du kan tydligt se skillnaden i verktygsdiagnostik. När en agent stöter på ett behörighetsfel:
Kontrollstil:
TOKEN saknas. Kör "zero permissions request gmail.send" för att åtgärda det.
Direkt, men agenten lär sig inget. Nästa gång den stöter på ett annat behörighetsfel är den fast.
Kontextstil:
process.env.GMAIL_TOKEN → finns zero connectors inspect gmail → ansluten zero permissions inspect gmail.send → nekad
Alternativ:
- Begär användarens godkännande för gmail.send
- Använd en redan godkänd väg om en sådan finns
Nu vet agenten att token finns, anslutningen fungerar och den specifika behörigheten är nekad. Den förstår systemets tillstånd och kan resonera kring nya situationer som regelmakaren aldrig förutsåg.
Heuristiken
Det här är vad jag alltid återkommer till:
Varje gång du är på väg att skriva "inte", "undvik" eller "aldrig" i en prompt. Stanna. Fråga: vilket faktum kompenserar denna regel för?
Ofta finns det ett saknat faktum. Agenten förstår inte vilken miljö den befinner sig i, vad användaren godkänt, vilka åtgärder som är oåterkalleliga eller varför denna körning skiljer sig från en vanlig chattinteraktion.
Skriv ner det faktumet. Ta bort regeln.
Ibland vill du ändå ha begränsningen, särskilt kring destruktiva åtgärder, penningrörelser eller säkerhetsgränser. Hårda kontroller är fortfarande viktiga.
Men många promptregler är inte verkliga gränser. De kompenserar för bristande förståelse. Och det är just de som samlas på hög och ruttnar.
Målet
Målet är inte en agent som memorerar en checklista.
Målet är en agent som förstår sin situation tillräckligt väl för att fatta bra beslut inom tydliga gränser.
En filosofi styr beteende genom att stapla regler. Den andra förbättrar beteendet genom att göra världen begriplig.
Den första leder mot byråkrati. Den andra mot förståelse.
Bygg kontext. Ta bort ärrvävnaden. Leverera agenter som kan tänka.
