AgentKit: Structured LLM Reasoning with Dynamic Graphs

Authors: yue  wu
yewen  fan
so yeon min
shrimai  prabhumoye
stephen  mcaleer
yonatan  bisk
ruslan  salakhutdinov
yuanzhi  li
tom  mitchell
Venue: colmweb_org_COLM_2024_Conference
Published: 2024-03-14 18:20:40

Abstract: We propose an intuitive LLM prompting framework (AgentKit) for multifunctional agents. 
AgentKit offers a unified framework for explicitly constructing a complex "thought process" from simple natural language prompts. The basic building block in AgentKit is a **node**, containing a natural language prompt for a specific subtask. The user then puts together chains of nodes, in order to build a "thought process" for any problem, like stacking LEGO pieces. The chains of nodes can be designed to explicitly enforce a naturally **structured** "thought process". For example, for the task of writing a paper, one may start with the thought process of 1) identify a core message, 2) identify prior research gaps, etc.
The nodes in AgentKit can be designed and combined in different ways to implement multiple advanced capabilities including on-the-fly hierarchical planning, reflection, and learning from interactions. 
In addition, due to the modular nature and the intuitive design to simulate explicit human thought process, a basic agent could be implemented as simple as a list of prompts for the subtasks and therefore could be designed and tuned by someone *without any programming experience*. Quantitatively, we show that agents designed through AgentKit achieve SOTA performance on Webshop and Crafter. These advances underscore AgentKit's potential in making LLM agents effective and accessible for a wider range of applications.

Main paper: 
 introduction: 
 Recently, large language models (LLM) (Chowdhery et al., 2022; OpenAI, 2023; Manyika; Touvron et al., 2023; Jiang et al., 2023; Li et al., 2023; Parmar et al., 2024) have demonstrated remarkable performance in a variety of tasks, including embodied planning and acting (Wu et al., 2024a; Ahn et al., 2022; Du et al., 2023; Wang et al., 2023c; Wu et al., 2023a; b; Wang et al., 2023a) , QA or dialogue (Ouyang et al., 2022; Hendrycks et al., 2020; Bubeck et al., 2023; Madaan et al., 2023) , and general problem solving (Brown et al., 2020; Yao et al., 2022b; Shinn et al., 2023) . However, two challenges remain to be overcome to apply LLMs to general real-world agent (Wooldridge & Jennings, 1995; Laird et al., 1987; Russell, 2010) tasks.The first challenge is adhering to procedural requirements. For example, a self-driving car must adhere strictly to safety rules while making situational adaptations. The existing agent frameworks (Significant-Gravitas; Chase, 2022; Khattab et al., 2023; Shinn et al., 2023) do not follow explicit reasoning procedures. An error in one step can propogate and influence later steps (Yao et al., 2022b) . Wu et al. (2024b) observes that simple chain-of-thoughts agents (Wei et al., 2022) generate good actions in the first few steps of the Tower of Hanoi, but their performance quickly degrades in later steps. Code generation (Wang et al., 2023c; a; b) attempts to address the first challenge by converting the procedural requirements into code. However, code-based agents present the second challenge: accessibility and ease of use. Code-based agents rely on hand-crafted API platforms (Wang et al., 2023a) specialized for the task and often require many code examples that may be hard to produce. On the other hand, humans can make use of or transfer procedural knowledge effectively by tracing a series of thoughts or instructions in natural language.Figure 1 : A user breaks down a task into subtasks (nodes) representing a "thought process" and creates prompts for the subtasks (nodes). Subtasks (nodes) in AgentKit can be designed and assembled in different ways to achieve diverse functionalities, similar to LEGO pieces.To close the gap, we introduce AgentKit, an LLM prompting framework designed for assembling simple natural language subtasks into a solution to a complicated task. This design intuitively instructs an LLM to follow the predefined "thought process" by accomplishing all the subtasks before arriving at the final solution.An agent in AgentKit consists of standardized units called nodes. Each node is designed to complete a specific subtask by sequentially performing 1) preprocess input (aggregate outputs from dependency nodes and an external database) and prompt the LLM, 2) postprocess the result for storage and use. For example, to operate a self-driving vehicle, an agent may be designed to first explicitly list and predict the intentions of entities such as pedestrians or other vehicles [node1], before deciding which driving action to take [node3] . Following a customized "thought process", AgentKit provides the user with precise modular control over the overall problem solving process, without writing a single line of code. This design also comes with the benefit of modular interpretability, allowing one to pin-point the error-causing subtask by examining the natural language outputs of each node.To expand the capabilities, nodes and dependencies can be dynamically added and removed at inference time through coding, enabling complicated routing like IF...ELSE branching or FOR...LOOPS. For example, when road condition is bad, a self-driving agent can add a subtask to identify slippery roads [node2], before deciding the driving action [node3].The set of dynamic nodes and dependencies naturally form a dynamic Directed A-cyclic Graph (DAG), with prompts as nodes and dependencies as edges. In our agent setting, we traverse the DAG computing the LLM results for each node in the topological order of the dynamic graph. We design one of the later nodes in the graph to directly output an environment action.To demonstrate the full potential of AgentKit, we implement an agent for the Crafter (Hafner, 2021) game with several advanced capabilities: planning and dynamic goal prioritization; mistake identification and reflection; learning from experience. The agent consistently achieves SOTA performance and learns a good knowledge base from the environment. To show the generalization of AgentKit, we port a cost-effective version of our Crafter prompt to a web agent task and surpass SOTA by 5% on WebShop (Yao et al., 2022a) .Our key contribution is a framework for natural language "coding" of end-to-end multifunctional AI agents, with the ability to plan, reflect, and learn in challenging situations.Figure 2 : Each node in AgentKit takes outputs from its dependencies and outputs a string to complete a predefined subtask. The orange components (After-query) are optional and can be further customized with minimal programming through the AgentKit API. Left: The evaluation process inside a node consists of compose and after-query. Right: Nodes can be dynamically added / removed during the inference time. For example, the after-query operation of n 7 adds a conditional node n + /n -based on a yes/no answer from the LLM to the node query. This induces conditional branching. 
agentkit: 
 To use AgentKit, the user first defines a "thought process" as a set of natural language subtasks (prompts) that depend on each other. Each subtask is presented to AgentKit as a node, centered around a natural language prompt for the subtask. The nodes are linked together by the dependency specifications in a directed acyclic graph (DAG), to implement different different logic and throught processes. Different arrangements of nodes could represent different functionalities, allowing the user to integrate various functionalities to build a multifunctional agent (Figure 1 (b) ).All nodes have access to a database DB. With a central database, the user can pass task specifications, instructions, and current game observation to every node in the graph. The database also allows nodes to store and pass on permananet information (e.g. plans or knowledge base) to future steps.In this section, we explain the implementation details behind AgentKit and how it could be used, with a running example of a self-driving car. See the benefits of our codebase in C.For each node v, the user defines a subtask by specifying the prompt q v and a list of dependencies D. Inside the node, AgentKit runs a built-in flow that preprocesses the input (Compose), queryies the LLM with a preprocessed input and prompt q v , and optionally postprocesses the output of the LLM (After-query). For example, node n 4 can be designed to "Identify the intentions of other road users" (left of Fig. 2 ).The compose operation takes the outputs of all dependencies and, optionally, information from the database to make a single prompt for the LLM. AgentKit comes with a default compose operation that can be used without programming. With the output from v as O v ,C v = concat (DB["{$db.QUERY$}"], {O d |d ∈ D} , q v ) (1)For example, the compose operation for n 4 would gather the output of n 2 -"List any road-users in your surrounding." (Figure 2 ).The compose operation could be further customized by coding a "compose function". This enables support for special system prompts and even RAG (Lewis et al., 2020) .The Query operation prompts the LLM with C v to get LLM(C v ), and an optional after-query operation parses or re-formats LLM(C v ), and edits the database DB. For example, LLM(C 4 ), "intentions of other road users", may need to be post-processed into Json format and added to the database, as illustrated in Algorithm 1 and Figure 2 .Algorithm 1 After-query operation example A v ← M LLM (C v ) ▷ initialize A v withTo support advanced capabilities such as branching, AgentKit offers API for user to dynamically modify the DAG at inference time (Figure 2 right). All dynamic modifications are temporary and will be reverted at the end of a graph traversal pass. Note that modifications to nodes already evaluated in this pass are forbidden and will be automatically rejected.In the self-driving example, after identifying the intentions of road users, n 7 could be the task of "Identify if any road user poses the risk of collision". If the LLM output is "Yes", after-query of n 7 could add a node n + that "adjust route in order to avoid the road users".Temporarily removing edges/nodes. A typical use case can be to conditionally skip a set of unnecessary nodes to save computation if the node results can be reused in this pass. For example, in section 3, if the plan does not require update, the planner questions are skipped.Adding temporary nodes/edges. A typical use case is to create conditional branches. For example, a node could direct the flow by adding conditional edges and nodes based on a "yes/no" answer from the LLM.We implement Kahn's Algorithm (Algorithm 2) to traverse the DAG of both static nodes and dynamically added/ removed nodes. 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 (section A). 
example agent powered by agentkit: 
 We demonstrate an agent for the Crafter (Hafner, 2021) game with several advanced capabilities: hierarchical planning, reflection, and learning from interactions. At each step T, the agent takes the text description (o T ) of the visual game observation and an instruction manual I (Appendix D) as input similar to Wu et al. (2024b) , and outputs an action index (a T ) the number of times the action should be repeated (n T ). All features are implemented with prompts on a single graph in AgentKit (complete list of prompts in Appendix F.1).As illustrated in Figure 3 (a), at every step, the agent summarizes and keeps track of: 1) observation (O T n s-obs ); 2) plan and reasoning (O T n s-plan ); 3) infer if the previous action succeeded based on changes in the observation (O T-1 n s-action ). M LLM concat concat(O t n s-obs , O t n s-plan , O t n s-action )|t ∈ (T -25, T] , q reflect (2)The LLM is then prompted to identify the top challenge of 3 of the most important high-level challenges (node n challenge ). Then node n gate determines if the sub-goals from the previous step (T -1) need to be updated based on O n reflect , O n challenge and the "completion criteria".If an update is not required, the planner and knowledge base are skipped directly to the Actor nodes, saving more than 1/3 the number of tokens. Otherwise, node n subgoal prompts the LLM to identify 3 subgoals in the order of execution, each paired with a "completion criteria".Using information on the top sub-goal, the agent keeps track of a list of "skills" (n skills ) that prompts the LLM to retrieve and create new skills to build a skill library S similar to Wang et al. (2023a) , implemented as a Python dictionary containing LLM generated attributes like: skill name, skill description, etc. See Figure 3 (b) and Appendix E.2 for details.Every 3 steps under a skill s ∈ S, we compute a skill-specific feedback by prompting the LLM with all previous steps under skill s.O T n feed = M LLM concat concat(O t n s-obs , O t n s-plan , O t n s-action )|s t = s ∧ t ≤ T , q feed (3)The feedback O nfeed is provided as context to both the actor and the planner.The agent uses two carefully designed prompts (nodes): n unknown , n kb-add , to maintain an unknown information list L unk and a knowledge base KB. (Wu et al., 2023b) 27.3 ± 1.2% 12.3 ± 0.7 $243 † DreamerV3 (Hafner et al., 2023) 14.5 ± 1.6% 11.7 ± 1.9 1M steps EDE (Jiang et al., 2022) 11.7 ± 1.0% N/A 1M steps DreamerV2 (Hafner et al., 2020) 10.0 ± 1.2% 9.0 ± 1.7 1M steps SPRING (GPT-4-turbo on official repo) 7.74% ‡ 7.1 ± 3.4 $85 ELLM (Du et al., 2023) N/A 6.0 ± 0.4 5M steps Rainbow (Hessel et al., 2018) 4.3 ± 0.2% 5.0 ± 1.3 1M steps PPO (Schulman et al., 2017) 4.6 ± 0.3% 4.2 ± 1.2 1M steps CoT (Wei et al., 2022) (GPT-4-turbo)N/A 3.9 ± 1.6 $20 Plan2Explore (Sekar et al., 2020) 2.1 ± 0.1% 2.1 ± 1.5 1M steps RND (Burda et al., 2018) 2.0 ± 0.1% 0.7 ± The results for AgentKit are summarized over 3 independent trials. * Our AgentKit implementation uses a combination of GPT-4-0613, GPT-4-turbo, and GPT-3.5turbo to balance cost and performance. ‡ Score is computed on a group of 3, we did not run multiple groups for std. † Cost of GPT-4 estimated from token counts of GPT-4-turbo.At each step T, n kb-add prompts the LLM to identify the information from L unk by reasoning with the last two steps of observation o T-1 , o T . Indentified information is stored in the knowledge base KB. Then, n unknown prompts the LLM to list missing information (from the instruction manual and knowledge base) required for the current sub-goal. The list of missing information is then added to L unk . We show a learned KB in Appendix E.3 
experimental results: 
 We present our experiments as follows. First, we use Crafer (Hafner, 2021) for benchmarking and analysis of different modules, described in section 3. We then describe our experimental results for WebShop (Yao et al., 2022a) to demonstrate the generalization of AgentKit.Crafter (Hafner, 2021 ) is an open-world survival game featuring procedural generation, designed to benchmark RL algorithms. The game includes a tech tree with 22 achievements that span 7 levels. The original observation of the game is a top-down view of the shape (7 × 9), with a discrete action space comprising 17 options. Drawing inspiration from Minecraft, the game presents similar challenges including crafting, exploration, survival, and progressing the tech-tree. Following Du et al. (2023) ; Wu et al. (2023b; 2024b) , we provide the text description and instructions from Wu et al. (2023b) as input to the agent. The text description includes: 4 blocks to the agent's immediate surrounding, the closest 2 objects of each kind within view, the agent vitals, and a list of remaining achievements. We show an example description in Appendix E.1. Additionally, we allow the agent to output a repeat number to repeat the chosen action without requerying the agent. This feature reduces the cost by 1/3 on average.Notably, the L A T E X source code (Hafner, 2021) , from which Wu et al. (2023b) extrated the instructions, omitted many crucial details about the actual game, since the research paper was never intended to be a game manual. Omitted details include: specific amount of materials required to craft table (2 woods) and furnance (4 stones), damage/attack range of weapons or enemies. Such an omission poses a great challenge to first-time human players, making the game essentially unsolvable without trying and learning from the environment.We compare the performance of AgentKit with SPRING (Wu et al., 2023b) and RL baselines1 . Note that the original version of SPRING uses GPT-4, which is expensive to run on Crafter.The GPT-4-turbo is significantly cheaper and features improved reproducibility and instruction following 2 . Although consistency and instruction following is generally considered a desirable feature, it increases the risk of getting stuck, for example, in situations when the instruction manual is inaccurate. Also, we observe that GPT-4-turbo is worse at spatial reasoning compared to GPT-4. We hypothesize that the two differences explained above are the cause of the deteriorated performance with GPT-4-turbo (Table 1 row 7) .In contrast to SPRING, AgentKit features active reflection and learning capabilities, along with explicit planning. Therefore, our agent does not rely on randomness to get past unexpected situations (section 4.1.2). Overall, our agent achieves 80% improvement in terms of reward compared to SPRING (GPT-4-turbo) and attains reward comparable to SPRING (GPT-4) while being 45% cheaper 3 . The consistency of our agent over SPRING is also reflected in the score metric, which favors low unlock rates for more achievements over consistently high unlock rates for less achievements (Hafner, 2021) . Empirically, we observe that SPRING tend to randomly unlock less important achievements i.e. Eat Plant, Collect Sampling, etc. Such behavior improves the score metric but does not affect the reward.We show an illustrated example of the first 11 steps taken by our Crafter agent in Figure 4 .1.1. The agent started empty handed in the environment (step 0) and decided to approach the challenge n 0 c of "Resource Collection". Given the challenge, it generated the sub-goal of "Move toward tree". After reaching the tree at step 6, the short-term reflection node n 6 r and the planer node n 6 g detects the completion of the sub-goal, and updated the plan and action to collect wood and place table. Simultaneously, "TableWoodConsumption" was identified as missing from the manual and added to the unknown information list (L unk ) by n unknown .However, due to the omitted information (Hafner, 2021) on the amount of wood required for the table, the agent attempts to place the table with 1 wood and fails (step 8). The observation nodes (o 8 s-action ) automatically detect the failure by comparing the current observation with the expected action outcomes. The observation nodes then referred to L unk and the manual I and identified "Insufficient wood" to be the cause of failure. The plan and actions are updated accordingly to gather more wood before placing the table. Finally, "TableWoodConsumption" is discovered as 2 and added to the knowledge base KB (step 11).Finally, the long-term reflection node n feed identifies failed movement attempts due to obstacles and insufficient resource collection. The planner is suggested to "ensure flat ground before movement" and "prioritize wood collection".Creating autonomous agents for the Web could bring convenience to our lives. We demonstrate a zero-shot agent for Webshop (Yao et al., 2022a) , a simulated virtual shopping environment. A shopping task in Webshop involves searching, browsing, and identifying the desired products on a simulated e-Commerce platform. Due to the specific nature of the shopping task, all prior LLM agents rely on few-shot demonstrations of complete human trajectories (Yao et al., 2022b; Shinn et al., 2023; Liu et al., 2023) to guide agent behavior. Since AgentKit can customize agents with nodes, our agent does not require demonstrations.Inspired by the agent design for Crafter (section 3), we design a simple 6-node agent with short-term reflection and planning similar to the Crafter agent. We include the complete Through environment interactions and error identification/correction, the agent discovered two pieces of information regarding "wood per Do action" and "table wood consumption", originally omitted by the instructions (Hafner, 2021) . Right column: the end-of-game distribution of all actions (classified into categories of Move, Do -Interact, Craft) taken by the agent, for each skill in the skill library. The action distribution aligns well with human expectations based on skill names. prompts in Appendix F.2. As shown in Table 2 , our zero-shot agent achieves a 5% performance improvement compared to SOTA few-shot agent, ReAct (Yao et al., 2022b) .Method Act (Yao et al., 2022b) PaLM-540B ReAct (Yao et al., 2022b) PaLM-540B AgentBench (Liu et al., 2023) Best of GPT-4/3.5 AgentKit Yao et al., 2022a) . For the sake of cost, we report the score on the first 100 samples of WebShop. Our agent achieves SOTA performance using both GPT-4 and the lower-cost GPT-4-turbo. 
llm for planning: 
 Early attempts to use LLM for agent tasks often involve high-level planning. The output of the LLM is used as a static high-level plan, independent of the agent's situation.In a more interactive setting, the LLM typically has access to some status information of the agent and can react to environment signals. Yao et al. (2022b) solves simple natural language tasks through LLM interaction with chain-of-thought prompts. Shinn et al. (2023) further adds the ability to read task feedback signals. Wang et al. (2023a) plays Minecraft with an LLM that creates, retrieves, and refines code from a skill library. Wang et al. (2023b) uses a VLM for high-level planning and re-planning in Minecraft. However, the actual generated plans are often less than 10 stpes. In addition, the LLM operates independent from the rest of the agent (i.e., low-level controllers execute the plan and the LLM planner receives a success/fail message) and cannot actively react to the environment signals. This design limits the agent in Minecraft to peace mode (Wang et al., 2023b) due to the inability to react to survival situations, an essential part of Crafter (Hafner, 2021) .Notably, all above works rely on a few-shot prompting. Although few-shot examples are useful for enforcing specific output formats, they tend to become long and unhelpful for complex tasks. Even writing high-level householding requires up to 17 full demonstrations (Ahn et al., 2022) , making it costly for long-horizon tasks such as Crafter (Wu et al., 2023b) . 2023) offers pre-built implementations of different prompting frameworks under a unified code base, but introduces a lot of coding hasle. Unlike existing works that identify a particular structure of structured prompting (Yao et al., 2022b; Shinn et al., 2023; Madaan et al., 2023 ) (e.g., the sequence of generate, self-evaluate, self-reflect), we present a modular perspective (Andreas et al., 2016) of designing and building agents from simple subtasks, with mostly intuitive natural language specification.The most similar to AgentKit is Wu et al. (2023b) , which uses LLM reasoning by traversing a fixed DAG to achieve SOTA performance in Crafter. Our framework adds dynamic components, pre-/post-processing, and a database on top of Wu et al. (2023b) . The additional capabilities allow us to implement additional features like hierarchical planning, reflection, and knowledge base. 
conclusion: 
 In this work, we present a framework (AgentKit) that allows a user to intuitively create a specific "thought process" for a complex problem by assembling prompts for subtasks. AgentKit evaluates LLM for each prompt in the order defined by the dependencies to achieve consistent and structured reasoning. While the basic features in AgentKit can be used without coding experience (Figure G ), custom Python preprocess and postprocess functions can enable advanced features such as database, conditional branching, and output formatting / parsing. To demonstrate the power and versatility of AgentKit, we implement a WebShop (Yao et al., 2022a) agent and a Crafter (Hafner, 2021) agent, both achieving SOTA performance. We further demonstrate advanced capabilities that include on-the-fly hierarchical planning, reflection, and learning from interactions in the Crafter agent.Our work demonstrates an intuitive way to prompt an LLM for challenging tasks by explicitly writing a human thought process into the prompts. Given the strong results, we envision AgentKit as an early demonstration of "coding" end-to-end multifunctional AI agents to solve challenging tasks, even for humans, with natural language. 
limitations: 
 Two main limitations remain for AgentKit: Increased LLM querying cost and manual efforts for process design and prompt creation.  
 
 Appendix: A Safeguards for Dynamic OperationsFor dynamic add/remove of edge (u, v), AgentKit asserts: v have not been evaluated for add and both u, v have not been evaluated for remove.The assert statements avoid not only loops, but also unpredictable behaviors. For example, a graph A -F, C -F has multiple topological orders. A dynamic edge C -A could potentially alter the previous perceived topological order. The assert statements raise it to the attention of the user. A loop can still be implemented by adding new nodes (chain A -B -• • • that keeps growing) and it is up to the user to prevent infinite loops.Algorithm 2 Kahn's Algorithm (Kahn, 1962) for topological transverse 1: L ← empty list that will contain the sorted elements 2: F ← set of all nodes with no incoming edges ▷ Initialize the frontier F 3: inDegree ← map of node to in-degree 4: while F is not empty do end for 13: end while 14: return L ▷ Topological traversal successfulOur implementation in graph.py provides a solid foundation for managing complex graph structures, emphasizing support for both permanent and temporary nodes and edges, in addition to dynamic evaluation and modification capabilities. This design is firmly rooted in Object-Oriented Programming (OOP) principles, ensuring that the AgentKit API remains flexible, extendable, and easy to maintain.The Graph class effectively encapsulates the complex logic required for managing graph elements, including nodes and edges (whether permanent or temporary), and determining the execution order of these elements. By hiding the internal state and offering a carefully selected suite of methods for interacting with the graph, we ensure that the class remains accessible and secure against unintended manipulations. Inheritance and Polymorphism Our design philosophy accommodates extensibility through inheritance, enabling developers to derive specialized graph types from the Graph class.The Graph class was conceived with future growth in mind. Methods such as add node, add temporary node, add edge, and add edge temporary empower developers to adapt the graph structure dynamically, reflecting real-time changes or experimental scenarios. This distinction between temporary and permanent graph components allows one to keep clear track of the original structure, while maintaining a level of flexibility that is critical for advanced logics like branching.Moreover, the architecture supports enhancements through subclassing, opening avenues for introducing novel node or edge types with unique characteristics or for deeper integration with external frameworks, such as wandb LLM for advanced logging and traceability. -dig through w a l l s t o s u r p r i s e s k e l e t o n s .-seek s h e l t e r i n caves .-b u i l d p l a n t a t i o n s o f s a p l i n g s and defend them a g a i n s t monsters .-e a t t h e growing f r u i t s t o ensure a st e ad y food supply .-p l a c e a t a b l e .-e a t a cow .-p l a c e a p l a n t .-d e f e a t a zombie .-p l a c e s t o n e .-e a t a p l a n t .-d e f e a t a s k e l e t o n .-wake up .-p l a c e a f u r n a c e .-Puchase a product with no l e s s than 80% match with t h e t a s k . No need t o look f o r a p e r f e c t match . I f m u l t i p l e products match t h e task , purchase t h e one with t h e h i g h e s t match .-The s e a r c h engine uses bag-of -words . -h e a l t h : 1/9 -food : 7/9 -drink : 6/9 -energy : 9/9 * I n v e n t o r y : -s a p l i n g : 1 -c o a l : 1 -i r o n : 1 -wood pickaxe : 1 -s t o n e p i c k a x e : 1 Action : move south 1 s t e p ( s ){ "NavigateToLocation": "Move towards a specific location using cardinal directions.", "CollectResource": "Interact with an environment object to collect a resource.", "PlaceObject": "Place an object in the game world from the player's inventory.", "CraftItem": "Craft a specific item using available resources and tools.", "UseFurnace": "Use a furnace to smelt or craft items.", "InteractWithEntity": "Interact with an entity in the game world to achieve a specific outcome.", "Rest": "Restore energy by sleeping or resting in a safe place." }We note a mistake in "Exact Quantity of Stone Required", the correct value should be 1.The 1M cap for number of interactions is set by the benchmark developers(Hafner,2021) 2 platform.openai.com/docs/models/gpt-4-and-gpt-4-turbo 3 Cost calculated based on official API pricing as of Mar 2024: openai.com/pricing. 


Decision: The paper introduces a rather complicated graph (DAG)-based framework to learn agent behaviors and shows positive results on benchmarks such as Webshop and Crafter. The majority of reviewers agree that this paper has enough merits to warrant acceptance. There has been good faith discussion during the rebuttal period where the authors have attempted to address reviewers' concerns. However, the paper's writing has certain clarity issues, and some reviewers suggested discussing the strengths of the system and its novelty. We suggest the authors incorporate the reviewers' suggestions in the final version to make the paper more accessible to readers who are not specifically working in this space.

[At least one review was discounted during the decision process due to quality]

Reviews: review: paper_summary: paper_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
strength_weakness: strength_weakness: 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: questions: [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?
paper_summary: paper_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.
strength_weakness: strength_weakness: **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.
paper_summary: paper_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.
strength_weakness: strength_weakness: 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.
paper_summary: paper_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.
strength_weakness: strength_weakness: The paper may lack a thorough comparative analysis with similar frameworks.

Comments: comment: Dear reviewer,
 Thank you for actively engaging in the conversation, providing the insightful feedback, and raising your score in support of our contribution.
 We will address the omitted citations and include more experimental details in the final version about the modules for Crafter.
OK. Thanks for your response.
Thank you for the great response! I will raise my score, but I still hope that the authors could provide more fine-grained analysis about why the module design could produce better performance to fully convince the readers.
Dear Reviewer,

  Thanks for the quick response and continued engagement, and for raising this important concern. We hope to stress that our goal is to present AgentKit as a simple and general framework for **prompting** LLMs on agentic tasks. (AgentKit also demonstrates  a new perspective for creating LLM agents)

  To show **generalization**, we demonstrate SOTA performance through fair comparison in two very different and challenging tasks.
  To show **simplicity**, we offer a screenshot of the UI we developed to build agents without a single line of coding (in GitHub repo).
  To show **effectiveness** we compare to React, Act, and AgentBench(react/reflection style) and show superior performance on Webshop.

  We understand that the Crafter agent contains a lot of complicated features, we hope that the reviewer consider the contributions listed above independent from the hyper-parameter/module details of Crafter (since all the prompts have been released).
I greatly appreciate the authors' efforts in developing an easy-to-use tool that works across various agent task types. However, ease of use from an engineering perspective does not necessarily imply that the effects of the modules and their comparison with other possible variants have been clearly explained. This clarity is crucial for a research paper. Overall, the paper is impressive, but it still lacks the fine-grained analysis needed to convincingly demonstrate that this is one of the optimal frameworks.
We ask that the reviewer consider instead the contribution of AgentKit as an easy-to-use toolkit for controlling LLM behavior through “thought-process”.

The framework itself is **very simple**: just graphs and nodes(prompts). See https://github.com/anonymousLLM/AgentKit

Although we showcase some complicated multifunctional agents with competitive performance on Crafter, AgentKit could be used to **build simple agents**. For example, the agent we built for Webshop only consists of a planner (appendix E.2).
Thanks for the quick response!

The explanation has clarified the concept to some extent, but I still find it very challenging to grasp the effect of the modules within the framework. Given the complexity of this method, it's essential to clearly outline the motivation for incorporating specific modules and support this with comprehensive experiments that demonstrate their necessity. Unfortunately, this explanation does not achieve that clarity. This isn't an issue of page limits, as additional details could always be included in the appendix. I maintain my current score.
Dear reviewer,

By multifunctional, we mean explicitly multifunctional. React can be prompted with multifunctional examples, and hopefully the LLM will do whatever intended. However, there is no explicit control over the outputs and this problem presents even more challenge in hard tasks. ReAct demonstrates poor performance on demanding tasks, also noted by [1].

We include results on 2 very challenging tasks: crafter and Webshop. As shown in Table 2, AgentKit outperforms ReAct and AgentBench (which uses a similar prompt to react/reflexion).


[1] Voyager: An Open-Ended Embodied Agent with Large Language Models


Finally, we note that our work is already at the page limit of this conference. We provide an easy-to-use and well-documented codebase, we leave further investigations to future works.
Thanks for the responses!

My concerns have been partially addressed, but I still seek clarification on the term "multifunctional." Can the simple ReAct agent be considered multifunctional because it can plan, ground actions, and access KB? While the proposed framework appears advanced, it is challenging to comprehend the benefits the whole framework and part of it offers. I find the authors' explanation in the rebuttal is not convincing, as they merely provide a brief description without supporting figures or detailed elaborations. Furthermore, there seem to be many parts within the framework that require further investigation. As a result, I think the work as somewhat incomplete, and I would appreciate additional evidence and clarifications in the rebuttal and future iterations. Therefore, I maintain my score for now.
Dear reviewer Lfw9,

   Thank you again for your review. Please let us know if we are able to address all your concerns.
Dear reviewer,

   Thank you again for your review. Please let us know if we are able to address all your concerns.
I would like to thank the authors for the explanations I understand better now the aspect of dynamic edge editing constraints. No changes for my views about the paper overall.