AgentKit: Structured LLM Reasoning with Dynamic Graphs

Summary

This paper presents a novel framework for structuring the reasoning process of large language models to tackle complex tasks. The use of DAG for structuring the thought process is technically sound. The authors provide quantitative results demonstrating the effectiveness of their framework, showing SOTA performance on WebShop and Crafter. It also gives a detailed explanation of the AgentKit framework and its organization aids in understanding the flow of ideas and the progression of the research.The framework has the potential to impact how LLMs are used in a variety of applications. Overall, it presents a high-quality, clear and significant work.

Rating

8

Confidence

4

Ethics flag

1

Reasons to accept

This paper presents a framework for natural language “coding” of end-to-end multifunctional AI agents, with the abilities to plan, reflect, and learn under challenging situations. This approach is innovative in its use of a node-based system to simulate a structured thought process. And it could be useful in many real-world tasks. Also the authors will open source its GitHub repository, which can lead to reproducibility and further community involvement.

Reasons to reject

The paper may lack a thorough comparative analysis with similar frameworks.

Summary

This paper proposes a framework (AgentKit) that constructs a graph with LLM prompts for reasoning, where each node contains a natural language prompt for a specific subtask. The paper claims that the proposed framework has modular interpretability and is easy to use (without the need to write explicit code). Experiments on Crafter and Webshop shows the framework works well and can generalize to different environments.

Rating

4

Confidence

4

Ethics flag

1

Reasons to accept

1. The proposed framework is general, and intuitively makes sense, I would expect it to work on a diverse set of tasks. 2. The idea of incorporating dynamic graph into LLMs for reasoning could have high potential.

Reasons to reject

1. Despite the high potential of the graph structure, it's unclear from the experiments whether it actually helps. First, the performance is (significantly) worse than Spring (20.6 vs 27.3) on Crafter. And there's no clear explanation from the paper why it is worse; Second, on Webshop, the improvement is also unclear. Actually, I'm not sure if the reported baseline (ReAct) uses GPT-3 or GPT-4 as base LLM, and the paper does not mention it as well. Therefore, I think the results of the proposed approach are quite weak to validate its effectiveness. 2. The writing of the paper needs significant improvement. First, it's very hard to get where the key motivation is. The paper proposes multiple components, but it's not explained well why we need this component. e.g., knowledge base (do we actually need an explicit KB, or just list all possible actions?). Second, some of the phrases are not accurate. E.g., in conclusion, it says "State-of-the-art performance" which is not accurate, as on Crafter, the performance is significantly worse. To summarize, the proposed framework is a bit overcomplicated, while the effectiveness over simpler baselines is not validated; Also the authors need to make the writing clear, especially in introducing the key motivations and the intuitions of different components.

Summary

The paper introduces AgentKit, a prompting framework for multifunctional agents. AgentKit uses simple natural language prompts to explicitly build complex "thought processes." The framework's core component is a node, which includes a prompt for a specific subtask. Users can combine these nodes to form a structured "thought process". Quantitative results show that agents designed using AgentKit achieve SOTA performance on Webshop and Crafter.

Rating

6

Confidence

2

Ethics flag

1

Reasons to accept

**Comprehensive, reliable and detailed agent framework**: AgentKit is a comprehensive agent framework that incorporates numerous essential functionalities for critical reasoning tasks. The framework offers transparent reasoning steps, enabling users to easily identify and rectify any reasoning errors. This makes it particularly valuable for those who aim to diagnose and improve their reasoning processes.

Reasons to reject

**1. Novelty of the framework**: In my view, this framework resembles an advanced self-reflection agent system, enhanced by specialized knowledge modules. Several unique nodes are employed to summarize previous trajectories and guide planning at the current step. However, this also brings to mind two relevant works: CLIN (Majumder et al., 2023) and SSO (Nottingham et al., 2024). Both incorporate memory modules (akin to a database) that refine agent skills. Thus, while this framework is quite sophisticated, it fundamentally builds on prior research with incremental, finer-grained modifications. - Majumder et al., 2023. CLIN: A Continually Learning Language Agent for Rapid Task Adaptation and Generalization. - Nottingham et al., 2024. Skill Set Optimization:Reinforcing Language Model Behavior via Transferable Skills. **2. Lack of in-depth evaluation**: The authors present only two performance tables for two tasks without a more detailed, fine-grained analysis, leaving several critical questions unanswered. For instance, what impact would the removal of node types n_{kg add} and n_{unk} have on performance? If the context window length were reduced from 25 to 20, would there be a significant performance decline? What role does the plan summarization node play in the overall performance, and how crucial is dynamic editing for the graph structure? Furthermore, given the framework's complexity, providing qualitative examples, particularly for the self-driving task, would be essential for helping readers understand the workflow and better grasp the practical implications.

Summary

This paper proposes an abstraction for structured reasoning using LLMs based on a Direct Acyclic Graph (DAG) structure where 1. nodes handle a specific subtask correspond to LLM calls with pre and post-processing 2. directed edges indicate which node outputs become which node inputs In addition to this static and local processing flow 3. there is a shared database of values that is read and written by every node that allows global communication 4. there is the possibility of dynamically adding or removing edges the experimental setup features comparison with other agent frameworks on the Crafter and Webshop tasks

Rating

6

Confidence

4

Ethics flag

1

Reasons to accept

**[A]** The topic is very timely and explores an area of growing importance: Abstractions needed in building agent systems. **[B]** The paper proposes a framework with a specific set of abstractions and an experimental setup with two commonly used agent benchmarks (Crafter, Webshop) where to test a particular instantiation of these against existing systems. The setups make sense and the comparison is against recent state of the art systems.

Reasons to reject

It is hard to judge the contributions to the paper because: **[A] It is hard to know which components contribute to what** The paper proposes a framework with a specific set of abstractions but it remains unclear how these help because the have conflicting properties i.e. 1. the system starts with desirable properties that bring simplicity and understandability. These are a. locality: provided by imposing a DAG structure. This indeed allows to think of sub-tasks independently and diagnose better b. static behavior: provided by having this DAG being pre-defined before execution 2. but then it adds properties that have the opposite effect, to attain flexibility and generality a. globally shared variables through a data-base b. dynamic modification of the DAG via "an API" so its hard to know if the locality/staticity help, what are the tradeoffs with regard to flexibility and generality. The paper just presents aggregate results with no ablations. For all we know the conflicting properties above give enough freedom to write any "neural computer program" and would make this paper more of a software package technical report, with not a strong research component. A possible improvement would be to compare local/static implementations versus the full version to analyze the effect of these design choices. **[B] The experimental setup for the Crafter setup has important confounding factors** It is well known that agent systems are very dependent on the LLM used, e.g. switching from GPT-4 to GTP-3.5 severely affecting performance [(Wang et al 2023)](https://arxiv.org/abs/2305.16291) But the experimental setup compares system with multiple different LLMs including some with markedly different performance >Our AgentKit implementation uses a combination of GPT-4-0613, GPT-4-turbo, and GPT-3.5- turbo to balance cost and performance This is not the authors fault. Its a sad state of affairs that closed-source proprietary systems are so far ahead open source alternatives for agent systems, but this does not change the fact that it is hard to judge results (i.e. was it the use of GPT-4 at some task that made the different?, have the authors identified tasks or flows that for which GPT-3.5 is good enough and competitive with GPT-4. All of this would be important for the papers scientific contribution.) It should be noted that the experimental setup for Webshop **does** have comparable setup using GPT-4 but also that it only uses the first 100 samples of Webshop, a specific category of Agent Bench, see [Table 3 in (Liu et al; 2023)](https://arxiv.org/abs/2308.03688) Agent Bench contains many more frameworks that were left out. So the setup for this second task could also be stronger. Again this is not exactly the authors fault.

Questions to authors

[S2.3] >Since there may exist more than one topological order for a given graph, the dynamic addition/removal of components may result in non-deterministic or unexpected behaviors. Safeguards are put in place to catch potential unexpected behaviors. Could you clarify this statement. If the graph is statically defined and topo-sorted before starting the processing but then dynamic graph changes are allowed, this can cause infinite loops. What are these safeguards?