Mens debatten om AI-agenter ofte ender i modelvalg, peger en ny udviklerguide på et andet fokus. Ifølge guiden fra Machine Learning Mastery opstår problemer i produktion sjældent på grund af modellen alene. Kilden formulerer det mere præcist sådan, at problemet oftere er et kontekstvindue, der bliver styret dårligt. Det gør context engineering til et centralt emne, ikke bare et ekstra lag promptarbejde.
Guiden definerer context engineering som praksissen med at afgøre, hvad der kommer ind i modelens kontekstvindue, hvad der skal komprimeres, hvad der skal hentes ved behov, og hvad der helt skal udelades. Den definition er ret konkret. Den flytter opmærksomheden væk fra idéen om, at mere information automatisk giver bedre svar. Ifølge kilden handler det i stedet om at holde hvert token så relevant som muligt.
Machine Learning Mastery skriver også, at god context engineering kan mindske de omkostnings- og kvalitetsproblemer, som følger af naiv akkumulering af kontekst. Det er en vigtig præcisering. Pointen i kilden er ikke bare, at store input er dyre, men at de også kan gøre output dårligere. Derfor bliver spørgsmålet om kontekst i artiklen behandlet som en del af selve agentarkitekturen.
Kontekstvinduet som designparameter
Et af de mest klare udsagn i kildematerialet er, at kontekstvinduet bør behandles som en begrænset ressource og som et primært designparameter. Guiden siger direkte, at kontekstvinduet former de øvrige beslutninger i agentisk arkitektur. Den advarer samtidig mod at se det som en ren teknisk grænse, man bare skal uden om. Den måde at formulere det på gør forskellen tydelig.
Når guiden beskriver dårlig håndtering af kontekstvinduet som en hyppig årsag til problemer i produktion, bliver arkitekturen omkring agenten også mere væsentlig. Det gælder især valg om, hvad der ligger fast i konteksten, og hvad der kun bliver hentet ind, når det er nødvendigt. Det er stadig kildens perspektiv, ikke et tværgående benchmark. Men som forklaring på, hvorfor nogle agentforløb bliver ustabile, er det centralt i materialet.
Guiden kobler det også direkte til akkumulering. Hvis historik, hentede resultater og rå værktøjsoutput bliver ved med at ligge i konteksten, risikerer man ifølge kilden både højere omkostninger og lavere kvalitet. Det er en mere snæver og dokumenteret pointe end brede konklusioner om hele markedet. Til gengæld er den skarp.
To slags omkostninger ved tokens
Et andet centralt element i guiden er skellet mellem to typer tokenomkostninger. Den første er finansiel. Machine Learning Mastery skriver, at modeller bliver afregnet per inputtoken, og at det kan skalere hurtigt i agentforløb med flere trin. Det er ligetil.
Den anden type omkostning beskrives i kilden som kognitiv. Her er pointen, at modellen ikke behandler alle tokens ens. Guiden forklarer, at opmærksomheden typisk prioriterer information i begyndelsen og slutningen af konteksten, mens indhold midt i konteksten ofte er mindre indflydelsesrigt. Derfor kan lange eller dårligt strukturerede input svække ræsonnering, selv når de holder sig inden for tokengrænsen.
Det er en vigtig del af guidens argument. Mere tekst er ikke i sig selv et plus. Hvis input er dårligt struktureret, kan ekstra tekst tværtimod gøre arbejdet sværere for modellen. Kildens skel mellem finansielle og kognitive omkostninger gør derfor context engineering til mere end et spørgsmål om pris.
Placering i konteksten er ikke neutral
Fordi guiden fremhæver, at modeller typisk vægter begyndelsen og slutningen af konteksten højere, får rækkefølgen af information også betydning. Den pointe er direkte understøttet af kildematerialet. Hvis noget vigtigt ligger midt i en lang kontekst, er det ifølge guiden ikke givet, at det får samme vægt som indhold placeret tidligere eller senere.
Det gør promptstruktur og sammensætning af input til et praktisk designvalg i agentarbejde. Kilden går ikke ud i en lang liste af cases, men selve mekanismen er klar nok. Når ikke alle tokens påvirker modellen lige meget, bliver placering en del af det tekniske arbejde med at få agenten til at fungere stabilt.
Her holder guiden sig tæt på struktur frem for generelle løfter. Den siger ikke, at ét bestemt layout løser alt. Men den siger, at lange eller dårligt organiserede input kan forringe ræsonnering, og at opmærksomheden ikke er jævnt fordelt. Det er nok til at gøre kontekststyring til et mere præcist spørgsmål end bare størrelsen på kontekstvinduet.
RAM og disk som forklaring
Machine Learning Mastery bruger en analogi, hvor kontekstvinduet svarer til RAM. Det beskrives som hurtigt og kraftfuldt, men begrænset og tømt mellem sessioner. Ekstern hukommelse, databaser og filsystemer bliver i samme analogi beskrevet som disk. De er større og billigere, men skal hentes ind for at blive aktive i øjeblikket.
Analogiens styrke i artiklen er, at den gør kildens hovedpointe lettere at forstå. Ikke alt bør ligge i den aktive kontekst hele tiden. Nogle oplysninger kan ifølge samme tankegang leve uden for kontekstvinduet og først blive hentet ind, når opgaven kræver det. Det ligger i forlængelse af guidens definition af context engineering som styring af, hvad der kommer med, hvad der komprimeres, og hvad der hentes ved behov.
Den forklaring understøtter også, hvorfor naiv akkumulering bliver et problem i kildens optik. Hvis alt ender i samme aktive kontekst, bliver grænsen mellem arbejdshukommelse og ekstern lagring udvisket. Guiden fremstiller netop det som en fejl i agentdesign, fordi det både kan øge omkostninger og svække kvalitet.
Hvorfor emnet fylder i AI-agenter
IBM beskriver AI-agenter som systemer, der autonomt udfører opgaver ved at designe workflows med tilgængelige værktøjer. Samme IBM-kilde nævner enterprise-anvendelser som softwaredesign, IT-automatisering, kodegenerering og samtaleassistance. De to udsagn siger ikke i sig selv noget om context engineering, men de viser, at agentbegrebet ofte handler om systemer, der arbejder på tværs af værktøjer og opgaver.
Det giver en relevant ramme om Machine Learning Masterys guide. Når AI-agenter arbejder gennem workflows og værktøjer, bliver spørgsmålet om, hvilken information der er aktiv i konteksten, mere centralt. Det er stadig Machine Learning Mastery, der leverer argumentet om mismanaged context window. IBM-kilden bruges her kun til at afgrænse, hvad slags systemer der er tale om.
Sammen læst peger kilderne altså på, at AI-agenter ikke kun er sprogmodeller, der svarer på tekst. De er systemer, der kan arbejde med værktøjer og flere trin. Og i den type opsætning bliver styringen af konteksten ifølge udviklerguiden et bærende spørgsmål.
IBM positionerer Bob omkring omkostninger og governance
En separat kilde fra Artificial Intelligence News omtaler IBMs lancering af Bob som en platform, der skal hjælpe med at regulere softwareleveringsomkostninger og governance i softwareudviklingslivscyklussen. Det er en konkret produktpositionering. Det dokumenterer ikke i sig selv en bred markedsbevægelse, men det viser, hvordan IBM vælger at beskrive en del af værdien i sin platform.
Set sammen med IBMs egen beskrivelse af AI-agenter giver det et supplerende billede af, at agent- og AI-platforme også bliver koblet til styring og kontrol i softwareudvikling. Her er det vigtigt at holde kilderne adskilt. Bob-kilden dokumenterer IBMs lancering og dens formål, ikke generelle kundekrav på tværs af branchen.
Det mest nøgterne er derfor at sige, at IBM placerer Bob omkring omkostningsstyring og governance i SDLC. Mere end det kan kilden ikke bære. Men som støttepunkt ved siden af udviklerguidens fokus på disciplin i konteksten er det stadig relevant at have med.
Hvad der står tilbage efter kildetjek
Når man skærer de brede generaliseringer væk, står der stadig en ret klar historie tilbage. Machine Learning Mastery argumenterer for, at problemer i AI-agenter ofte hænger sammen med dårlig styring af kontekstvinduet. Guiden definerer context engineering som arbejdet med at vælge, komprimere, hente og udelade information. Og den understreger, at kontekstvinduet bør behandles som en begrænset ressource og et centralt designparameter.
Guiden giver også en mere præcis forklaring på, hvorfor det betyder noget. Tokens har både en finansiel og en kognitiv omkostning. Modeller vægter typisk begyndelsen og slutningen af konteksten højere end midten. Og RAM-disk-analogien bruges til at forklare, hvorfor ikke alt bør ligge i den aktive kontekst hele tiden.
Det gør ikke context engineering til et universelt svar på alle agentproblemer. Den pointe bærer kilderne ikke. Men de bærer klart et mere afgrænset udsagn: at styring af kontekst er en central del af at holde AI-agenter pålidelige, omkostningseffektive og præcise i produktion. Det er mindre bombastisk. Også mere holdbart.
