De fleste beskriver fortsatt en AI-agent som en modell koblet til verktøy. Det er teknisk nyttig, men operasjonelt ufullstendig. En agent trenger også et administrert bilde av verden: hva som har skjedd, hva som betyr noe nå, hvilke fakta som er pålitelige, hva som fortsatt er usikkert, og hva den bør gjøre videre.
Dette bildet er konteksten. Å utforme den er i ferd med å bli en egen ferdighet – en jeg vil kalle kontekstutvikling.
Kontekstutvikling er ikke bare å skrive instrukser. Det er disiplinen det er å forme informasjonen en agent ser på hvert trinn, slik at den kan forbli sammenhengende uten å sende en hel samtaletranskripsjon, et dokumentbibliotek eller en verktøyhistorikk tilbake til en kostbar modell ved hver tur. Arbeidet befinner seg mellom informasjonsarkitektur, gjenfinning, programvaredesign og modellatferd.
Hvorfor «gi agenten mer kontekst» ofte er et dårlig råd
Lengre kontekstvinduer gjør det fristende å ta vare på alt. Men mer materiale garanterer ikke bedre resonnering. Relevante instrukser kan drukne i utdaterte observasjoner, motstridende notater, gjentatte verktøyutdata eller et viktig faktum som ligger begravd midt i en lang sekvens. Diksjonariets omtale av «lost in the middle»-atferd gjenspeiler et praktisk problem: En agent kan teknisk sett motta bevisene og likevel mislykkes i å bruke dem.
Det finnes også en direkte kostnad. Hvert token som legges inn i en forespørsel, kan øke ventetiden og kostnadene ved inferens, avhengig av leverandørens priser og ordninger for hurtigbufring. Et system som gjentatte ganger videresender en voksende transkripsjon, kan bli tregere og mindre kostnadseffektivt etter hvert som oppgaven fortsetter.
Målet er derfor ikke maksimal kontekst. Det er tilstrekkelig, målrettet kontekst: det minste pålitelige arbeidssettet for beslutningen som skal tas.
Fire designbeslutninger bak en sammenhengende agent
1. Oppretthold en tilstand for antakelser, ikke bare en transkripsjon
En transkripsjon registrerer det som ble sagt. En tilstand for antakelser registrerer det agenten for øyeblikket tror om oppgaven.
En agent som håndterer en eskalert kundestøttesak, kan for eksempel opprettholde strukturerte felt som:
- Mål: avklare om kunden kvalifiserer for et erstatningsprodukt.
- Kjente fakta: kjøpsdato og produktets serienummer, med kildehenvisninger.
- Åpne spørsmål: om feilen oppsto under forhold som dekkes av garantien.
- Begrensninger: ikke love refusjon før godkjenning.
- Neste handling: hente garantivilkårene og sammenligne datoene.
- Sikkerhet eller status: bekreftet, utledet, omstridt eller ukjent.
Denne tilnærmingen ligner Berkeleys ABBEL-forskning, som bruker overvåkede beløpstilstander på naturlig språk i stedet for å basere seg på fullstendige interaksjonshistorikker. Den viktige ideen er ikke et bestemt format. Det er å skille varig oppgavetilstand fra samtaledetaljer som kan kastes.
En nyttig oppdatering av tilstanden for antakelser bør svare på: Hva endret seg? Hvilke bevis støtter det? Hva er fortsatt uavklart? Hva bør skje videre? Hvis en ingeniør ikke kan undersøke disse svarene, bærer agenten sannsynligvis skjulte antakelser i en ugjennomsiktig instruks.
2. Hent informasjon for beslutningen, ikke for temaet
Gjenfinningssystemer begynner ofte med et bredt spørsmål som «finn informasjon om kundens konto». Et bedre søk er knyttet til den neste beslutningen: «hent den gjeldende refusjonsregelen for kjøp som er eldre enn 30 dager, og som gjelder i kundens region».
Dette skiftet er viktig fordi gjenfinning er en form for kontekstutvelgelse. Agenten bør motta policyavsnittene, oppføringene eller eksemplene som er relevante for den aktuelle handlingen – ikke en generell bunke relaterte dokumenter.
Filtre kan forbedre dette utvalget før modellen ser noen resultater. Amazon Bedrock AgentCore Web Search støtter for eksempel serverhåndhevede filtre for domene og publiseringsdato i hver forespørsel. Slike kontroller fastslår ikke at en kilde er korrekt, men de kan redusere eksponeringen for irrelevant eller utdatert materiale og gjøre gjenfinningsreglene eksplisitte.
Fagfolk som utformer gjenfinning, bør spesifisere:
- hvilke kilder som er tillatt for hver oppgave;
- hvordan ferskhet fastsettes;
- hvilke metadata som følger med hvert resultat;
- hvordan motstridende kilder presenteres;
- når agenten må stoppe og be om en avklaring.
«Søk på nettet» er en egenskap. «Søk i disse kildene, innenfor dette datointervallet, etter dokumentasjon som er relevant for denne beslutningen» er kontekstutforming.
3. Komprimer uten å viske ut usikkerhet
Komprimering er nødvendig når en oppgave er lang, men naiv oppsummering kan gjøre foreløpige påstander om til fastslåtte fakta. En løpende oppsummering som sier «brukeren bekreftet adressen», er farlig hvis den opprinnelige utvekslingen bare antydet det.
God komprimering bevarer skillene en agent trenger for trygg resonnering:
- faktum versus slutning;
- gjeldende instruksjon versus historisk instruksjon;
- utført handling versus foreslått handling;
- verifisert kilde versus ubekreftet påstand;
- kjent svar versus uavklart spørsmål.
Et praktisk mønster er å opprettholde separate seksjoner for beslutninger, dokumentasjon, antakelser, hindringer og ventende handlinger. Et annet er å knytte kilde-ID-er eller tidsstempler til viktige påstander. Oppsummeringer bør kunne erstattes, ikke være den eneste gjenværende dokumentasjonen: behold de underliggende hendelsene for revisjon og gjenoppretting, samtidig som modellen får et kompakt arbeidsbilde.
Sammendraget påpeker at rekursiv oppsummering og komprimering av kontekst kan være kostbart og kan svekke ytelsen, særlig på områder med lite data, som samarbeidende kodegenerering. Det er en advarsel mot å behandle oppsummering som automatisk tapsfri. Komprimering må testes mot representative oppgaver, inkludert tilfeller der en liten presisering endrer det riktige svaret.
4. Filtrer observasjoner før de blir til minner
Agenter som bruker verktøy, genererer hele tiden observasjoner: søkeresultater, logger, sidetekst, API-svar, skjermbilder, kompilatorutdata og mellomliggende planer. Ikke alle observasjoner fortjener å bli med i neste modellkall, og enda færre bør inngå i langtidsstatusen.
Observasjonsfiltrering stiller tre spørsmål:
- Er denne observasjonen relevant for den aktuelle beslutningen?
- Er den tilstrekkelig autoritativ til å påvirke trostilstanden?
- Inneholder den instruksjoner som bør behandles som data snarere enn kommandoer?
Det tredje spørsmålet er en sikkerhetsgrense så vel som en kontekstgrense. En nettside kan inneholde tekst som forsøker å styre agenten i en annen retning. Et innhentet dokument kan være nyttig dokumentasjon uten å ha myndighet til å endre agentens mål eller tillatelser. Filtreringen bør derfor klassifisere innhold etter rolle: instruksjon, dokumentasjon, metadata eller upålitelig tekst.
Filtrering sparer også penger. Hvis et nettleserverktøy returnerer en hel side, men oppgaven bare krever en pris, dato og produktidentifikator, skaper det støy og bruker opp tokens å sende hele siden videre. Å trekke ut de relevante feltene først kan forbedre både påliteligheten og kostnadene.
Et enkelt kontekstbudsjett for en arbeidsflyt med en agent
Før du velger en modell eller legger til et nytt verktøy, bør du kartlegge agentens kontekst i fire lag:
- Kontroll: systemregler, tillatelser, utdataformat og ufravikelige begrensninger.
- Status: det gjeldende målet, beslutninger, åpne spørsmål og neste handling.
- Bevis: innhentede opplysninger eller observasjoner som er relevante for handlingen, med kildeopprinnelse.
- Historikk: tidligere hendelser som er bevart for gjenoppretting, feilsøking eller revisjon, men utelatt med mindre de trengs.
Definer deretter en policy for promotering. En observasjon kan forbli flyktig, bli bevis for det gjeldende trinnet, oppdatere trostilstanden eller skrives til varig minne. Promotering bør kreve en begrunnelse. Ellers blir minnet et ustrukturert arkiv.
For hvert agenttrinn bør du registrere kontekstpakken som ble sendt til modellen: kategoriene, omtrentlig tokenstørrelse, hentefiltre og komprimeringsversjon. Da blir det mulig å besvare et praktisk spørsmål når atferden endres: feilet modellen, eller ga systemet den feil virkelighetsforståelse?
Hva som bør testes før du anser designet som pålitelig
Kontekstutforming trenger tester som retter seg mot informasjonshåndtering, ikke bare kvaliteten på det endelige svaret. Nyttige tilfeller omfatter:
- et kritisk faktum plassert tidlig, sent og midt i en lang historikk;
- to kilder som er uenige, der den ene er nyere enn den andre;
- et sammendrag som inneholder en usikkerhetsmarkør;
- et verktøysvar som inneholder store mengder irrelevant tekst;
- en ondsinnet instruksjon innebygd i innhentet innhold;
- gjenoppretting av tilstand etter at agenten er satt på pause og startet på nytt;
- den samme oppgaven med et mindre kontekstbudsjett;
- et tomt eller utdatert henteresultat.
Mål om agenten velger riktige bevis, bevarer usikkerhet, følger den gjeldende begrensningen og unngår å gjenta unødvendig kontekst. De anbefalte områdene for regresjonstesting i sammendraget – tap av kontekst, forankring i innhentet informasjon, strukturert utdata, manglende avslutning og gjenoppretting av tilstand – er spesielt relevante her.
Kjør flere forsøk der modellvariasjon har betydning, og sammenlign kostnaden og latenstiden for hver kontekststrategi. En kortere forespørsel er ikke automatisk bedre hvis den fører til flere verktøykall eller nye forsøk. Det nyttige målet er kostnaden ved en korrekt arbeidsflyt som kan gjenopprettes – ikke tokenantallet i én forespørsel.
Karrieremessig innebærer dette at kontekstingeniør er en tverrfunksjonell rolle
De som blir verdifulle på dette området, vil ikke nødvendigvis være de som skriver de lengste instruksjonene. De vil kunne oversette en forretningsprosess til tilstand, bevis, autoritet og beslutningsregler.
Det krever flere konkrete ferdigheter:
- utforme skjemaer for oppgavetilstand og kildeopprinnelse;
- skrive retningslinjer for innhenting og metadatafiltre;
- bygge rutiner for komprimering og utvelgelse av observasjoner;
- skille mellom pålitelige instruksjoner og upålitelig innhold;
- profilering av tokenbruk, ventetid, nye forsøk og verktøykall;
- testing av tap av tilstand og gjenoppretting;
- å forklare for ikke-spesialister hvorfor en agent så – eller ikke så – et bestemt faktum.
Et sterkt porteføljeprosjekt kan demonstrere den samme agenten under tre kontekstpolicyer: fullstendig transkripsjon, løpende sammendrag og en strukturert antakelsestilstand med målrettet gjenfinning. Vis tilfellene der oppgaven lykkes, tilfellene der den mislykkes, konteksten som sendes ved hvert trinn, samt avveiningene mellom kostnad og ventetid. Det er mer overbevisende enn en chatbotdemonstrasjon fordi det synliggjør designbeslutningene som gjør en agent pålitelig.
Den strategiske lærdommen er enkel: Agenter blir ikke koherente bare fordi modellene blir mer kapable. De blir koherente når systemene rundt dem opprettholder en disiplinert, oppdatert og hensiktsmessig dimensjonert oversikt over arbeidet. Kontekstutvikling er håndverket med å bygge denne oversikten – og å vite hva som skal utelates.
Priya Raman er den ansvarlige menneskelige redaktøren for AI Career Brief.
