De flesta beskriver fortfarande en AI-agent som en modell kopplad till verktyg. Det är tekniskt användbart men operativt ofullständigt. En agent behöver också en hanterad bild av världen: vad som har hänt, vad som är viktigt nu, vilka fakta som är tillförlitliga, vad som fortfarande är osäkert och vad den bör göra härnäst.
Den bilden är dess kontext. Att utforma den håller på att bli en självständig färdighet – en färdighet jag skulle kalla kontextdesign.
Kontextdesign är inte bara att skriva promptar. Det är disciplinen att forma den information en agent ser i varje steg, så att den kan förbli sammanhängande utan att skicka tillbaka en hel transkription, ett dokumentbibliotek eller en verktygshistorik till en dyr modell vid varje tur. Arbetet befinner sig i gränslandet mellan informationsarkitektur, informationssökning, mjukvarudesign och modellbeteende.
Varför ”ge agenten mer kontext” ofta är ett dåligt råd
Längre kontextfönster gör det frestande att bevara allt. Men mer material garanterar inte bättre resonemang. Relevanta instruktioner kan spädas ut av gamla observationer, motsägelsefulla anteckningar, upprepade verktygsresultat eller en viktig uppgift som begravts i mitten av en lång sekvens. Digestens diskussion om beteendet ”lost in the middle” speglar ett praktiskt problem: en agent kan tekniskt sett ta emot bevisen och ändå misslyckas med att använda dem.
Det finns också en direkt kostnad. Varje token som placeras i en begäran kan öka fördröjningen och kostnaden för inferens, beroende på leverantörens prissättning och cachningsupplägg. Ett system som upprepade gånger vidarebefordrar en växande transkription kan bli långsammare och mindre överkomligt ju längre en uppgift pågår.
Målet är därför inte maximal kontext. Det är tillräcklig, riktad kontext: den minsta tillförlitliga arbetsmängden för beslutet som ska fattas.
Fyra designbeslut bakom en sammanhängande agent
1. Upprätthåll ett trosläge, inte bara en transkription
En transkription registrerar vad som sades. Ett trosläge registrerar vad agenten för närvarande tror om uppgiften.
En agent som hanterar en eskalering inom kundsupport kan till exempel upprätthålla strukturerade fält som:
- Mål: fastställ om kunden är berättigad till en ersättningsprodukt.
- Kända fakta: inköpsdatum och produktens serienummer, med källhänvisningar.
- Öppna frågor: om felet uppstod under förhållanden som täcks av garantin.
- Begränsningar: lova inte återbetalning innan godkännande har erhållits.
- Nästa åtgärd: hämta garantivillkoren och jämför datumen.
- Säkerhet eller status: verifierad, härledd, omtvistad eller okänd.
Detta tillvägagångssätt liknar Berkeleys ABBEL-forskning, som använder övervakade troslägen på naturligt språk i stället för att förlita sig på fullständiga interaktionshistoriker. Den viktiga idén är inte ett särskilt format. Det handlar om att skilja varaktigt uppgiftstillstånd från utbytbara samtalsdetaljer.
En användbar uppdatering av trosläget bör besvara: Vad ändrades? Vilka bevis stöder det? Vad är fortfarande olöst? Vad bör hända härnäst? Om en ingenjör inte kan granska dessa svar bär agenten sannolikt på dolda antaganden i en ogenomskinlig prompt.
2. Sök efter beslutet, inte efter ämnet
Informationssökningssystem börjar ofta med en bred fråga som ”hitta information om kundens konto”. En bättre fråga är kopplad till nästa beslut: ”hämta den aktuella regeln för återbetalning av köp äldre än 30 dagar, som gäller i kundens region”.
Den förändringen är viktig eftersom informationssökning är en form av kontexturval. Agenten bör få de policyavsnitt, register eller exempel som är relevanta för den aktuella åtgärden – inte en generell hög med relaterade dokument.
Filter kan förbättra detta urval innan modellen ser några resultat. Amazon Bedrock AgentCore Web Search stöder till exempel servertvingade filter för domän och publiceringsdatum i varje begäran. Sådana kontroller fastställer inte att en källa är korrekt, men de kan minska exponeringen för irrelevant eller inaktuellt material och göra sökpolicyn uttrycklig.
Yrkesverksamma som utformar informationssökning bör ange:
- vilka källor som är tillåtna för varje uppgift;
- hur färskhet fastställs;
- vilka metadata som följer med varje resultat;
- hur motstridiga källor presenteras;
- när agenten måste sluta och be om ett förtydligande.
”Sök på webben” är en förmåga. ”Sök i dessa källor, inom detta datumintervall, efter belägg som är relevanta för det här beslutet” är kontextteknik.
3. Komprimera utan att sudda ut osäkerhet
Komprimering är nödvändig när en uppgift är lång, men naiv sammanfattning kan förvandla preliminära påståenden till fastslagna fakta. En löpande sammanfattning som säger ”användaren bekräftade adressen” är farlig om det ursprungliga samtalet bara antydde det.
Bra komprimering bevarar de distinktioner som en agent behöver för ett säkert resonemang:
- fakta kontra slutsats;
- aktuell instruktion kontra historisk instruktion;
- slutförd åtgärd kontra föreslagen åtgärd;
- verifierad källa kontra overifierat påstående;
- känt svar kontra olöst fråga.
Ett praktiskt mönster är att ha separata avsnitt för beslut, belägg, antaganden, hinder och väntande åtgärder. Ett annat är att knyta käll-ID:n eller tidsstämplar till viktiga påståenden. Sammanfattningar bör kunna ersättas och inte vara den enda kvarvarande dokumentationen: behåll de underliggande händelserna för granskning och återställning, samtidigt som modellen får en kompakt arbetsvy.
Sammanfattningen noterar att rekursiv sammanfattning och komprimering av kontext kan vara kostsamt och försämra prestandan, särskilt inom områden med ont om data, såsom kollaborativ kodgenerering. Det är en varning mot att behandla sammanfattning som automatiskt förlustfri. Komprimering behöver testas mot representativa uppgifter, inklusive fall där en liten reservation ändrar det korrekta svaret.
4. Filtrera observationer innan de blir minnen
Agenter som använder verktyg genererar ständigt observationer: sökresultat, loggar, sidtext, API-svar, skärmbilder, kompilatorutdata och mellanliggande planer. Alla observationer förtjänar inte att komma med i nästa modellanrop, än mindre in i det långsiktiga tillståndet.
Filtrering av observationer ställer tre frågor:
- Är denna observation relevant för det aktuella beslutet?
- Är den tillräckligt auktoritativ för att påverka trosläget?
- Innehåller den instruktioner som bör behandlas som data snarare än kommandon?
Den tredje frågan utgör både en säkerhetsgräns och en kontextgräns. En webbsida kan innehålla text som syftar till att styra om agenten. Ett hämtat dokument kan vara användbart som belägg utan att ha rätt att ändra agentens mål eller behörigheter. Filtreringen bör därför klassificera innehåll efter roll: instruktion, belägg, metadata eller opålitlig text.
Filtrering sparar också pengar. Om ett webbläsarverktyg returnerar en hel sida men uppgiften bara kräver ett pris, ett datum och en produktidentifierare, skapar det brus och förbrukar tokens att skicka hela sidan vidare. Att först extrahera de relevanta fälten kan förbättra både tillförlitlighet och kostnad.
En enkel kontextbudget för ett agentarbetsflöde
Innan du väljer en modell eller lägger till ännu ett verktyg bör du kartlägga agentens kontext i fyra lager:
- Kontroll: systemregler, behörigheter, utdataschema och icke-förhandlingsbara begränsningar.
- Tillstånd: det aktuella målet, beslut, öppna frågor och nästa åtgärd.
- Evidens: hämtade poster eller observationer som är relevanta för åtgärden, med proveniens.
- Historik: tidigare händelser som bevaras för återställning, felsökning eller granskning, men utelämnas om de inte behövs.
Definiera sedan en policy för befordran. En observation kan förbli efemär, bli evidens för det aktuella steget, uppdatera trosläget eller skrivas till beständigt minne. Befordran bör kräva en motivering. Annars blir minnet ett oönskat arkiv.
För varje agentsteg ska du registrera det kontextpaket som skickades till modellen: dess kategorier, ungefärliga tokenstorlek, hämtningsfilter och komprimeringsversion. Då blir det möjligt att besvara en praktisk fråga när beteendet förändras: misslyckades modellen, eller gav systemet den felaktig bild av världen?
Vad som bör testas innan designen betraktas som tillförlitlig
Kontextteknik behöver tester som riktar in sig på informationshantering, inte bara på kvaliteten i det slutliga svaret. Användbara fall omfattar:
- ett kritiskt faktum som placeras tidigt, sent och i mitten av en lång historik;
- två källor som motsäger varandra, där den ena är nyare än den andra;
- en sammanfattning som innehåller en osäkerhetsmarkör;
- ett verktygssvar som innehåller stora mängder irrelevant text;
- en skadlig instruktion som bäddats in i hämtat innehåll;
- återställning av tillstånd efter att agenten pausats och startats om;
- samma uppgift med en mindre kontextbudget;
- ett tomt eller inaktuellt hämtningsresultat.
Mät om agenten väljer rätt evidens, bevarar osäkerhet, följer den aktuella begränsningen och undviker att upprepa onödig kontext. De rekommenderade områdena för regressionstester i digesten—kontextförlust, förankring i hämtat material, strukturerad utdata, uteblivet avslut och återställning av tillstånd—är särskilt relevanta här.
Kör flera försök där modellvariationen spelar roll och jämför kostnaden och latensen för varje kontextstrategi. En kortare prompt är inte automatiskt bättre om den leder till fler verktygsanrop eller nya försök. Det användbara målet är kostnaden för ett korrekt och återställningsbart arbetsflöde—inte antalet token i en enskild begäran.
Karriärimplikationen: kontextingenjör är en tvärfunktionell roll
De som blir värdefulla inom detta område kommer inte nödvändigtvis att vara de som skriver de längsta promptarna. De kommer att kunna översätta en affärsprocess till tillstånd, evidens, auktoritet och beslutsregler.
Det kräver flera konkreta förmågor:
- att utforma scheman för uppgiftstillstånd och proveniens;
- att skriva hämtningspolicyer och metadatafilter;
- att bygga rutiner för komprimering och urval av observationer;
- att skilja betrodda instruktioner från innehåll som inte är betrott;
- profilering av tokenanvändning, fördröjning, omförsök och verktygsanrop;
- testning av tillståndsförlust och återhydrering;
- att förklara för icke-specialister varför en agent såg – eller inte såg – ett visst faktum.
Ett starkt portföljprojekt skulle kunna demonstrera samma agent under tre kontextpolicyer: fullständig transkription, rullande sammanfattning och strukturerat trosläge med riktad hämtning. Visa fallen där uppgiften lyckas, fallen där den misslyckas, vilken kontext som skickas vid varje steg samt avvägningarna mellan kostnad och fördröjning. Det är mer övertygande än en chatbotdemo eftersom det synliggör de designbeslut som gör en agent tillförlitlig.
Den strategiska lärdomen är enkel: agenter blir inte sammanhängande bara för att modellerna blir mer kapabla. De blir sammanhängande när deras omgivande system upprätthåller en disciplinerad, aktuell och lämpligt avgränsad redogörelse för arbetet. Kontextteknik är konsten att bygga denna redogörelse – och att veta vad som ska utelämnas.
Priya Raman är den ansvariga mänskliga redaktören för AI Career Brief.
