Ordet för ögonblicket, i den lilla världen av AI-agenter, är kontextteknik.

Det verkar som om ännu en etikett uppfanns för att sälja något vi redan gjort. Delvis är det så. Men som ofta händer, märks etiketten eftersom den ger namn åt en verklig smärta.

Smärtan är denna: modeller misslyckas inte bara för att de "inte tänker". De misslyckas ofta för att vi skickar dem till jobbet med fel rum.

Vi ger dem gamla instruktioner. Vi gömmer viktiga filer för honom. Vi skickar dokument som är för långa och säger inte vad som är viktigt. Vi visar dem loggar utan prioritet. Vi ger dem tio verktyg utan att förklara när de ska användas. Då blir vi förvånade om agenten rör sig som en person väckt i en okänd lägenhet.

Uppmaningen är den fras du säger till den. Kontexten är den värld du förbereder dig kring den.

Från prompt ingenjörskonst till kontextteknik

Snabb ingenjörskonst var ofta tänkt som att skriva. Välj rätt ord, fråga på rätt sätt, lägg till exempel, ange formatet.

Kontextteknik är närmare arkitektur.

Man frågar inte bara "hur formulerar jag förfrågan?". Den frågar:

• vilken information behövs egentligen?
• vad är buller?
• vad behöver återvinnas i farten?
• vad ska man komma ihåg?
• vilka verktyg ska exponeras?
• vilka instruktioner är stabila och vilka beror på uppgiften?
• hur får jag agenten att förstå vad som är auktoritativt?

Det är en subtil men enorm förändring. För när du arbetar med agenter är sammanhanget inte ett statiskt block. Det förändras vid varje steg.

Agenten öppnar en fil, lär sig något, kör ett test, får ett fel, uppdaterar planen, anropar ett verktyg, upptäcker ett beroende. För varje varv måste han bestämma vad han ska ta med sig och vad han ska lämna utanför.

Det här är ingenjörskonst.

Sammanhanget är inte en deponi

Mallar med stora sammanhangsfönster gav oss en frestelse: låt oss kasta in allt.

Det är förståeligt. Om jag har en miljon tokens, varför ska jag välja?

För även när du kan stoppa in allt betyder det inte att allt hjälper. Ja, buller har en kostnad. Det kostar tokens, det kostar uppmärksamhet, det kostar latens, det kostar kvalitet. En modell kan gå vilse i irrelevanta detaljer precis som vi när vi öppnar tjugo flikar och inte längre kommer ihåg varför.

Bra sammanhang har en hierarki:

1. systeminstruktioner och policyer;
2. Särskilt mål.
3. aktuell status;
4. Relevanta uppgifter.
5. begränsningar;
6. tillgängliga verktyg;
7. spåra redan fattade beslut.

Det finns ingen anledning att behandla allt på samma nivå. Ett användarkommando är värt mer än en gammal anteckning. Ett misslyckat test är nu värt mer än en estetisk preferens från tre månader sedan. En säkerhetspolicy är mer värd än en produktionsgenväg.

Kontextteknik innebär också att ge vikter, inte bara data.

Minne: minns mindre, kom ihåg bättre

Minne hos agenter är ett av de mest hala ämnena.

Som användare vill du att agenten ska känna dig. Du vill att han ska komma ihåg tonen, planen, konventionerna, de saker som redan beslutats. Som ingenjör vet du att varje ihållande minne också är en risk: det kan vara fel, gammalt, för personligt, för generiskt, omöjligt att kontrollera.

Ett användbart minne bör ha minst tre egenskaper:

• härkomst: var kommer denna information ifrån?
• datum: när var det sant?
• syfte: vilken typ av uppgift ska den användas till?

Utan dessa tre saker blir minnet till vidskepelse.

Jag tycker om att tänka på agentminne som en arbetsbok, inte som ett magiskt sinne. Det finns tillfälliga anteckningar, bekräftade beslut, stilpreferenser, tekniska begränsningar, länkar till källor. Vissa saker går ut. Vissa behöver skrivas om. Vissa måste elimineras eftersom agenten missuppfattade dem.

Ett bra system måste göra detta underhåll normalt. Inte heroisk.

Hämtning och verktyg är inte samma sak

När vi pratar om sammanhang hamnar vi ofta direkt på RAG. Inbäddning, vektordatabas, chunking, omrankning.

Alla användbara. Men hämtning är bara ett sätt att föra information till modellen. Han är inte den enda.

En agent kan få sammanhang genom att läsa filer, fråga efter ett API, anropa en MCP-server, öppna en webbläsare, köra tester, söka i Slack, titta på en instrumentpanel, fråga människan.

Det intressanta är att bestämma vilken väg som ska användas och när.

Om agenten behöver svara på en historisk fråga kanske det bara räcker med hämtning. Om han måste fixa en bugg måste han läsa riktig kod. Om han behöver förstå varför en distribution misslyckas måste han titta på nya loggar. Om du behöver skriva till en kund måste du hämta ton, historik och status för biljetten. Om han måste agera i produktionen måste han be om tillstånd.

Kontext är inte en databas. Det är ett arbetsflöde.

Den goda agenten vet också hur man ignorerar

Ett tecken på mognad hos agenter kommer att vara förmågan att säga: Jag behöver inte den här informationen.

Det verkar trivialt, men det är väldigt svårt. Många agentsystem ackumuleras. Varje verktygsanrop lägger till text. Varje fel finns kvar i bufferten. Varje fil som läses läggs till i stacken. I slutändan har modellen en mycket lång historia och ingen karta.

Kompression behövs. Mellansyntes behövs. Det måste struktureras.

Inte "det var allt som hände", utan:

• Målet är fortfarande giltigt.
• aktuell hypotes;
• filer som redan är kontrollerade;
• fattade beslut;
• Öppna risker;
• nästa åtgärd.

Detta gör agenten mindre teatralisk och mer hjälpsam. Inte för att han verkar smartare, utan för att han jobbar med ett städat skrivbord.

Kontextteknik för team, inte för snabba artister

Anledningen till att detta ämne intresserar mig är att det flyttar ansvaret från individen till systemet.

I prompt ingenjörskonst vinner ofta den som bäst kan prata med modellen. I sammanhangsteknik vinner det team som bäst organiserar sitt arbete: dokumentation, konventioner, frågor, loggar, tester, ägande, namngivning, källor.

Ett rent förvar blir ett bättre sammanhang. Ett välskrivet nummer blir bättre bränsle. En uppdaterad runbook sparar tokens och ångest. En tydlig förändringslogg minskar hallucinationer.

Det här är bra och lite obekväma nyheter. Vackert eftersom det belönar bra metoder. Obekvämt eftersom du inte kan lösa allt med en smart uppmaning.

Medlen förstärker hygienen i systemet de hittar.

Hur jag skulle tillämpa det imorgon

Om jag skulle introducera kontextteknik i ett riktigt projekt, skulle jag utgå från små saker:

• en kort och underhållen projektinstruktionsfil;
• Goda exempel på förväntad produktion.
• En lista över tillgängliga verktyg och fall där de ska användas;
• arkitektoniska beslut skrivna på ett citerbart sätt;
• fråga med minsta obligatoriska sammanhang;
• lätt att hämta loggar och tester;
• ihållande minne som kan modifieras av människor.

Då skulle jag mäta en enkel sak: hur många gånger måste agenten be om ett förtydligande eller går i fel riktning?

Om det händer ofta skulle jag inte lägga till en större modell direkt. Jag skulle titta på sammanhanget.

Min läsning

Kontextteknik är lite av ett uppblåst ord, ja. Men konceptet är sunt.

Det påminner oss om att en agents intelligens inte bara finns i modellen. Det ligger i miljön som vi förbereder för honom: vad han ser, vad han minns, vad han kan göra, vad han förbjuds att göra, vilka källor han känner igen som sanna.

Den mänskliga delen är denna: att förbereda sammanhanget väl är en form av omsorg. Det säger till agenten, men också teamet, "Jag vill inte att ni ska gissa, jag vill att ni ska ha det ni behöver."

Mindre magi. Renare rum. Agenter behöver det lika mycket som vi.

Källor

• LangChain Blog: The rise of context engineering
• Simon Willison: Kontextteknik
• Model Context Protocol: Introduction
• Anthropic: Building effective agents
• OpenAI: Nya verktyg för byggagenter