Paper: Dynamic LLM-Agent Network: An LLM-agent Collaboration Framework with Agent Team Optimization (ICLR-2024)

Reviewer comment (Evaluation):
One limitation, which seems to be also shared with the compared baselines, is the performance gain compared with computation cost increase, especially when compared with the single execution. For example, in table 2-4, the Overall performance improved 4% but required 7 API calls (MATH dataset), 4 API calls (MMLU dataset) and 15 API calls (HumanEval dataset) compared to 1 API call with the single execution baseline.

Author response:
We acknowledge your observation regarding the performance gain relative to the computation cost increase in experimental results. We want to clarify that **current multi-agent methods inherently involve a trade-off between performance gains and computational costs** and were discussed limitedly in previous works. Instead, we take it as an important factor.

It is important to note that our methods are orthogonal to different prompting methods, as shown in Table 2. **While prompt engineering methods can improve performance without increasing #API calls, our framework demonstrates improvement across different prompting methods by leveraging the collaborative strengths of multiple agents.** 

Compared with single execution, the seemingly marginal improvement from **all current methods** actually results from the limited collaborative capacity of the backbone model. We still view the LLM-agent collaboration as a promising direction for better utilization of LLMs. And we thought of two possible approaches to address it in the future work: (1) build LLMs that inherently incorporate collaboration mechanisms; (2) investigate specific scenarios that single LLMs struggle to complete, e.g., agents have exclusive resources or are distributedly deployed.

Reviewer comment (Experiments):
In the general reasoning task provided (Figure 6), it is unclear why it would require the language model to act in 4 different roles. While perspectives from agents with diverse roles may help in debatable topics, it is unclear if that is necessary for topics that have a single correct solution.

Author response:
Please refer to General Response 2 for overall responses to your concern about the collaborations of agents with different roles. Here're some detailed explanations:

Your question about the role of a doctor in solving a mathematics problem is insightful. There are chances that agents with certain roles refuse to answer specific queries. Generically, agents' behaviors are unpredictable without their actual responses, indicating that ideal agent team optimization could not be achieved based on human priors (also see General Response 5). **Since different roles provide diversity as well as potential poor performance, we propose a posterior agent team optimization method in DyLAN to mitigate this gap.** 

Specific to your concern, as we described in General Response 2, Doctor, Programmer, Economist, and Mathematician agents may exclusively have correct answers to different mathematical queries, and it's difficult to distinguish whose answer is the correct one. Moreover, they may all have false answers but come up with a correct one after a discussion on the reasoning process / factual knowledge / probable hallucination. In conclusion, given that we couldn't predict whether an agent will respond faithfully according to its backbone model, give better solutions due to the stimuli of tools and role prompts, or even refuse to answer, **collaboration is necessary and is usually (if not always) better for accuracy on some topics even if they have a single correct solution**.

We will clarify this point by stating the discussion explicitly and demonstrating clearer cases in the case study.

Reviewer comment (Evaluation):
If an agent is assigned the role of a doctor for solving the example mathematics problem, is the underlying language model deliberately trying to act as if it doesn't know how to solve the problem, despite the fact that the same language model underlies the role of the mathematician?

Author response:
Please refer to General Response 2 for overall responses to your concern about the collaborations of agents with different roles. Here're some detailed explanations:

Your question about the role of a doctor in solving a mathematics problem is insightful. There are chances that agents with certain roles refuse to answer specific queries. Generically, agents' behaviors are unpredictable without their actual responses, indicating that ideal agent team optimization could not be achieved based on human priors (also see General Response 5). **Since different roles provide diversity as well as potential poor performance, we propose a posterior agent team optimization method in DyLAN to mitigate this gap.** 

Specific to your concern, as we described in General Response 2, Doctor, Programmer, Economist, and Mathematician agents may exclusively have correct answers to different mathematical queries, and it's difficult to distinguish whose answer is the correct one. Moreover, they may all have false answers but come up with a correct one after a discussion on the reasoning process / factual knowledge / probable hallucination. In conclusion, given that we couldn't predict whether an agent will respond faithfully according to its backbone model, give better solutions due to the stimuli of tools and role prompts, or even refuse to answer, **collaboration is necessary and is usually (if not always) better for accuracy on some topics even if they have a single correct solution**.

We will clarify this point by stating the discussion explicitly and demonstrating clearer cases in the case study.

Reviewer comment (Theory):
If the system started with a majority of non-experts and a minority of experts, could it potentially produce a wrong solution due to the non-experts reaching a consensus on a wrong solution and being the majority in the multi-agent system?

Author response:
We want to clarify that in most subjects of MMLU, there are only 1-2 expert agents among seven candidates in our experiments, and no expert agents for a few subjects, aka. **we have already conducted experiments with a majority of non-expert agents**. Please refer to General Response 3 for further discussion about the imbalance of experts and non-experts.

Regarding the potential risk of non-experts reaching a consensus on an incorrect solution, **our Agent Team Optimization algorithm plays a key role in mitigating this**, as described in General Response 3. In extreme cases, where all agents are designed to perform poorly in specific tasks, possible techniques could be designed in addition to agent team optimization, such as automatically creating agents before optimization with validation, which is not our primary focus.

Reviewer comment (Writing):
On Page 1, in the last paragraph, what does sensitivity mean?

Author response:
In the last paragraph of Page 1, the term "sensitivity" refers to the system's low adaptability to the domain and complexity of different tasks. In a static setup, the lack of flexibility can lead to suboptimal performance when faced with tasks that deviate from the expected domain or complexity. Our dynamic multi-round approach in DyLAN and Agent Team Optimization method is designed to adapt more effectively to a broader range of tasks. We will clarify the term in the updated version.

Reviewer comment (Reproducibility):
It would be beneficial if some of the details of the method were discussed more clearly. For example, how are the agents different from each other? Did you manually create a list of agents before running the experiments?

Author response:
Please refer to General Response 4 for detailed clarification. 

In DyLAN, the prompts are not the same between prompt-based agents according to Section 3.1 & 4.1 and Appendix E. This approach allows the agents to specialize in specific tasks or subtasks, contributing their unique strengths to the collaborative effort and utilizing different tools in various tasks. While diverse prompts may not significantly affect performance in some tasks like MATH, this specialization is crucial for achieving high accuracy in other scenarios like general reasoning and code generation. 

Specific to your concern, agents with specific expertise could be automatically settled in each time step by the Agent Team Optimization process. Orthogonally, agents can be manually set in different time steps; e.g., we designate four code writers and four judges in different time steps for code generation tasks, as exhibited in Figure 5. Thus, agents could collaborate at both task and subtask levels.

Our revised paper will provide a more precise explanation of the process and construction of agent teams.

Reviewer comment (Experiments):
It seems the agent team optimization part is an additional step to the inference, how many rounds of communication and "training" are required to get a specific task ready for inference with high accuracy? Do you need like 10% or more of the dataset for this optimization before you can use it for inference?

Author response:
The agent team optimization in DyLAN is indeed an additional step. Please note that the process is unsupervised, meaning it does not rely on labeled data. As described in Appendix C.1, the additional consumption of API calls is 8.30 on average for general reasoning tasks and 23.04 on average for code generation. We did not add these costs to the collaboration process of optimized teams of agents because the unsupervised optimization could be performed offline, and the scores are reusable. Moreover, according to the first paragraph of Section 4.3, only a small amount of data is enough for optimization towards higher accuracy.

Also, the unsupervised optimization process required no extra data as an additional step to inference. Please note that it is not an overfitting since no label is used during the process. We will emphasize these details in our revised paper to provide a comprehensive understanding of the agent team optimization process.

Reviewer comment (Experiments):
When top k agents are selected for the inference agent selection, how is the k selected?

Author response:
k is a super-parameter that is tuned to balance efficiency and performance. We assign k=2 because it is the minimal number for agents’ interactions, and empirically found it brings a great trade-off between effectiveness and efficiency. We will include the information on how k is selected in our revised paper.

Reviewer comment (Evaluation):
In the evaluation section, for Table 4, it seems the gain from your method to the baseline is smaller when using GPT-4 (than GPT3.5). Will this method still be effective when the single LLM model performance improves?

Author response:
Regarding the observation in Table 5 about the smaller gains over the baseline when using GPT-4 compared to GPT-3.5, we believe this is due to the simplicity of HumanEval benchmark instead of the ineffectiveness of the method, since the score is 90+ and the improvement seems to be marginal. It is easy to understand that very weak LMs cannot collaborate and solve tasks, but DyLAN with GPT-3.5 actually gains excellent improvement. Thus, **the improvement of backbone models actually makes collaboration and agent team optimization more effective**. That is because capacities of reasoning, instruction following, etc., determine the effectiveness of LLM-agent collaborations.

As **for empirical results**, due to budget limits, we have only tested DyLAN on the humanities category of MMLU with GPT-4-0314, and we found an improvement from 83.9 (single execution) to 87.9 (+4.0), greater than +2.3 (from 59.8 to 62.1) with GPT-3.5 in Table 3. Nonetheless, we acknowledge that, ideally, if single agents are capable of solving tasks in whatever complexity at 100% accuracy, DyLAN will be meaningless. Nevertheless, in fact, even GPT-4 can only reach <50% accuracy or even lower in some challenging tasks, including MATH (we have tested), WebArena [1], SWE-bench [2], etc., denoting strong potential for LLM-agent collaboration and agent team optimization methods in DyLAN.

We are also experimenting with how our framework can be adapted to leverage the collaborative potential of LLMs in a more challenging task - WebShop. If time permits, we will also update the results.

[1] WebArena: A Realistic Web Environment for Building Autonomous Agents. https://arxiv.org/abs/2307.13854  
[2] SWE-bench: Can Language Models Resolve Real-World GitHub Issues? https://arxiv.org/abs/2310.06770

Reviewer comment (Novelty):
Novelty is somewhat limited since the framework is primarily a combination of standard technologies.

Author response:
Please refer to General Response 1 for the overall explanation of our contributions. We understand your perspective on the perceived limited novelty of our framework, given its use of standard technologies. However, we argue that the novelty of our work lies in **the unique concept of agent team optimization, and the innovative and effective method based on the unsupervised metric Agent Importance Score**. We will emphasize and clarify the point in the updated version of our paper.

Reviewer comment (Experiments):
The baseline (i.e., random selection) for agent team optimization is very weak.

Author response:
Please refer to General Response 5 for the additional baseline (Human Prior Selection) for Agent Team Optimization. We demonstrated that the current agent team optimization method is posterior and based on actual interactions and peer ratings between agents. **It exhibits significant improvement compared to prior selections.** As a detailed explanation, prior selections seem to overweigh the statement from role prompts and fail to predict each agent's actual behaviors and the functions of tools from short descriptions. We will add the results and the discussion in the updated paper.

Reviewer comment (Presentation):
It was slightly tricky to grasp the type of queries being solved by the ensemble of LLMs and how they interact with each other. While it is unfortunate that it was relegated to the appendix, Figure 5 is an excellent figure that could have helped readers understand the problem being solved if it had been presented earlier. In place of Figure 5 which seems to take a lot of space, perhaps the authors could consider describing a formal model of the interaction between agents and decision-making problems just to give more context.

Author response:
We appreciate your suggestion regarding our formulations. We agree that Figure 5 is a crucial element in conveying the concept and operations of DyLAN. Currently, we demonstrate the formal model for agent interactions as a feed-forward network $S=(A, E)$, in Section 3.1, and we described how task query $q$ is solved by the system's output $o$ in the last paragraph. Based on your suggestion, we will consider including a formal model, including the decision-making process earlier in the text, to provide readers with a clearer and more immediate understanding of the problem being solved.

Reviewer comment (Experiments):
One of the weaknesses of DyLAN is when the number of expert LLMs for dealing with a particular query is significantly lower than the number of non-experts. If somehow the number of non-expert LLMs selected during agent selection is still larger than the experts after agent selection, DyLAN can still yield poor accuracies. Perhaps it could be useful to have multiple rounds of agent selection until some average score/metric (ideally reflecting their capacity in solving the task) of the remaining LLMs is above a certain threshold.

Author response:
Your concern about the potential imbalance between expert and non-expert LLMs in DyLAN is insightful. Please refer to General Response 3 for detailed explanations. Based on empirical results, we explained that **Agent Team Optimization could deal with the imbalance between expert and non-expert agents**. Implementing multiple rounds of agent selection is likely to be effective in addressing extreme cases, as you suggested. We believe this approach will enhance the robustness of DyLAN against the risk of poor accuracies due to an imbalance in expertise.

**To step further, we want to share some thoughts on building metrics that reflect an agent's capacity for certain tasks**. A new work demonstrates several aspects for evaluating agents under multi-agent settings [1]. We think it is possible to extend its metric to certain timesteps inside DyLAN for a clear understanding of agents' capacities. We will add the discussion to our updated paper.

Reviewer comment (Experiments):
This paper cannot demonstrate that agent collaboration must perform better than single agent. For example, in Figure 6, the agent collaboration is totally unnecessary. The roles such as Programmer, Economist and Doctor are useless for the math reasoning problem.

Author response:
Please refer to General Response 2 for the discussion of the effectiveness of LLM-agent collaborations. Detailed explanations about comparing the collaboration with single LLM agents are as follows.

Our work is grounded in the philosophy that while a single, perfect agent capable of efficiently handling all tasks is an ideal goal, it is not yet achievable. In this context, our Dynamic LLM-Agent Network (DyLAN) framework aims to leverage the strengths of multiple agents in a collaborative setting to achieve better results and cost-efficiency, as well as better generalizability compared to a single agent.

From our observations in current experiment settings: (1) Expert is hard to manually select when there are many candidates; (2) The selection from human priors (by LLMs) mismatches the optimal team of agents and cause severe performance drop (refer to General Response 5).

In response to your comments, **Mathematician and Programmer agents alone are not enough for all mathematical and programming problems, respectively**. For instance, Programmer and Economist agent can outperform Mathematician agent in elementary mathematics, and a single programmer in Figure 5 (based on GPT-35-turbo-0301) could only achieve 73.2 on HumanEval compared to 82.9 from DyLAN. Collaboration. We'll add a different case to demonstrate the effectiveness of collaborations, e.g., DyLAN solves a query where all single agents fail.

Reviewer comment (Evaluation):
The results are not convincing. For example, does agent collaboration really perform better than single agent on math reasoning? The example in Figure 6 does not show the benefit of agent collaboration on math reasoning.

Author response:
Please refer to General Response 2 for the discussion of the effectiveness of LLM-agent collaborations. Detailed explanations about comparing the collaboration with single LLM agents are as follows.

Our work is grounded in the philosophy that while a single, perfect agent capable of efficiently handling all tasks is an ideal goal, it is not yet achievable. In this context, our Dynamic LLM-Agent Network (DyLAN) framework aims to leverage the strengths of multiple agents in a collaborative setting to achieve better results and cost-efficiency, as well as better generalizability compared to a single agent.

From our observations in current experiment settings: (1) Expert is hard to manually select when there are many candidates; (2) The selection from human priors (by LLMs) mismatches the optimal team of agents and cause severe performance drop (refer to General Response 5).

In response to your comments, **Mathematician and Programmer agents alone are not enough for all mathematical and programming problems, respectively**. For instance, Programmer and Economist agent can outperform Mathematician agent in elementary mathematics, and a single programmer in Figure 5 (based on GPT-35-turbo-0301) could only achieve 73.2 on HumanEval compared to 82.9 from DyLAN. Collaboration. We'll add a different case to demonstrate the effectiveness of collaborations, e.g., DyLAN solves a query where all single agents fail.

Reviewer comment (Presentation):
The collaboration process is unclear. For example, in Figure 5, how does the algorithm developer and programmer collaborate together? It seems programmer can already finish the task very well.

Author response:
To be specific, in Figure 5, Programmer and Algorithm Developer agents write incorrect programs at t=1, and at t=3, they receive the judgment from judges at t=2, thereby perceiving other cases along with according judgments from Unit Tester, Syntax Checker, and other judges. Programmer at t=3 refined its solution, which turned out to be correct, while Algorithm Developer still failed. The process demonstrates that code writers refine their solutions based on the feedback from judges and ensemble cases from other code writers. After Inference-Time Agent Selection, the other two agents reach a consensus and vote for the final, correct answer.

In short, **the interplay of agents' distinct expertise leads to a more robust and accurate solution than what a single agent could achieve**. We will add these descriptions to the caption of Figure 5. Additionally, to demonstrate the necessity and effectiveness of Agent Importance Score in Figure 5, we will include more detailed examples in the revised version.

Reviewer comment (Writing):
It is suggested that the authors explain more clearly the function of Agent Importance Scores using examples. Otherwise, it is unclear why it is necessary. This paper says that “We ignore the peer rating scores in responses of agents for computing Agent Importance Scores.” In Figure 5, the author may not ignore the peer rating process.

Author response:
We ignore the scoring process in Figure 5 mainly due to simplicity since there are 8 agents in Figure 5. We chose to demonstrate **the scoring process in Figure 6** with only 4 agents.

To be specific, in Figure 5, Programmer and Algorithm Developer agents write incorrect programs at t=1, and at t=3, they receive the judgment from judges at t=2, thereby perceiving other cases along with according judgments from Unit Tester, Syntax Checker, and other judges. Programmer at t=3 refined its solution, which turned out to be correct, while Algorithm Developer still failed. The process demonstrates that code writers refine their solutions based on the feedback from judges and ensemble cases from other code writers. After Inference-Time Agent Selection, the other two agents reach a consensus and vote for the final, correct answer.

In short, **the interplay of agents' distinct expertise leads to a more robust and accurate solution than what a single agent could achieve**. We will add these descriptions to the caption of Figure 5. Additionally, to demonstrate the necessity and effectiveness of Agent Importance Score in Figure 5, we will include more detailed examples in the revised version.

Reviewer comment (Novelty):
Some important references are missing. It is worth noting that this paper does not cite the paper [1] which proposed “role-playing”.

Author response:
We apologize for the oversight in not citing the relevant paper. Though "role-playing" is not our core focus, we acknowledge its importance in the field of LLM agents. The reference will be duly added in the next version of our paper.

Reviewer comment (Novelty):
The paper presents core ideas around dynamically organizing LLM agent collaborations and automatically optimizing the agent team, which seem novel and potentially of interest to the ICLR community. However, the work is generally incremental, building on a lot of recent research around multi-agent LLMs, and the techniques used, such as inference-time pruning and unsupervised contribution scoring, are not completely new concepts.

Author response:
1. **Summary of Key Contributions and Novelty:**

Please refer to General Response 1 for the summary of contributions. Our core contribution of improving LLM-agent collaborations by optimizing agent teams is **distinct from previous methods or concepts**, especially as we proposed an unsupervised metric Agent Importance Score to implement the posterior optimization.

Reviewer comment (Experiments):
The experimental validation is reasonable but mainly incremental, as it evaluates on established datasets with existing baseline methods. More complex, real-world tasks could be illustrative.

Author response:
2. **Experimental Validation and Real-World Applicability:**

Our experiments were designed to provide a clear and objective evaluation of DyLAN's performance. We chose established general datasets and **the strongest baselines (before the submission time)** for their recognized validity in the research community. All baselines are chosen for fair reasons. Specifically, CodeT is the strongest method based on GPT-35-turbo before submission. Even though Reflexion managed to reach SOTA using GPT-4, it still performs worse than CodeT on GPT-35-turbo, as shown in Table 5.

We acknowledge that CodeT is not a multi-agent method, but **it serves as a strong baseline even with multi-agent methods coming out near the submission date**. Because we were not able to re-implement all of them, we post a few reported results from recent (concurrent) multi-agent works on HumanEval with different backbone models:

|Method|GPT-35-turbo|GPT-4|
|:----|:---:|:---:|
|AgentVerse [1]|75.6|89.0|
|CAMEL [2]|69.4| - |
|MetaGPT [3]| - |85.9|
|The best baselines in our paper|74.8 (CodeT)|91.4 (Reflexion)|
|**DyLAN** (*Ours*)|**82.9**|**92.1**|

Regarding MMLU and MATH datasets, most multi-agent works [4] have not reported their results on the datasets or used the same backbone model, and it’s out of budget for us to reimplement those methods on GPT-35-turbo. Nonetheless, we demonstrate our fair reasons for baseline selections and the effectiveness of DyLAN.

We acknowledge your point about the potential benefits of evaluating DyLAN on more complex, real-world tasks. As part of the rebuttal response, we are extending our evaluation to more diverse and challenging scenarios, such as WebShop [5], to demonstrate the applicability of our framework further. Due to the time limit, we plan to update the results later.

Reviewer comment (Evaluation):
The paper claims efficient collaboration, but the overhead of techniques like peer rating and consensus checks could be significant. More analysis on computational costs is needed.

Author response:
3. **Clarification on Computational Overhead and Efficiency:**

Regarding the computational overhead of techniques like peer rating and consensus checks, we have **already included these factors** in the number of API calls reported in our experiments:

- In Appendix C.2, we mentioned that the rating is implemented by the suffix of prompts. Thus, the rating process does not affect #API calls. Indeed, this kind of prompting would increase token consumption. However, we find it insignificant since CoT prompts, reasoning processes, mathematical formulas, and codes take up most of the token consumption.

- In the last two paragraphs of Appendix C.1, we mentioned that consensus checks are processed by template matching with pure scripts. Thus, the overhead is small and does not change #API calls as well. 

We appreciate your concern about our potential mistakes. We will explicitly describe the overhead above in the next version of the paper.

Reviewer comment (Experiments):
There is limited ablation study or analysis into the agent scoring method, making it unclear if it is actually capturing meaningful contribution effectively.

Author response:
5. **Analysis and Insights on Agent Team Optimization:**

The effectiveness of our agent team optimization approach is a key contribution of our work. The Agent Importance Score is designed to capture the contributions of individual agents within a collaboration based on actual responses. 

First, we want to clarify the **motivation** of the scoring method. The scoring method is inspired by neural Importance Score in traditional machine learning studies, as explained in Section 2. While the algorithm couldn’t be directly transferred, we propose a three-step algorithm (as described in Section 3.3) by leveraging peer ratings to achieve effectiveness and efficiency. There are also several human-team optimization findings supporting our methodology, as shown in Section 2.

We also **provided empirical results to demonstrate Agent Importance Score as the indicator of individual contributions**. (1) The direct proof is the performance improvement after optimization in downstream tasks. In the last paragraph in Section 4.2 and the second paragraph in Section 4.3, we clearly describe the benefits of Agent Team Optimization and the impact of team sizes. (2) We also compared the scoring distribution with Shapley Value (Appendix D.5). We found that Agent Importance Score has a closer distribution to Shapley Value, which shows that the scoring process grasps the individual contributions of each agent to a fair extent.

Some insights could be derived from the existing results. As shown in Table 6, Agent Team Optimization is capable of **differentiating contributory agents** from the others. Some contributory agents match human prior, e.g., Mathematician for college mathematics, and some seem to be unrelated or not directly related, e.g., Psychologist for public relations. It reveals that Agent Team Optimization could not only retrieve domain experts but might **also retrieve agents with other domain knowledge that might help** (refer to Appendix D.1 & D.4). Moreover, peer ratings are more reliable than self-confidence due to previous studies [6], which provides extra solid support for our method.

Please refer to General Response 5 for the additional experiment of another baseline for Agent Team Optimization. We will add the discussion in the next version of our paper.

Reviewer comment (Experiments):
The choice of CodeT as the baseline is questionable, as CodeT is not a multi-agent framework for code generation and works on the principle of generating more test cases to improve the ranking of solutions. Stronger baselines should be chosen for a fairer comparison.

Author response:
2. **Experimental Validation and Real-World Applicability:**

Our experiments were designed to provide a clear and objective evaluation of DyLAN's performance. We chose established general datasets and **the strongest baselines (before the submission time)** for their recognized validity in the research community. All baselines are chosen for fair reasons. Specifically, CodeT is the strongest method based on GPT-35-turbo before submission. Even though Reflexion managed to reach SOTA using GPT-4, it still performs worse than CodeT on GPT-35-turbo, as shown in Table 5.

We acknowledge that CodeT is not a multi-agent method, but **it serves as a strong baseline even with multi-agent methods coming out near the submission date**. Because we were not able to re-implement all of them, we post a few reported results from recent (concurrent) multi-agent works on HumanEval with different backbone models:

|Method|GPT-35-turbo|GPT-4|
|:----|:---:|:---:|
|AgentVerse [1]|75.6|89.0|
|CAMEL [2]|69.4| - |
|MetaGPT [3]| - |85.9|
|The best baselines in our paper|74.8 (CodeT)|91.4 (Reflexion)|
|**DyLAN** (*Ours*)|**82.9**|**92.1**|

Regarding MMLU and MATH datasets, most multi-agent works [4] have not reported their results on the datasets or used the same backbone model, and it’s out of budget for us to reimplement those methods on GPT-35-turbo. Nonetheless, we demonstrate our fair reasons for baseline selections and the effectiveness of DyLAN.

We acknowledge your point about the potential benefits of evaluating DyLAN on more complex, real-world tasks. As part of the rebuttal response, we are extending our evaluation to more diverse and challenging scenarios, such as WebShop [5], to demonstrate the applicability of our framework further. Due to the time limit, we plan to update the results later.

Reviewer comment (Writing):
The presentation seems repetitive in parts, with previous sections being paraphrased. More clarity and conciseness in writing would strengthen the paper.

Author response:
4. **Clarity and Conciseness of Presentation:**

We appreciate your feedback on our paper's presentation. We will undertake a thorough review to eliminate repetitive content and improve clarity and conciseness.