Presentation proposes context engineering to replace bloated LLM context windows with 300 curated tokens

The presentation identifies a concrete failure mode: coding agents break when their context window is overstuffed with documentation, logs, and chat history. The speakers show that even a small code change can fail if the LLM receives too much irrelevant data. This is not a model limitation but an architectural one, every token sent consumes context window and increases cost, regardless of whether it is used.

The proposed context engineering techniques reframe the problem. Instead of relying on larger context windows, engineers pre-process input to extract only the 300 most relevant tokens. Lazy-loaded skills and versioned artifacts act as filters, while externalized memory banks offload state to cheaper storage. These changes require upfront work to curate and version context, but they reduce runtime cost and latency.

The trade-off is clear: context engineering shifts effort from runtime to build time. Engineers must now maintain versioned artifacts and external memory, which adds complexity to deployment pipelines. The techniques also assume that the 300-token subset is sufficient, which may not hold for complex or novel codebases. LLM-as-a-judge evals are proposed to validate this, but they add another layer of testing overhead.

The presentation does not claim these techniques are universally applicable. They target coding agents, where the task is narrow and the context can be pre-structured. For open-ended chat or research tasks, the same approach may not work, as the relevant context cannot be known in advance. The techniques also do not address model hallucination or reasoning errors, only the problem of context bloat.