The State of Context Engineering
Posted by pchristensen 3 days ago
Comments
Comment by BenoitEssiambre 3 days ago
There is more to it than just reducing content in context. LLMs attention mechanism works by finding graphs of related words and concepts and it works best when the relevant relationships are close together in the text. Length matters but how well the information is organized matters as well.
It's useful to be familiar with the concept of dependency length. The two sentences in this image ( https://benoitessiambre.com/img/dependencylength.png ) have the same words and same meaning but sentence C is organised to minimize the distance between related words.
This can also apply to paragraphs and sections. Ordering them so that related information is recursively closer together, helps AIs think better (also helps humans, Dependency Length Minimization, DLM is an idea from psycho-linguistics).
This is one reason progressive disclosure and sub agents are important. Including unnecessary information spreads apart surrounding information and makes it more difficult for AIs to figure things out.
For eg. optimizing skills, it can help to put more important information at the bottom of a skill. Usually after a skill is loaded, the AI will start “thinking”, talking to itself to try to reason through a problem. The thinking block will have an easier time considering the text closest to it, the last part of the skill, than information farther up.
Thinking blocks can produce a lot of text (a lot of it often hidden from users) that also spreads information apart. Sometimes, when an early instruction is still relevant but there’s been a lot of thinking and discussion added to the context since, it’s worth repeating a summary the early information ( keeping in mind that too many reminders can also spread other information apart ). I think however, LLMs are tuned to overweight very early information so that they don't disregard system prompts. You might be able to exploit this by placing some important facts near the very beginning of a conversation.
If you've ever written compression algorithms where repeated blocks are referenced instead of encoded, you'll be familiar with how related information being clustered allows for better compression. It's another example of the parallels between intelligence and compression and it hints at the information theoretic aspect of DLM.
Comment by darkwater 3 days ago
For eg. optimizing skills, it can help to put more important information at the bottom of a skill.
LLMs are tuned to overweight very early information so that they don't disregard system prompts. You might be able to exploit this by placing some important facts near the very beginning of a conversation.
Aren't these 2 parts in contradiction then?Comment by sweetdreamerit 2 days ago
This is also how human memory works
Comment by BenoitEssiambre 2 days ago
Full disclosure: this is info I got from Claude. I was discussing DLM ideas with it a while back and while it mostly confirmed (maybe sycophantically) my ideas, it also said that rather than a pure decaying distribution effect with distance, it was U shaped because of the small boost at the beginning of the context window.
Comment by s1n_ 3 days ago
Comment by infogulch 3 days ago
An implementation of this idea based on the pi harness: https://github.com/jonaslsaa/pi-optchat
[1]: https://gist.github.com/VictorTaelin/91837951a5ce5b38f341ec1...
Comment by cadamsdotcom 3 days ago
> I think that’s the context problem of tomorrow.
This passage is explains why humans have imperfect memory. Seems the perfect memory we wish LLMs had impedes creativity and is maladaptive.
Strategic forgetting helps put the non-deterministic machine to best use. LLMs don't need perfect memory; that's covered by the computer itself.
I like that this justifies the continuing relevance of context engineering - a seemingly dated term - in the face of trends like loop engineering.
Comment by jphorism 3 days ago
Comment by viccis 3 days ago
Comment by jphorism 3 days ago
Comment by viccis 2 days ago
Comment by zhengzefeng 3 days ago
Comment by ethanj8011 3 days ago
I don't find this to be true, at least with the newer models. I also find that the models fill up to 250k very quickly (presumably mostly by looking through the codebase). Without that context I find the models perform badly. I also don't really notice that large of a change until around 700-800k context and even then it isn't as bad as it used to be. I suspect, that (especially for coding), the long horizon RLVR tasks have helped with this quite a bit.
Comment by nfw2 3 days ago
Comment by gnatolf 3 days ago
Comment by xyzsparetimexyz 3 days ago
Comment by desterothx 3 days ago
Comment by nghiemphucminh7 3 days ago
Comment by losvedir 3 days ago
Mmm, to my mind, isn't this mixing completely different things? I thought poisoned context is stuff in the context that makes the model behave poorly. But if it's in the weights, that's just... model issues.
Comment by antleys 3 days ago
I really like this final sentence from the presentation. When I read this phrase, I realized that it captured one of the core dynamics that I've been using to figure out when and how to apply AI to a task. I often find myself trying to figure out if it is better to A) ask the AI to do a task for me or B) ask the AI to build something that can do the task for me. A major component of that answer comes down to how deterministic or probabilistic the task is.
Comment by lumzell 3 days ago
Comment by mlmonkey 3 days ago
Comment by kadoban 3 days ago
I've taken to just manually making it write a handoff file and clearing context completely. I'm pretty much manually compacting instead of my harness doing it. Feels weird, but it does work.
Comment by plasticchris 3 days ago
Comment by kqr 3 days ago
Comment by kadoban 2 days ago
Comment by kadoban 3 days ago
Comment by ptkachykby 2 days ago
One hard part is that from a handoff file you only have information for 1 session, so you have to manually determine next week which facts are still true. At Substrate we solve this problem using our memory: we have 1 memory outside of an agent and track the source of every fact. https://trysubstrate.co/l/a2hn
Comment by joshheitzman 3 days ago
Comment by jwpapi 3 days ago
I have auto-compact on at 400k
Comment by throw-qqqqq 3 days ago
I try to manually manage as much of the context as possible. Most of the time, I limit myself to a context window of 200k, and it works great for my use cases.
Comment by 0xbadcafebee 3 days ago
Comment by bluerooibos 3 days ago
Comment by anax32 2 days ago
Like a see-saw - we just need that balance, man!!!
Comment by kirBurkhanov 3 days ago
Comment by viccis 3 days ago
Comment by fortitudedev 3 days ago
Comment by jdw64 3 days ago
That’s really true, but on the other hand, if there’s too little information, it also ends up working in strange ways. Most AGENT code anti-patterns work well at a medium amount of context, but when there’s too much or too little information, they don’t behave properly.
Comment by DenisM 3 days ago
Interestingly, the artifacts include not just code but alao retroactive design and retroactive “execution plan”. I feed them to another agent to validate the approach and resume work with fresh context and update mission statement.
Unexpectedly, design doc and an execution plan are now outcomes of coding process, not inputs to it. I’m not sure how to think about this.
Comment by hd168 2 days ago
Comment by DenisM 1 day ago
Comment by dishantsethi 3 days ago
Comment by zby 3 days ago
> Several times, Gemini 2.5 became convinced it needed to get tea, even though it
> was playing the older game. The tea task for FireRed was in its weights, so it
> poisoned its context. It spent hours trying to find or give the guard tea. Once
> it had been added to its to-do list, the model could not get past it.
I don't understand why this is called context poisoning when the information was in the weightsComment by WarmWash 3 days ago
Once pulled it added "iced tea" to its to-do list, which gets put into context. The model then couldn't escape the idea.
Comment by zby 3 days ago
Comment by WarmWash 3 days ago
It hallucinated that it needed tea.
Once that hallucination got into context, the context was poisoned.
If you don't want to believe that, then I cannot force you to, you can believe whatever you want.
But I (and the author) am explaining an otherwise well known problem with hallucinations getting into context.
Comment by zby 3 days ago
It is also a bit tongue in cheek - if you did not notice - because of course all of this can be explained if needed even if the name alone suggests something else.
Comment by WarmWash 2 days ago
On the next round, it's likely to correctly determine lemonade.
Hallucinations are usually outliers. So 1 in 10 times it gets confused and picks tea. Those 1 in 10 times end up with poisoned context.
The models are not deterministic by design. Identical inputs produce different outputs. So if you roll a bad output, it can poison your context. Flushing the context can easily fix the problem (unless like the in the pokemon harness, you roll over a brief of the previous context)
Comment by podocarp 2 days ago
Comment by lurker137 3 days ago
Comment by agentdev001 3 days ago
From my understanding, if we have turns [A, B, C, D, E] and we decide that turn C is useless context, then we lose our cache for the [D, E] segment. (plz correct me if im wrong, I havent tested this)
Personally, I pay no mind to session state nowadays. I exclusively use provider native hosted compaction, which if you believe the providers, is the way to go. For context management- I spend most of my effort on the things which dump output back to the model.
If anyone has any good reads on benchmarking OpenAI and Anthropic hosted/native compaction against custom stuff, I would love to read!
Comment by cyanydeez 3 days ago
Since I run everything local, speed benefits from keeping context low ~128k. This gets me through a single agent on multiple tasks through the same repo. It seems to break around 6M but that's more probablistic.
KV cache is definitely valuable but context poisoning happens regardless of size and it's probability increases regardless of intelligence. So at some point you're going to suffer from context overload regardless.
Comment by CBLT 3 days ago
Personally, I use a harness extension that auto-compacts my context just before the cache expires. Combined with the default compact-when-full, this ends up being pretty much always what I want. It's one less thing to think about.
Comment by orbital-decay 3 days ago
Comment by winwang 3 days ago
Comment by agentdev001 3 days ago
Comment by lhk931122 3 days ago
Comment by bertmuir 3 days ago
E.g. you can't use coworking/projects for shared memory in most domains because this hinges on compacting/refactoring true reusable facts and organisational knowledge (as opposed to code, schemas, technical references). The heuristics to find and decide on candidates for memory in this case are quite specific to the institution you work in. For example, the boundaries of the domain of "sales" versus "marketing" vary lots from place to place, as does the trustworthiness of certain staff, the way they they communicate or make decisions that contain the knowledge you want to store to memory, and so on.
I'm finding harnesses are still vastly better for grabbing this sort of complex institutional knowledge. Also, they're just a bit of a safety net for any frontier labs going bankrupt in the next couple of years, if we need an easy way to port over to open weights.
Comment by alfiedotwtf 2 days ago
Is context represented in by the original text, or translated into token indexes? Because if it’s in the original form, it seems obvious that either the server should be compressing into token indexes, or on handshake the server gives the client its dictionary and on request it translates it
Comment by rwoerz 2 days ago
Comment by triyambakam 3 days ago
I would like to counter with Theo Browne's "Your Prompts Kinda Suck" [1] I'm not a "fan" of Theo but his perspective here is useful.
Comment by vcryan 3 days ago
Comment by viccis 3 days ago
Comment by sdevonoes 3 days ago
But nowadays I have very little interest in knowing how “to prompt better” or why after around 100K tokens of context things start to suck for agents, or compiling tons of MD as “skills”. I don’t find that stuff challenging or interesting (granted, I don’t mean that I know all about it) and I have the feeling that it’s not like learning about operating systems or relational dbs.
I think part of my overall rejection to LLMs comes from this (of course the actual knowledge of how LLMs work under the hood is super interesting, but not their usage Id say)
Comment by PhunkyPhil 2 days ago
Knowing TCP connection protocols or deep compiler infra is impressive insofar as it's a mountain of knowledge that you've conquered and can stand on with a nice view, whereas "context engineering" and current AI engineering is a murky domain with no correct answers because... nobody alive knows the correct answers.
There's something different about wading forward into unexplored territory, or being able to establish techniques that nobody has attempted before. A lot of it will be noise or garbage (especially given a lot of it is LLM code), but I'd be careful to not mistake clever greenfield engineering with garbage simply because there's not a book written about it you can use as an oracle.
Comment by squidmaster 2 days ago
Comment by nottanjune 3 days ago
Comment by bickfordb 3 days ago
Comment by jthomas1 3 days ago
Comment by lioeters 3 days ago
Comment by PavelGIL 2 days ago
Comment by ChicagoDave 3 days ago
Comment by traderskillpack 3 days ago
Comment by 840754587 2 days ago
Comment by shenyanbuilds 3 days ago
Comment by gauravsharmaGG 2 days ago
Comment by agentic-affairs 3 days ago
Comment by toccter 3 days ago
Comment by maxsich 2 days ago
Comment by lucysilva90 2 days ago
Comment by pomerene 3 days ago
Comment by kensuh 3 days ago
Comment by pang_claw 3 days ago
Comment by nulltrace 3 days ago
Comment by 840754587 3 days ago