Means the agent (based on any model) will now primarily collect context on its own, rather than using what has been provided.
🟢 How is Dynamic Context different from "Classic" approach?
Static context is a classic approach. You dump all the logs, documentation, chat history, descriptions of all toolboxes, MCP, etc. into the agent's context at once. In general, this works, but the context ends up being filled with a lot of irrelevant information and is constantly overflowing.
Now, Cursor is offering Dynamic context discovery. This involves placing a conditional "table of contents" and links in the context, while the rest is scattered across files, and the agent can add information to itself as needed. For example:
➖ Everyone remembers that when the context overflows, Cursor performs summarization and updates the window, right? Now, in addition to this, Cursor stores chat history as a file. After summarization, the agent receives a link to this file, and if some necessary detail was lost in the summary, he can search the history and supplement himself.
➖ Long responses from tool calls are now also recorded in files, rather than being sent directly into the context. Only a link to the necessary output appears in the context, while the gigantic JSON file sits waiting for the agent to access it and search for what he needs using conditional grep or tail.
➖ The same applies to MCP, Agent Skill, and terminal sessions. Bulky tool descriptions and terminal outputs are stored not in the context, but in files. The context simply says "MCP is available for jira, datadog, figma", and the agent, if he needs something, goes to the detailed description and invokes the tool.
It turns out to be quite nice and practical. On A/B tests, the overall token consumption has decreased by ~46.9%.
And it's also scalable, because here the context transforms from a place where knowledge is stored into an instruction on how to retrieve it. Find details
••••••••••••••••••••••••••••••••••••••
🤖 Data Science, ML & Big Data with @DataXplore