I recently spent a lot of time trying to elevate Cursor, a common Agentic AI tool, to a new level. Initially, Cursor could only write and execute code, which made us feel that while it was like a clever little brother, there was still room for improvement. Therefore, we rewrote Cursor Rules to enable it to perform more complex planning, state reporting, and self-improvement. Subsequently, we connected Cursor to a private knowledge base and database through Python command line and natural language narratives, further expanding its capabilities.
However, even though Cursor now possesses capabilities such as large models, search, Feedback Loop, and multi-modal functionalities, it still often gives the impression of being somewhat clueless when faced with slightly complex tasks, frequently getting stuck in a loop. For example, when Cursor was tasked with connecting to a third-party search library, it first fixed Bug A under our guidance but forgot the changes it made when fixing Bug B, reverting the code to a previous version and reintroducing Bug A. This back-and-forth was time-consuming. Although it eventually got fixed, it wasted a significant amount of time. For more complex projects, it might even have been impossible to complete.
Why does it get stuck?If you are familiar with Context Window Management, you will notice that this is a typical loss of control phenomenon: when the same model is responsible for both high-level planning and low-level execution, all information gets crammed into the same context. It first has to sift through a clutter of information to find what is truly useful for planning before it can make a decision. This is a tremendous cognitive burden for the model. Conversely, if it focuses solely on execution, it may forget what the Planner previously stated or lose focus. The result is neither proper planning nor execution, leaving both sides unsatisfied.This prompted us to make our first major shift: separating the Planner and Executor.First Decision: Separate the Planner and ExecutorOur inspiration actually comes from management theory: if we expect one person to be both a manager and a coder, while holding them to the standards of both roles, they will inevitably fail at both management and coding. The same applies to the Context Window. Therefore, I allocated an independent context for the high-level Planner, allowing the Executor to focus solely on low-level implementation while the Planner maintains oversight. This simple stratification did not even require switching to a more powerful large model, yet it immediately reduced the error rate significantly. The Executor could concentrate on writing code and running debugging, while the Planner could periodically review and instruct the Executor to carry out specific bug fixes and version updates.However, an unexpected problem arose.Second Decision: Enforce Documentation Communication Among AgentsThe issue was that while the Planner and Executor were separated, they still communicated through conversation. This meant that as soon as the context window lengthened or was truncated, the Planner’s instructions were completely lost. For instance, if the Planner previously said, “Remember to run a version compatibility test,” after several rounds of debugging, if the context window got truncated, that statement would be lost. Since it was not within the Executor’s context window, the Executor would completely forget about it during the next execution.This is akin to a busy management layer in a company where no one bothers to document these minor matters. As a result, the execution layer cannot track progress and relies entirely on the boss’s reminders. The boss also cannot remember technical details, coming back daily to ask the same questions. (Why does this feel so familiar?)Thus, we realized that even after isolating the context window, we had not truly solved the amnesia problem. So, we devised a rather basic solution: we prepared a shared Scratchpad document for the Planner and Executor. Any thoughts, analyses, test results, encountered bugs, and final discussion conclusions would all be documented in this file.As a result:The Planner can check the current challenges and progress in the document at any time, as well as leave new task instructions;The Executor, upon completing a feature or encountering an issue, updates the document with results and feedback, ensuring the Planner will not forget what they read.By transforming the dialogue channel into a persistent notebook, we fundamentally addressed the LLM context loss issue. Even if the dialogue is temporarily refreshed, as long as the document is referenced again, the likelihood of amnesia and repeating the same mistakes has significantly decreased.Third Decision: Appoint My Brother o1 as the PlannerAfter separating the Planner and Executor and establishing a shared document, another new problem emerged: if we used a standard model as the Planner, it often lacked depth, only providing the Executor with very superficial suggestions. For instance, if we had a data processing pipeline, a seasoned senior engineer would first validate on a small scale before deploying to a larger data set, saving a lot of debugging time.However, if a simpler Planner is used, it would often debug directly on the final large-scale data, wasting a lot of time. An even more frustrating issue is that Cursor has a timeout for task execution; if it tests using real production data, it might time out before finishing, preventing it from automatically iterating.This problem is not hard to solve; we simply replaced the Planner with a smarter, more reasoning-capable model, such as o1. However, after the switch, another amusing issue arose. o1 tends to over-engineer. Sometimes it becomes overly enthusiastic about analysis and detailing, thinking about how to cover various edge cases or turning this small program into a Concurrent Large-Scale Platform, making the process exceedingly cumbersome.Sometimes I feel like I’ve hired a professional manager who is more focused on creating a fancy platform than helping me accomplish a task. I always think the next thing he will suggest is hiring more Claudes… This is like bringing in a famous consulting firm into a human team. These consultants often provide some elaborate, large, but cumbersome plans to showcase their expertise. The staff ends up busy for a while, but it doesn’t contribute to the final business goal or necessarily improve efficiency.Thus, we made a 3.5th decision: through prompting, we encouraged the Planner to exercise moderation and paired it with a clear acceptance mechanism. Our final approach was to still use o1 as the Planner but prompted it to adopt a Founder Mindset, avoiding the urge to achieve everything at once and create the most impressive platform. Instead, it should have a Bias for Action, seizing opportunities as they arise. It should first create a simple prototype, validate its feasibility, and then gradually add more features step by step.Especially when the Planner assigns tasks to the Executor, it needs to clarify the necessity of each step’s breakdown and the validation methods. Simultaneously, the Executor can raise questions in the document’s feedback section if they find the plan too complex, challenging the Planner to reassess the necessity or further break it down. This interaction and acceptance mechanism helps control the Planner’s reasoning.Practical ExampleFor example, the DuckDuckGo search I was calling in my Cursor rules had been unstable without clear patterns for when it would fail. After introducing the Multi-Agent system, o1, as the planner, first designed a series of experiments for Claude to run. Claude wrote the code based on this and provided the results back to o1. o1 then analyzed it, instructing Claude on what keywords to search for and to check the issues on the DuckDuckGo Python library’s GitHub.After several iterations, we discovered a bug in version 6.4 of the DuckDuckGo Python library, which was fixed in the latest version 7.2. The o1 planner then instructed Claude executor to upgrade the version and designed ten different test cases for Claude to test one by one. Finally, Claude was directed to write a document summarizing our learnings, detailing the measures taken to cross-check and ensure our implementation was correct, and explaining how it achieved the user’s goals.This entire Multi-Agent development experience has made me feel that the quality of task completion has reached a new level. Previously, it was just a little brother handing over completed tasks. Now it feels like there is a more experienced supervisor who first cross-checks before reporting back to me. It feels like we have transitioned from a manager to a senior manager.Fundamental Reasons for the Three Major Changes: Context WindowLooking back, we did not pursue Multi-Agent for its own sake, but rather it was a process of continuous trial and error, reflection, and gradual iteration.Because we encountered the issue of context interference, we were compelled to split roles.Because we faced the problem of amnesia, we were driven to make documentation the primary communication channel between the Planner and Executor.Because the ordinary model’s depth of thought and planning ability are limited, we were forced to replace it with a smarter Planner.Because smarter Planners tend to over-engineer, we were compelled to control their complexity through prompting and various methods.From the basic Cursor Agent Mode to Multi-Agent, we have uncovered three practical experiences and observed that multi-agent systems can indeed elevate AI collaboration to a new level. They not only clean up bugs more effectively but also engage in more complex abstract thinking, resulting in more outcomes within the same development cycle.On the surface, this system seems to merely add o1 to the original Claude in Cursor, but the underlying thought processes are much deeper than this appearance. Any analysis and improvement of LLM systems must understand what is within its context window. It is essential to ensure that the context window contains enough information to support task completion while also being sufficiently organized and clear. Grasping this point naturally leads to our three changes.I hope our reflections, experiences, and especially our lessons can inspire you while building your own multi-agent applications. Perhaps next time you encounter context loss, amnesia, or dialogue loss, you will think about how to reverse-engineer what inputs the LLM is receiving from the perspective of the context window. It may be necessary to separate their context windows and prepare an appropriate communication channel for them.Additionally, this Multi-Agent implementation has already been open-sourced, and everyone is welcome to reference it.Open Source Link:https://github.com/grapeot/devin.cursorrules/tree/multi-agent<PAST · Review of Previous Issues >One Hour Revamp: Turning a $20 Cursor into a $500 DevinA Guide to AI Tools for Young People | Devin vs. CursorA Must-Read for Entrepreneurs! How to Make Cursor Your Universal AI Entry PointSpecial Contributor: Duck, Application Scientist at Samsara | Olympic Torchbearer | Former Pinterest/Microsoft Employee | PhD from Columbia, published over 20 papers in top conferences/journals and holds more than 10 US patents, dedicated to exploring the technical potential of AI. He has some excellent GenAI course resources for young entrepreneurs:Online Courses:https://maven.com/kedaibiao/genaiOffline Courses:https://www.superlinear.academy/c/ai/This article is reprinted from yage.ai, with exclusive authorization.