Paper deep dive

How to Steer Your Multi-Agent System: Human-LLM Collaborative Planning

Zeyu He, Hannah Kim, Dan Zhang, Estevam Hruschka

Year: 2026Venue: arXiv preprintArea: cs.MAType: PreprintEmbeddings: 105

Intelligence

Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 85%

Last extracted: 7/8/2026, 7:13:17 PM

Summary

The paper addresses transparency limitations in multi-agent systems by formalizing a design space for human-LLM collaborative planning along three axes: mode (semantic vs. structural), scope (global vs. targeted), and level (low vs. high-level edits). These concepts are implemented in AMBIPOM, a prototype that enables process-level supervision through a dual-panel interface for inspecting and modifying plan DAGs. The authors validate the framework through a user study with 13 participants and a controlled benchmark, revealing hybrid workflows, effort-control-risk trade-offs, and LLM revision capabilities, ultimately providing design insights for transparent, controllable human-AI co-planning.

Entities (14)

AMBIPOM · prototype · 95%Large Language Models · technology · 95%Controlled Benchmark · evaluation-method · 90%Human-LLM Co-Planning · paradigm · 90%Multi-Agent Systems · architecture · 90%User Study · evaluation-method · 90%Directed Acyclic Graph · data-structure · 85%Process-level Supervision · concept · 85%Direct Manipulation · interaction-level · 80%Semantic Interaction · interaction-type · 80%Structural Interaction · interaction-type · 80%Global Feedback · interaction-scope · 75%High-level Structural Edits · interaction-level · 75%Targeted Feedback · interaction-scope · 75%

Relation Signals (13)

AMBIPOM → evaluatedvia → User Study

confidence 90% · Through a user study, we characterize how users navigate this space, revealing hybrid workflows and effort-control-risk trade-offs

AMBIPOM → evaluatedvia → Controlled Benchmark

confidence 90% · through a controlled benchmark, we analyze how LLMs revise plans under varying scope and revision strategies.

AMBIPOM → implements → Human-LLM Co-Planning

confidence 90% · We realize it in AMBIPOM, a prototype supporting process-level supervision through both semantic and structural interactions.

Human-LLM Co-Planning → operateson → Multi-Agent Systems

confidence 90% · In orchestrated multi-agent systems, humans often struggle to manage plans due to their complexity and limited transparency.

Human-LLM Co-Planning → utilizes → Large Language Models

confidence 90% · Recently, large language models (LLMs) have increasingly been employed as planners within orchestrated MAS thanks to their ability to break down high level tasks into manageable subtasks specialized agents.

Human-LLM Co-Planning → enables → Process-level Supervision

confidence 85% · These limitations call for process-oriented supervision in MAS, where humans can observe dependencies among agent subtasks, evaluate individual outputs, and intervene at multiple stages of planning and execution.

AMBIPOM → representsas → Directed Acyclic Graph

confidence 85% · We represent multi-agent plans explicitly as directed acyclic graphs (DAGs), where nodes correspond to agent-executable subtasks and edges encode data dependencies.

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract:In orchestrated multi-agent systems, humans often struggle to manage plans due to their complexity and limited transparency. Existing approaches rely on outcome-level supervision, where users verify only final outputs without visibility into intermediate reasoning. We formalize a design space for human-LLM co-planning interactions along three axes: mode (semantic vs. structural), scope (global vs. targeted), and level (low vs. high-level edits). We realize it in AMBIPOM, a prototype supporting process-level supervision through both semantic and structural interactions. Through a user study, we characterize how users navigate this space, revealing hybrid workflows and effort-control-risk trade-offs; through a controlled benchmark, we analyze how LLMs revise plans under varying scope and revision strategies. Our findings yield design insights for more transparent, controllable, and effective human-AI co-planning. We release code and data at this https URL.

PDF

Open source PDF →Open local PDF →

Trouble viewing inline? Open PDF directly →

Full Text

104,354 characters extracted from source content.

Expand or collapse full text

How to Steer Your Multi-Agent System: Human-LLM Collaborative Planning Zeyu He ∗ zmh5268@psu.edu Penn State University State College, Pennsylvania, United States Hannah Kim hannah@megagon.ai Megagon Labs Mountain View, California, United States Dan Zhang dan_z@megagon.ai Megagon Labs Mountain View, California, United States Estevam Hruschka estevam@megagon.ai Megagon Labs Mountain View, California, United States Abstract In orchestrated multi-agent systems, humans often struggle to man- age plans due to their complexity and limited transparency. Existing approaches rely on outcome-level supervision, where users verify only final outputs without visibility into intermediate reasoning. We formalize a design space for human-LLM co-planning interactions along three axes: mode (semantic vs. structural), scope (global vs. targeted), and level (low- vs. high-level edits). We realize it in AM- BIPOM, a prototype supporting process-level supervision through both semantic and structural interactions. Through a user study, we characterize how users navigate this space, revealing hybrid workflows and effort-control-risk trade-offs; through a controlled benchmark, we analyze how LLMs revise plans under varying scope and revision strategies. Our findings yield design insights for more transparent, controllable, and effective human-AI co-planning. We release code and data at https://github.com/megagonlabs/ambipom. CCS Concepts • Computing methodologies→Multi-agent planning;• Human- centered computing→ Interactive systems and tools. Keywords Human-LLM Collaborative Planning, Multi-Agent Planning ACM Reference Format: Zeyu He, Hannah Kim, Dan Zhang, and Estevam Hruschka. 2026. How to Steer Your Multi-Agent System: Human-LLM Collaborative Planning. In ACM Conference on AI and Agentic Systems (ACM CAIS ’26), May 26– 29, 2026, San Jose, CA, USA. ACM, New York, NY, USA, 18 pages. https: //doi.org/10.1145/3786335.3813144 1 Introduction In recent years, the paradigm of agentic systems has shifted from single, monolithic agents to multi-agent systems (MAS) [19,31]. Un- like monolithic architectures, MAS consist of multiple specialized ∗ Work done during internship at Megagon Labs. This work is licensed under a Creative Commons Attribution 4.0 International License. ACM CAIS ’26, San Jose, CA, USA © 2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-2415-2/26/05 https://doi.org/10.1145/3786335.3813144 agents, each designed with distinct capabilities or domain expertise, for example, mathematical reasoning agents, information extrac- tion agents, or real estate advisory agents [11,34]. This modularity enables MAS to tackle complex tasks more efficiently, exploit paral- lelism for faster execution, and maintain robustness through fault tolerance when individual agents fail [29]. Within the spectrum of MAS architectures, orchestrated MAS, in which a central controller coordinates the agents, offer additional advantages. The controller plays a crucial role in task decomposition, agent assignment, and orchestration of execution, effectively performing high-level plan- ning across the system. This centralized orchestration facilitates global optimization and coherence, clear accountability and control, and more effective allocation of resources and agent capabilities than fully decentralized MAS [4, 23, 29]. Recently, large language models (LLMs) have increasingly been employed as planners within orchestrated MAS thanks to their ability to break down high level tasks into manageable subtasks specialized agents [14]. However, relying solely on LLM planners remains insufficient in practice. Generated plans may misalign with human intent, fail to capture domain-specific constraints, or suffer from hallucinations [14,30]. Therefore, systematic mechanisms are needed to incorporate user interventions effectively and ensure that generated plans remain both correct and aligned with user goals [35]. Unfortunately, most existing systems rely on outcome-based su- pervision: users are presented with a final answer or, at best, a linear high-level plan while intermediate states remain opaque. This lack of transparency makes it difficult to diagnose failures and apply tar- geted corrections, especially for complex multi-agent plans. These limitations call for process-oriented supervision [25] in MAS, where humans can observe dependencies among agent subtasks, evaluate individual outputs, and intervene at multiple stages of planning and execution. By making intermediate reasoning and coordination ex- plicit, process supervision fosters trust and improves controllability in complex MAS. To operationalize process-level supervision in orchestrated MAS, we adopt a human-LLM interactive co-planning paradigm [12]. We represent multi-agent plans explicitly as directed acyclic graphs (DAGs), where nodes correspond to agent-executable subtasks and edges encode data dependencies [16]. This representation serves as a first-class planning object that can be inspected and modified prior to and during execution. Building on this representation, we arXiv:2605.23023v1 [cs.MA] 21 May 2026 ACM CAIS ’26, May 26–29, 2026, San Jose, CA, USAHe et al. formalize a co-planning interaction design space along three axes: mode—structural direct manipulation of the graph vs. semantic natural-language feedback; scope—global feedback affecting the en- tire plan vs. targeted feedback conditioned on a selected subgraph; and level—low-level graph edits (add/edit/delete) vs. high-level structural operations (merge/split/replan). By making scope and level first-class alongside mode, our framework introduces interac- tion types beyond those exposed by prior co-planning systems and makes different human-LLM collaboration strategies formally com- parable. We realize this design space in AMBIPOM (Agent-aware Mixed-initiative Block-level Interactive Planning for Orchestrated Multi-agent systems), a prototype to study user and LLM behavior across this space. Our contributions are threefold. First, we formalize a design space for human-LLM co-planning along three axes (mode, scope, level) and instantiate it in AMBIPOM, making different co-planning strategies explicit, operationalizable, and comparable. Second, through a user study, we examine how users combine these interaction types to steer and refine plans. Third, through a controlled benchmark, we analyze the capabilities and limitations of LLMs as co-planning partners across these axes. 2 Related Work 2.1 Multi-Agent Systems Recent progress in large language models (LLMs) has shifted the focus from single-agent architectures toward multi-agent systems (MAS) for solving complex and long-horizon tasks [27]. Instead of relying on a single agent to perform reasoning, planning, and tool use within one loop, MAS distribute these responsibilities across specialized agents, improving scalability while reducing the burden on individual agents [10, 28, 29]. Among coordination strategies, centralized or hierarchical or- chestration has emerged as a practical design pattern [23,29]. In this setting, agents are non-proactive and invoked only when as- signed specific subtasks by a central controller. Such systems typi- cally adopt a plan-then-execute paradigm (sometimes referred to as decomposition-first or plan-ahead) [14,21]: a central planner in- terprets high-level user intent and decomposes it into a structured plan. This plan is often represented as a directed acyclic graph, where nodes correspond to subtasks and edges encode execution order or data dependencies. Execution follows this predefined plan. Compared to decentralized approaches, centralized orchestration provides explicit data flow, reduced communication overhead, and globally coherent task planning, making it particularly suitable for human-in-the-loop settings, where transparency and controllability are essential. 2.2 Human-LLM Co-Planning Recent advances in LLMs have demonstrated remarkable capabili- ties in high-level planning and reasoning, making them as promis- ing planners for coordinating MAS without extensive task-specific training [14,33]. Despite these strengths, fully autonomous LLM planners encounter practical limitations, especially in domain-specific or high-stakes scenarios, due to issues such as hallucination and misalignment with human preferences and expertise [13,15,30]. These challenges motivate a mixed-initiative human-in-the-loop (HITL) approach, where human guidance is leveraged to refine, validate, or modify generated plans [35]. In mainstream AI assistants, including GitHub Copilot and Gem- ini Deep Research, planning typically occurs within a conversa- tional interface. Within this paradigm, humans function as pas- sive consultants [7], i.e., reviewing generated plans and request- ing changes via high-level prompts. However, this chat-based ap- proach lacks the transparency and granular control required to manage complex multi-agent plans. Addressing this, recent frame- works [8,16,24,26] shift the human’s role to an active collab- orator [6,7] through interactive co-planning, co-execution, and debugging. Frameworks like COCOA [8] and Magnetic-UI [24] al- low humans to directly manipulate linear plans by adding, editing, or removing plan steps. Alternatively, AGDebugger [6] enables humans to send or edit messages sent among agents including the orchestrator. The closest prior work, AIPOM [16], combines chat with a graph editor and shares our goal of process-level supervision, but realizes it along the mode axis only. Our work is the first to formalize a co-planning interaction design space along three axes (mode, scope, level), populating them with new interaction types and enabling controlled comparison. 3 Problem Statement Given a task query푄and a set of agent descriptions퐴, a planner generates a plan푃for a multi-agent system (MAS). We formalize human-LLM collaborative planning along three axes: (1) mode: structural interactions, where the user directly manipulates the plan graph, vs. semantic interactions, where the user provides high- level feedback interpreted by the planner; (2) scope: global interac- tions affecting the entire plan vs. targeted interactions modifying a selected subgraph; and (3) level: low-level edits (atomic graph operations) vs. high-level edits (compositional operations such as merge or split). Formally, the plan update can be represented as 푃 ′ = update_plan 푃 0 ,(mode, scope,Δ,푆 0 if scope = targeted)) , wheremode ∈ structural, semantic,scope ∈ global, targeted, Δcorresponds to either direct manipulation on a graph or text feed- back, and푆 0 ⊆ 푃 0 is the selected subgraph for targeted interactions. update_plan=             apply_ops(푃 0 ,Δ 퐷푀 )if structural planner(푃 0 ,Δ 푇푒푥푡 )if semantic / global planner(푆 0 ,Δ 푇푒푥푡 ) ⊕ (푃 0 \ 푆 0 )if semantic / targeted 3.1 Research Questions Our study investigates two complementary aspects of collaborative planning in MAS: how users interact with the system to steer and refine plans (RQ1,2) and how LLM-based planners revise structured plans under varying feedback scopes and strategies (RQ3,4). • RQ1 (User Performance with Interaction Types) How do interaction types–especially targeted semantic interactions and high-level structural interactions–affect user efficiency, effort, and task success compared to baseline interactions? • RQ2 (User Preference and Strategy) How do users select among interaction types depending on their plan modification How to Steer Your Multi-Agent System: Human-LLM Collaborative PlanningACM CAIS ’26, May 26–29, 2026, San Jose, CA, USA goals, and what patterns emerge in their human–LLM collabo- ration strategies? • RQ3 (Effect of Feedback Scope) How does the scope of feed- back (targeted vs. global) affect the quality of LLM-generated plan revisions in terms of edit correctness and global coherence? •RQ4 (LLM Revision Strategies) How do different LLM revi- sion strategies–direct plan regeneration vs. edit-sequence (struc- tural operation) generation–compare in terms of correctness, interpretability, and robustness? 3.2 Design Goals Motivated by our research questions, we define three design goals for human–LLM collaborative planning systems that emphasize transparency and controllability. Such systems should support flexi- ble interactions across mode, scope, and level while preserving plan integrity [1,3,9,12]. Building on these principles, we highlight three key goals that address gaps in existing systems. DG1 (Support Targeted and Safe Interactions) Planning sys- tems should provide fine-grained control over plan revisions, al- lowing users to refine specific parts of a plan without affecting the rest [16,22]. Preserving boundary interfaces and limiting cascad- ing changes ensures targeted adjustments are safe and predictable, supporting more precise human guidance. DG2 (Support Complex Structural Edits) Beyond low-level graph edit operations, such as adding, editing, or removing subtasks, planning systems should facilitate high-level structural modifica- tions such as merging, splitting, or branching that consist of a sequence of low-level edits [9,16,18,20]. Automating or assisting these complex operations reduces user effort and errors, addressing the high friction of structural plan refinement in existing work. DG3 (Preserve Transparency, Traceability and Inspectabil- ity) Users should be able to inspect node-level execution status, intermediate plan states, and the history of interactions [2,32]. These capabilities enable iterative refinement, support error diag- nosis, and facilitate informed decision-making. Based on these design goals, we implemented AMBIPOM, a prototype human–LLM co-planning system to study human–LLM collaborative behaviors and investigate the research questions out- lined above. 4 AMBIPOM: Human-LLM Collaborative Planning AMBIPOM consists of an LLM-based planner and four execution agents (LLMs with tools enabled) specialized in code, math, search, and commonsense tasks. Implementation details are provided in Ap- pendix A, including prompts for the planner (§ A.1) and execution agents (§ A.2). To facilitate transparency and controllability, AMBIPOM comes with a dual-panel interface, featuring a chat panel for semantic interaction and an interactive plan DAG visualization for structural interaction, similar to Kim et al. [16]. 4.1 LLM-Based Planner The planner is an LLM-based module responsible for generating the initial plan and revising the plan in response to user interac- tions. It supports four interaction types (§4.1.2−4.1.5) spanning different interaction modes (semantic vs. structural), scopes (global vs. targeted), and edit levels (low-level vs. high-level). 4.1.1 Initial Plan Generation. The initial plan푃 0 is generated en- tirely by the LLM, i.e., 푃 0 = planner(푄,퐴). 4.1.2 Semantic Interaction: Global Feedback (GF). Users can pro- vide free-form textual feedbackΔ text that applies to the entire plan. The planner regenerates the plan as: 푃 ′ = planner(푃 0 ,Δ Text )(1) This interaction type allows holistic revisions that reflect changes in overall strategy or task goals. 4.1.3 Semantic Interaction: Targeted Feedback (TF) (Supporting DG1). Users can select a subgraph푆 0 ⊆ 푃 0 and provide textual feedbackΔ Text specific to that region. The planner then regenerates only the selected subgraph while preserving compatibility with the rest of the plan: 푃 ′ = planner(푆 0 ,Δ text )⊕(푃 0 \ 푆 0 )(2) where⊕denotes reintegration of the revised subgraph into the unchanged portion of the plan. To encourage the LLM to follow the prompt template and preserve required interfaces, we intentionally minimize the context provided during replanning. In particular, the planner is prompted only with the selected subgraph푆 0 and its boundary input/output specification, rather than the full conver- sation history and the full plan푃 0 , which can introduce irrelevant details and increase format violations. 4.1.4 Structural Interaction: Direct Manipulation (DM 푙표푤 ). Users can perform low-level operations (single graph edit operations) on plan DAG, such as adding or deleting nodes or edges, modifying task descriptions, reassigning agents, updating input/output fields, or updating agent configurations, i.e., direct manipulation (DM). These operations are applied deterministically and do not involve the LLM: 푃 ′ = apply_ops(푃 0 ,Δ 퐷푀 ),(3) whereΔ 퐷푀 represents the set of user-specified direct manipulations on the plan graph. 4.1.5 Structural Interaction: High-Level DM and LLM-Assistance (DM ℎ푖푔ℎ ) (Supporting DG2). Beyond low-level DM, AMBIPOM sup- ports high-level DM (i.e., compositional edit operations that com- bine multiple low-level operations into a single meaningful interac- tion) such as merge or split, which can be performed both manually and with LLM assistance. For manual edits, the merge operation collapses a selected interface-closed subgraph푆 0 ⊆ 푃 0 into a single node푣 new , preserving the subgraph’s external input/output inter- faces. The split operation divides a single node푣 ∈ 푃 0 into two sequential nodes푣 1 ,푣 2 , while maintaining the original input/output connectivity. In LLM-assisted editing, denoted by DM + ℎ푖푔ℎ , the system auto- matically generates a structural edit operationΔ LLM for either auto- merge or auto-split, based on the details of the selected subgraph푆 0 (auto-merge) or node푣(auto-split). The operation is then applied deterministically to 푃 0 : Δ LLM = planner 표푝 (selection), 푃 ′ = apply_ops(푃 0 ,Δ LLM ),(4) ACM CAIS ’26, May 26–29, 2026, San Jose, CA, USAHe et al. Figure 1: AMBIPOM supports transparent and controllable human–LLM co-planning through a dual-panel interface. (A) Chat Panel supports plan generation, replanning, and execution feedback, with textualized logs of plan changes for transparency. (B) Plan Panel visualizes the current plan as an editable graph, allowing users to inspect and refine the workflow via DMs. whereselectiondenotes either a subgraph for an auto-merge or a node for an auto-split. By automating these high-level structural operations, the LLM-assisted edits reduce user effort while main- taining structural validity. 4.2 Interface (Supporting DG3) AMBIPOM provides a dual-panel interface centered on a shared plan state, which tracks the plan DAG, node execution status, and user interaction history. Updates from either panel are propagated immediately, ensuring consistent views across semantic and struc- tural interactions. The chat panel serves as the primary channel for natural language interaction and system feedbacks. The plan panel serves as the primary workspace for inspecting and editing the visualized plan graph through structural interactions. 4.2.1Chat Panel (Fig. 1A). The chat panel provides a conversation interface semantic interactions, allowing users to issue high-level instructions and receive system status messsages. It supports a range of high-level instructions, including (1) initializing a plan via “Generate Plan” and (2) refining an existing plan through “Entire Re- plan” (global replanning) or “Targeted Replan,” (subgraph-specific replanning), enabling flexible control over revision scope. User messages and system responses are displayed as chat bub- bles, forming a traceable interaction history. During plan generation and replanning, the system posts concise summaries of changes (i.e., the number of nodes/edges created, which nodes were added or removed) to help users understand. In addition, the chat panel surfaces system activity notifications that record DM activity from the plan panel. For basic DMs, these logs capture the performed actions for activity tracking; for LLM-Assisted DMs, such as merge and split, they also summarize the resulting node-level changes. Figure 2: Each node card shows the agent, task, status, ed- itable I/O fields, and post-execution logs. Selection enables merge; single-node operations via the three-dot menu. 4.2.2 Plan Panel (Fig. 1B). The plan panel visualizes the current plan as an editable DAG, where nodes represent subtasks and edges denote data dependencies. Each node (Fig. 2) is rendered as a card displaying the subtask description, assigned agent, input/output fields, and node status indicator. Nodes also expose execution logs in two formats: raw log and structured trace that vary by agent in- ner pipelines. For example, the math agent’s trace shows generated expressions and computed results; the code agent shows gener- ated code and execution outputs; the search agent shows search queries, retrieved results, and summaries; and the commonsense agent surfaces intermediate reasoning alongside final outputs. How to Steer Your Multi-Agent System: Human-LLM Collaborative PlanningACM CAIS ’26, May 26–29, 2026, San Jose, CA, USA Nodes can be executed individually, with outputs and status up- dated immediately. Users can perform direct manipulations (DM), including adding, deleting, duplicating, or repositioning nodes, link- ing or removing edges, and editing subtask attributes (e.g., agent as- signment, input/output variables, task descriptions). The plan panel also supports high-level structural interactions: interface-closed subgraphs can be merged into a single node, either manually or via LLM-assisted auto-merge, while nodes can be split sequentially or via LLM-assisted auto-split based on task description and I/O fields. Selection shortcuts, undo/redo, and collapse/expand buttons aid iterative plan refinement, while control buttons at top-right allow execution of the full plan (“Execute All”) and viewing aggregated outputs (“Results”). This design integrates low-level DM and high-level LLM-assisted edits, enabling transparent, efficient, and controllable structural interactions that complement the chat panel’s semantic interactions. 5 User Study: Understanding Human–LLM Collaboration To study how humans interact with LLMs in co-planning, we con- ducted a controlled user study comparing two system prototypes. We used AMBIPOM, our prototype human–LLM co-planning sys- tem, and a baseline version implemented with standard interactions offered in prior works (GF, § 4.1.2, DM 푙표푤 , § 4.1.4). To mitigate con- founding effects of interface design, the baseline retained a user interface similar to AMBIPOM. While AMBIPOM includes several features to support co-planning, the primary difference relevant to our research questions was the availability of advanced interaction types: targeted semantic feed- back (TF, § 4.1.3) and high-level structural edit (DM ℎ푖푔ℎ , § 4.1.5). We employed a within-subject design in which participants com- pleted two sessions (one per system), allowing direct comparison of task efficiency, effort, and success across interaction types. This design allowed us to examine the effects of interaction types on performance (RQ1) and how users select and combine them to steer plans (RQ2). 5.1 Study Design 5.1.1Participants. We recruited 13 voluntary participants (P1–P13) in-house from a US-based industry research lab using convenience sampling. A background survey revealed that 69% of participants reported using LLMs constantly, while 31% reported daily use. On 7-point Likert scales, participants’ familiarity with LLMs was high (M = 5.92, SD = 0.95), as was their awareness of LLM limitations (M = 5.62, SD = 0.96). Trust in LLM-generated responses was be- low the scale midpoint (M = 3.62, SD = 1.04), whereas verification habits were higher (M = 5.31, SD = 1.18), indicating that participants tended to critically assess LLM outputs despite frequent use. 5.1.2Tasks. We curated four sets of question pairs (Table 4), with each pair designed to have similar difficulty and planning complex- ity. The questions were crafted to involve multiple agents and could not be solved by a single agent alone, requiring a combination of numerical computation, coding, retrieval, and commonsense rea- soning. Each pair belongs to one of four distinct structural patterns: (1)Stepwise Math Reasoning: multi-step arithmetic with no re- trieval (e.g., value increase when flipping an item). (2) Multi-Hop Computation: chained retrievals leading to compar- ative computation (e.g., distance between MVPs’ birthplaces). (3) Listed Retrieval & Aggregation: list given in the query; retrieve per item and aggregate (e.g., total chapters in a book series). (4) Top-K Retrieval & Aggregation: discover a top-K list, retrieve per item, and aggregate (e.g., average top-university tuition). For each question, an initial plan was provided, which could con- tain different kinds of errors. Participants’ task was to revise the plan using the system, and produce the correct final answer. Each participant completed all eight questions in two sessions of four questions each, with one question from each structural pattern per session. Question order and error type assignment were randomized to mitigate learning and order effects. 5.1.3 Procedure. Each study was conducted in person and lasted between 70 to 171 minutes. With consent, screen, audio, and video were recorded for analysis. Participants first completed a short background survey on LLM usage and familiarity. The main part consisted of two sessions, one with each system (AMBIPOM and the baseline). To mitigate order effects, system order was counterbalanced: seven participants used AMBIPOM first, and six participants used the baseline first. In each session, participants first watched a brief demonstration and completed a tutorial task to familiarize themselves with the interface, followed by four study tasks (one per question type). After finishing the four tasks, participants completed post-session questionnaires, including SUS and NASA-TLX. Participants then proceeded to a second session with the other system, following the same structure (demo, tutorial task, four tasks, and questionnaires). Finally, participants completed a post-study survey that captured system preferences and open-ended feedback. 5.1.4 Metrics. We measure task performance along two dimen- sions: effectiveness (task success, plan completeness) and efficiency (completion time, interaction frequency, conversation turns). De- tailed definitions in Appendix B.2. 5.2 User Study Results In this section, we summarize our findings under user-side research questions (RQ1,2) mentioned in § 3.1. Detailed analyses are included in Appendix B.4. 1 5.2.1RQ 1: Performance with Advanced Interaction Types. We com- pared how advanced interactions (TF, DM ℎ푖푔ℎ ) affected plan quality and efficiency compared to basic interactions (GF, DM 푙표푤 ). While we hypothesized that advanced types would produce better plans (H1), participants actually produced slightly higher-quality plans us- ing the basic types. However, advanced features did provide distinct usability benefits: DM ℎ푖푔ℎ reduced users’ cognitive load compared to manual DM 푙표푤 , and targeted text feedback TF successfully re- duced the number of conversational turns required to refine a plan (H3). Across both systems, semantic interactions generally reduced 1 Parts of this summary, derived from the detailed analyses in Appendix B.4, were initially generated using ChatGPT and Gemini and subsequently edited by the authors for clarity and accuracy. ACM CAIS ’26, May 26–29, 2026, San Jose, CA, USAHe et al. mental effort, while structural interactions were perceived to match users’ exact intentions more closely. To disentangle the contributions of TF and DM high + in partici- pants’ refinement workflows, we grouped each participant-question observation by which advanced types appeared: TF+DM high + , TF only, DM high + only, and (for observations using neither) GF-dominant or DM low -dominant workflows. Following the effectiveness met- rics in Appendix B.2, we compared these groups on final-answer accuracy and plan quality. The results suggest that DM + ℎ푖푔ℎ was as- sociated with better plans and higher accuracy than TF. This aligns with post-study preference for DM high + and with TF’s higher appli- cation difficulty: users need to select the correct subplan boundary and formulate targeted textual feedback. It is also consistent with our benchmark experiment (§6.5), where TF underperforms more constrained revision strategies. This refines our earlier finding: within advanced interaction types, DM high + is the more beneficial component, while TF introduces greater difficulty and variability. 5.2.2 RQ 2: User Strategy and Collaboration Patterns. To under- stand type selection during collaborative refinement, we triangu- lated (1) post-task preference ratings, (2) interaction logs, and (3) think-aloud and observational notes across 13 participants. Partici- pants could refine plans via four types: manual DM, LLM-assisted DM + ℎ푖푔ℎ , GF (full-plan replanning), and TF (subplan replanning). In addition, we coded participants’ text feedback into two functional categories: prescriptive/instructive (specifying corrective steps or transformations) and descriptive/diagnostic (identifying an error or mismatch and requesting correction). Users did not “pick a type”; they assembled hybrid workflows per iteration: Rather than sticking to a single interaction type, users dynamically alternated between modes and scopes. A typical se- quence involved using text feedback for broad modifications and then switching to manual DM for fine-grained, local repairs. Intentions for structural modification pulled strongly toward LLM- assisted DM + ℎ푖푔ℎ ; semantic modification were more mixed: When making graph-level changes, users heavily favored LLM-assisted DM + ℎ푖푔ℎ (e.g., auto-merge or auto-split) for rapid restructuring. For semantic tweaks, preferences were split, and users frequently paired targeted text feedback (TF) with manual DM to safely finalize adjustments. Type choice was mediated by an effort-control-risk trade-off: In- teraction choices were driven by balancing manual effort against the risk of the LLM breaking the plan. Users treated manual DM as high-control but high-effort, global text feedback (GF) as low- effort but risky (like “rolling a dice”), and LLM-assisted DM + ℎ푖푔ℎ as a favored middle ground. Collaborative refinement showed two recurring rhythms: review- first versus execute-first: Most participants (10/13) preferred to thoroughly inspect and clean the plan before executing it, while a few (3/13) executed early to let failures guide their edits. Regardless of their rhythm, both groups converged on a similar iterative cycle: broad text edits, local DM patches, and then re-execution. Users used text feedback as an executable specification, switching to diagnostic feedback when debugging: Text feedback was over- whelmingly prescriptive (169 out of 178 messages). Users primarily commanded the LLM like an algorithmic executor (e.g., “split this node”), and only resorted to diagnostic feedback (describing errors like a bug report) when actively debugging a breakdown. Trust increased in-task but verification declined later in sessions (The Trust-Fatigue Paradox): While users’ trust in LLM-assisted features (DM + ℎ푖푔ℎ ) grew as they gained experience with the sys- tem, their rigorous verification habits decayed over time. Due to fatigue, users shifted from carefully checking intermediate results early in the session to accepting plausible-looking outputs without verification later on. 6 Experiments: LLM Plan Revision with Feedback We evaluate the effectiveness of LLM planners in interpreting and incorporating human feedback to revise multi-agent plan graphs. Our main experiments systematically vary three factors: feedback scope (global vs. targeted), context availability (whether the full plan is provided), and revision strategy (direct plan regeneration vs. edit-sequence generation). Boundary flexibility (whether bound- ary interfaces are frozen or can be updated) is studied in Appen- dix C.2. We compare four conditions (GF, TF, TF+P, GF-to-DM) on a benchmark with ground-truth plans and report structural/semantic similarity, stability, and execution accuracy where applicable. 6.1 Experimental Setup Our experimental design follows a structured ablation approach. We group conditions by the revision strategy they use and then isolate mechanisms within each group. 6.1.1Direct Plan Regeneration (GF, TF, TF+P). Direct Plan Regener- ation conditions use textual feedback to regenerate plans, but vary in two mechanisms that shape the trade-off between local correct- ness and global coherence: feedback scope and context availability. GF corresponds to Global Feedback that replans the plan with full- plan context and does not require explicit boundary handling. TF corresponds to Targeted Feedback that replans only on the selected subplan with no full plan context and freezes boundary interfaces during reintegration. TF+P extends TF by providing the full plan as context during subplan revision, while still freezing boundary interfaces during reintegration. To evaluate LLM-Assisted DM + ℎ푖푔ℎ , we instantiate auto-merge and auto-split within the TF setting (TF 푚푒푟푔푒 and TF 푠푝푙푖푡 ). 6.1.2 Edit-Sequence Generation (GF-to-DM). GF-to-DM takes a full plan and text feedback, but differs from GF in revision strategy: instead of regenerating a plan using text feedback, the LLM gener- ates a sequence of structural edit operations that will be applied to the original plan to transform it to a new plan. 6.2 Benchmark Dataset We construct a benchmark of 200 gold plans and 1,150 broken-plan items with ground-truth structures via reverse operation. For each item, we start from a gold plan푝 gold , apply a breaking operation푓 How to Steer Your Multi-Agent System: Human-LLM Collaborative PlanningACM CAIS ’26, May 26–29, 2026, San Jose, CA, USA to obtain an initial plan푝 initial = 푓(푝 gold ), and generate a natural- language feedback describing the inverse transformation. Each benchmark item is a tuple(푝 initial , feedback, target_nodes,푝 gold ), wheretarget_nodesspecifies the target subgraph to be edited for targeted conditions. The benchmark is designed to mirror the structural demands of our user study tasks (§ 5.1.2) rather than their topics, spanning four subsets: Stepwise Math Reasoning, Multi-Hop Computation, Listed Retrieval & Aggregation, and Top-K Retrieval & Aggregation. For Stepwise Math Reasoning, we select 50 math problems from GSM8K [5] whose gold plans are known to execute correctly under our planner and satisfy plan-generation constraints, ensuring that execution-based evaluation is meaningful. For the remaining three subsets, we use Claude Sonnet 4.6 to draft 50 questions per subset that match the target structural pattern, and manually review them, discarding ambiguous, unsolvable, or off-pattern items. Across all selected items, we enforce a minimum plan-complexity threshold (at least 5 nodes and 5 edges) to ensure that the reverse-breaking operation and its corresponding inverse instruction are feasible. We cover seven operation types: add node, change node de- scription, change node agent, merge (sequential), merge (parallel), split (sequential), and split (parallel). Split operations require spe- cific node patterns (e.g., a plan with a compatible node structure) and thus appear only in compatible subsets. In our benchmark, sequential split instances occur only in the Multi-Hop Computation and Top-K Retrieval & Aggregation subsets, while parallel split instances occur only in the Top-K Retrieval & Aggregation subset. 6.3 Experimental Procedure For each benchmark item, we provide an initial plan푝 initial and a natural-language feedback describing the intended refinement. To mirror the interaction modes in our system, we render the feedback differently across conditions: global conditions (GF and GF-to- DM) receive ID-anchored instructions that reference specific node IDs, whereas targeted conditions receive deictic instructions that intentionally avoid node IDs and instead refer to the selected region. Each condition then differs in the plan context provided to the LLM. For GF, the model receives the full plan and outputs a revised full plan. For targeted conditions, the model receives only the selected subplan (with full-plan context provided in TF+P) and outputs a revised subplan, which is reintegrated into the original plan. Rein- tegration checks boundary interface compatibility; if the revised subplan cannot be integrated into the original plan due to a bound- ary interface mismatch, this run is marked as a failure. For LLM- Assisted DM + ℎ푖푔ℎ , we do not provide additional instruction beyond operations because the target node(s) are already selected. The sys- tem applies auto-merge/auto-split within the same context setting as TF. For edit-sequence-based revision (GF-to-DM), the model re- ceives the full plan and an ID-anchored instruction, but outputs edit sequence operations rather than a revised plan. The system applies operations step-by-step, and any invalid edit-sequence structural operation is treated as a failure. We evaluate GF-to-DM only on the Stepwise Math Reasoning subset, and we additionally execute the refined plans produced by both GF and GF-to-DM to compute execution accuracy. Table 1: Integration success and failure counts by feedback condition. GF bypasses integration by regenerating the full plan; targeted conditions and GF-to-DM may fail at boundary or operation-validity checks. GF TF TF split TF merge TF+P GF-to-DM Success115011221503971134197 Failure028031653 Success Rate10.97610.9920.9860.788 To complement the synthetic benchmark, we evaluate on naturally- occurring faulty plans (Appendix C.3), selected from the outputs of weaker planner models on the benchmark queries. 6.4 Evaluation Metrics We evaluate each refined plan푝 refined against푝 gold using four qual- ity metrics, computed only over runs that pass an integration check: (1) Graph Edit Distance (GED↓): structural similarity between plan topologies (0 = exact match). (2) Semantic Similarity (S↑): similarity aggregated over node descriptions (range 0-1). (3) Plan Stability (Stable↑): fraction of non-target nodes unchanged after revision (range 0-1; higher = fewer unexpected side effects). (4) Execution Accuracy↑: applicable only to the Stepwise Math Rea- soning subset; we execute revised plans and compute final-answer accuracy for GF and GF-to-DM. The integration check fails for targeted conditions when the revised subplan cannot be integrated due to boundary interface mismatch, and for GF-to-DM when an invalid structural operation is generated; integration success rates are reported in Table 1. 6.5 Experiment Results Our findings below address how feedback scope affects revisions (RQ 3: GF, TF, TF+P) and how revision strategies compare (RQ 4: GF vs. GF-to-DM). Integration failures concentrate in targeted feedback and edit- sequence revisions. Table 1 presents the integration performance across all interaction conditions. The detailed breakdown is shown in Table 7. Global feedback (GF) produced valid revisions in all cases, largely because it is designed to regenerate the entire plan directly, thereby avoiding explicit subgraph reintegration. In con- trast, targeted conditions exhibited lower success rates because revising only a subgraph can introduce interface mismatches with the unchanged remainder of the plan at reintegration boundaries. Within the targeted conditions, TF+P has a slightly higher success rate than TF. This pattern suggests that full-plan context improves reintegration success. Auto-merge/split variants under TF show near-perfect integration. In contrast, edit-sequence structural opera- tion refinement (GF-to-DM) had the lowest success rate, since later operations depend on accurately tracking the plan state produced by earlier edits. Targeted feedback helps on plan stability but worsens in structural correctness. Table 2 presents refinement performance across oper- ation types for different feedback conditions. Targeted feedback ACM CAIS ’26, May 26–29, 2026, San Jose, CA, USAHe et al. Table 2: Plan refinement performance by operation type and feedback condition, measured by graph edit distance (GED↓), semantic similarity (S↑), and plan stability (Stable↑). Bold marks the best per column. Boundary-flexible variants (+B) are reported in Appendix C.2. Operation Add NodeChange Desc.Change AgentMerge SequentialMerge ParallelSplit SequentialSplit Parallel GED↓ S↑ Stable↑GED↓ S↑ Stable↑GED↓ S↑ Stable↑GED↓ S↑ Stable↑GED↓ S↑ Stable↑GED↓ S↑ Stable↑GED↓ S↑ Stable↑ GF0.570 0.9930.9910.030 0.9940.9810.005 1.0000.9980.070 0.9950.9770.375 0.9930.9730.000 0.9990.9840.0000.9951.000 TF1.9200.979 1.0000.1850.987 1.0000.6200.993 1.0000.2700.986 1.0001.7550.987 1.0000.0200.995 1.0000.1600.994 1.000 TF 푚푒푟푔푒 ---------0.0000.987 1.0001.7670.988 1.000------ TF 푠푝푙푖푡 ---------------0.3700.993 1.0000.4000.993 1.000 TF+P1.5490.979 1.0000.5900.988 1.0000.9350.982 1.0000.1950.987 1.0001.0050.988 1.0000.000 0.999 1.0000.0800.994 1.000 GF-to-DM1.0000.985 1.0000.0200.989 1.0000.000 1.000 1.0000.3000.985 1.0001.3600.989 1.000------ Flexible Boundary TF+B2.3700.9780.9960.7700.9890.9960.8750.992 1.0000.9300.987 1.0001.9150.9880.9940.1800.993 1.00017.180 0.994 1.000 TF 푚푒푟푔푒 +B---------0.3650.988 1.0001.8450.9890.994------ TF 푠푝푙푖푡 +B---------------0.6600.989 1.00017.220 0.994 1.000 TF+B+P2.6050.9790.9960.7200.9900.9960.6950.986 1.0000.1950.988 1.0001.4850.9880.9940.0000.996 1.0000.840 0.996 1.000 Table 3: Plan refinement execution accuracy on Stepwise Math Reasoning by operation type and feedback condition. Bold and underline mark the best and second-best. Operation Add Node Change Desc. Change Agent Merge Sequential Merge Parallel Avg. GF0.8600.8600.8600.8600.7600.840 TF0.1280.9000.8000.8570.0200.545 TF 푚푒푟푔푒 ---0.8600.0000.434 TF+P0.3780.8800.7200.9000.4000.657 GF-to-DM0.2680.9070.8600.3700.1670.553 Flexible Boundary TF+B0.1300.4200.2600.1000.0200.187 TF 푚푒푟푔푒 +B---0.5600.0000.280 TF+B+P0.2130.7400.7000.7800.0800.506 improves plan stability compared to global feedback. Because tar- geted refinement revises only the selected subgraph, it naturally yields higher plan stability: the non-target portion of the plan is largely preserved by construction. Accordingly, all targeted con- ditions achieve higher stability than global feedback. GF-to-DM shows a similar stability advantage. Since GF-to-DM converts a global feedback into a sequence of localized direct-manipulation operations, it also leaves untouched nodes unchanged and therefore achieves perfect stability, comparable to TF-based conditions. However, the conditions differ in structural correctness. Tar- geted feedback does not consistently outperform global feedback: across most operation types, TF and TF+P produce higher GED than GF, indicating larger deviations from the gold plan topology. GF-to-DM’s GED is between that of GF and targeted-feedback settings, suggesting that edit-sequence revision can preserve plan stability while avoiding some of the structural drift introduced by free-form targeted rewriting. For simpler operation types, such as changing the assigned agent, GF-to-DM can even achieve perfect GED, showing that constrained edit operations are especially ef- fective when the intended repair maps cleanly onto a small set of direct manipulations. Auto-merge preserves structure more reliably than auto-split. Across operation types, the LLM-assisted DM + ℎ푖푔ℎ variants largely mirror the targeted-replanning trends observed in TF, but with asymmetric effects on structural deviation. In particular, applying auto-merge based on TF tends to be structure-preserving: it reduces the GED introduced by targeted replanning, or yields a GED comparable to TF baseline. In contrast, auto-split is structurally more disruptive and typically increases GED relative to TF, indicating that split op- erations introduce larger topology changes than merge operations. Direct plan regeneration is most robust on complex structural revi- sions. Table 3 reports execution accuracy across operation types on Stepwise Math Reasoning tasks. Overall, global replanning achieves the highest average accuracy (0.840) across all plan regenerations, substantially outperforming structural operation generation with an average accuracy of 0.553 (0.287 difference). This suggests that the failure of structural operation refinement arises from incomplete recovery from 푝 initial to the 푝 gold structure, which then propagates to incorrect final answers during execution. Here, robustness refers to how reliably a strategy produces a globally consistent plan and executable plan when the required revision involves structural updates, rather than a single parame- ter change. Consistent with this definition, the performance gap is concentrated in structural edit operations. For operations that require coordinated topology changes (Add Node and Merge), GF- to-DM is markedly worse than GF (i.e., Add Node: 0.268 vs. 0.860; Merge Sequential: 0.370 vs. 0.860; Merge Parallel: 0.167 vs. 0.760). These sharp drops indicate that step-wise edit sequences are less robust when a refinement requires multiple node/edge updates: small mistakes in early operation can compound, leading to a plan that executes incorrectly even if the plan structure appears plausi- ble. In contrast, for more localized semantic edits, such as Change Description and Change Agent, GF-to-DM is competitive with (and sometimes outperforms) GF (i.e., Change Desc.: 0.907 vs. 0.860 and Change Agent: 0.860 tie). Edit-sequence revisions trade reliability for interpretability. In terms of interpretability, GF-to-DM provides an explicit audit trail of operations, enabling users to inspect what changed at each step and potentially diagnose where a revision went wrong. By com- parison, GF outputs a revised plan in a single pass without reveal- ing intermediate decisions. These results highlight a key trade-off: edit-sequence generation offers higher interpretability (auditable, How to Steer Your Multi-Agent System: Human-LLM Collaborative PlanningACM CAIS ’26, May 26–29, 2026, San Jose, CA, USA step-wise operations) and can be effective for localized edits, but direct regeneration is more reliable for complex structural changes that require globally consistent revisions. 7 Discussion 7.1 Design Suggestions Our results reveal a pattern that richer interaction types shift user effort from authoring to verification and integration. In the user study, advanced interactions (particularly LLM-assisted structural edits) reduced perceived effort and improved ease of use, yet they did not improve final plan quality. Complementing this, our LLM plan-revision experiments show that global feedback yields the strongest overall performance. However, effective global feedback assumes that users can reason about the full plan state and articulate precise guidance: an interaction style that participants were less inclined to use or prefer. Instead, participants often relied on hybrid workflows, combining targeted feedback for coarse replanning with direct manipulation for local refinements. This strategy partially mitigates the performance gap of targeted feedback by offloading global-coherence corrections to human edits. These findings sug- gest that the primary bottleneck in collaborative plan revision is not merely the efficiency of plan authoring, but the verification and integration of edits: users must ensure that modifications preserve global dependencies, maintain boundary compatibility, and guaran- tee execution validity. These findings point to the following design suggestions: Verification and integration support. Our findings suggest that the main barrier to higher plan quality is not generating edits faster, but making them easy to trust and integrate. To reduce “blow-up” con- cerns and verification burden, systems should shift support toward verification and boundary management: Preview how a proposed visualized edit changes nodes and edges at reintegration points, and validate compatibility before applying revisions. In addition, light- weight, risk-triggered checks (such as orphan node detection and input/output mismatch warnings) can counter verification decay and help users confirm the plan without heavy manual inspection. Proactive context-aware interaction guidance. Since users natu- rally combine targeted feedback with direct manipulation, inter- active planners should make proactive context-aware guidance a first-class feature across both modes. When users select nodes, the system can recommend targeted feedback prompts tailored to the selected region and its boundary contracts (i.e., “split this node into smaller sub-steps”, “duplicate these nodes and parallelize them with the existing branch”). After replanning, the system should immediately surface likely follow-up fixes, e.g., missing variable bindings, orphan nodes, boundary mismatch, and offer one-click repairs. Finally, the interface can suggest the next best action to reduce iteration overhead and prevent verification fatigue. Domain-specific output inspection. While the planning and edit- ing process can remain domain-agnostic, systems should provide domain-specific views for inspecting intermediate outputs. Our current interface assumes that node outputs can be summarized as short text, but richer workflows may produce code, tables, images, long-form text, or web search results that are difficult to verify within a node card. Future systems should therefore pair a general DAG-based planning shell with dedicated output panels, such as code diffs, rendered image previews, table viewers, or side-by-side long-text comparisons, so users can verify both structural changes and domain-specific execution results. 7.2 Limitations Despite providing insights into human–LLM collaborative planning, our work has several limitations. First, our co-planning paradigm was restricted to a single user operating on an orchestrated MAS with a fixed set of specialized agents, leaving unexplored other interaction paradigms and MAS configurations, such as multi-user collaboration or cooperative and more decentralized agent settings. Second, our user study involved a small sample (n=13) drawn from a single research lab, with most participants already possessing strong LLM expertise, which may limit generalizability to broader and more diverse populations. Third, participants’ verification ef- fort declined over time due to fatigue, potentially biasing plan quality measures, and our evaluation metrics may not fully capture more nuanced aspects of robustness or interpretability. Fourth, the artificially curated tasks, while multi-agent and multi-step, were relatively constrained in complexity and may not reflect highly dynamic or open-ended planning scenarios that could most benefit from human steering (e.g., domain-specific or personal workflows, or long-horizon tasks such as deep research). Finally, the initial erroneous plans used for our main experiments were synthetically constructed. While our supplementary experiment with naturally- occurring planner failures (Appendix C.3) suggests our key findings generalize, larger-scale validation across diverse planner models and failure distributions remains future work. 8 Conclusion In this paper, we formalized a design space for human-LLM co- planning along three axes (mode, scope, level) and implemented it in AMBIPOM. Through a user study and controlled benchmark, we found that users dynamically construct hybrid workflows, alter- nating across interaction types to navigate an effort-control-risk trade-off; while LLM revision is most robust under global feedback, targeted feedback is essential for preserving structural stability. Together, these contributions move human-LLM co-planning to- ward more transparent, controllable, and trustworthy multi-agent systems. References [1]M. Ai-Chang, J. Bresina, L. Charest, A. Chase, J.C.-J. Hsu, A. Jonsson, B. Kanefsky, P. Morris, Kanna Rajan, J. Yglesias, B.G. Chafin, W.C. Dias, and P.F. Maldague. 2004. MAPGEN: mixed-initiative planning and scheduling for the Mars Exploration Rover mission. IEEE Intelligent Systems 19, 1 (2004), 8–12. doi:10.1109/MIS.2004. 1265878 [2]Amine Barrak. 2025. Traceability and Accountability in Role-Specialized Multi- Agent LLM Pipelines. In 2025 40th IEEE/ACM International Conference on Auto- mated Software Engineering Workshops (ASEW). IEEE, 315–322. [3] Wei-Hao Chen, Weixi Tong, Ph.D. Case, Amanda, and Tianyi Zhang. 2025. Dango: A Mixed-Initiative Data Wrangling System using Large Language Model. In Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems (CHI ’25). Association for Computing Machinery, New York, NY, USA, Article 389, 28 pages. doi:10.1145/3706598.3714135 [4]Yongchao Chen, Jacob Arkin, Yang Zhang, Nicholas Roy, and Chuchu Fan. 2024. Scalable Multi-Robot Collaboration with Large Language Models: Centralized or Decentralized Systems?. In 2024 IEEE International Conference on Robotics and Automation (ICRA). 4311–4317. doi:10.1109/ICRA57147.2024.10610676 ACM CAIS ’26, May 26–29, 2026, San Jose, CA, USAHe et al. [5]Karl Cobbe, Vineet Kosaraju, Mohammad Bavarian, Mark Chen, Heewoo Jun, Lukasz Kaiser, Matthias Plappert, Jerry Tworek, Jacob Hilton, Reiichiro Nakano, Christopher Hesse, and John Schulman. 2021. Training Verifiers to Solve Math Word Problems. arXiv preprint arXiv:2110.14168 (2021). [6]Will Epperson, Gagan Bansal, Victor C Dibia, Adam Fourney, Jack Gerrits, Erkang (Eric) Zhu, and Saleema Amershi. 2025. Interactive Debugging and Steering of Multi-Agent AI Systems. In Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems (CHI ’25). Association for Computing Ma- chinery, New York, NY, USA, Article 156, 15 pages. doi:10.1145/3706598.3713581 [7]K. J. Kevin Feng, David W. McDonald, and Amy X. Zhang. 2025. Levels of Autonomy for AI Agents. arXiv:2506.12469 [cs.HC] https://arxiv.org/abs/2506. 12469 [8] K. J. Kevin Feng, Kevin Pu, Matt Latzke, Tal August, Pao Siangliulue, Jonathan Bragg, Daniel S Weld, Amy X. Zhang, and Joseph Chee Chang. 2026. Cocoa: Co-Planning and Co-Execution with AI Agents. In Proceedings of the 2026 CHI Conference on Human Factors in Computing Systems (CHI ’26). Association for Computing Machinery, New York, NY, USA, Article 16, 23 pages. doi:10.1145/ 3772318.3791673 [9]Stephen N. Freund, Brooke Simon, Emery D. Berger, and Eunice Jun. 2025. Flowco: Mixed-Initiative Authoring of Reliable End-to-End Data Analyses via Dataflow Graphs and LLMs. In Proceedings of the 38th Annual ACM Symposium on User In- terface Software and Technology (UIST ’25). Association for Computing Machinery, New York, NY, USA, Article 182, 20 pages. doi:10.1145/3746059.3747636 [10]Taicheng Guo, Xiuying Chen, Yaqi Wang, Ruidi Chang, Shichao Pei, Nitesh V. Chawla, Olaf Wiest, and Xiangliang Zhang. 2024. Large Language Model Based Multi-agents: A Survey of Progress and Challenges. In Proceedings of the Thirty- Third International Joint Conference on Artificial Intelligence, IJCAI-24, Kate Larson (Ed.). International Joint Conferences on Artificial Intelligence Organization, 8048–8057. doi:10.24963/ijcai.2024/890 Survey Track. [11] Sirui Hong, Mingchen Zhuge, Jonathan Chen, Xiawu Zheng, Yuheng Cheng, Jinlin Wang, Ceyao Zhang, Zili Wang, Steven Ka Shing Yau, Zijuan Lin, Liyang Zhou, Chenyu Ran, Lingfeng Xiao, Chenglin Wu, and Jürgen Schmidhuber. 2024. MetaGPT: Meta Programming for A Multi-Agent Collaborative Frame- work. In The Twelfth International Conference on Learning Representations. https: //openreview.net/forum?id=VtmBAGCN7o [12]Eric Horvitz. 1999. Principles of mixed-initiative user interfaces. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (Pittsburgh, Pennsylvania, USA) (CHI ’99). Association for Computing Machinery, New York, NY, USA, 159–166. doi:10.1145/302979.303030 [13]Lei Huang, Weijiang Yu, Weitao Ma, Weihong Zhong, Zhangyin Feng, Haotian Wang, Qianglong Chen, Weihua Peng, Xiaocheng Feng, Bing Qin, and Ting Liu. 2025. A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions. ACM Trans. Inf. Syst. 43, 2, Article 42 (Jan. 2025), 55 pages. doi:10.1145/3703155 [14]Xu Huang, Weiwen Liu, Xiaolong Chen, Xingmei Wang, Hao Wang, Defu Lian, Yasheng Wang, Ruiming Tang, and Enhong Chen. 2024. Understanding the planning of LLM agents: A survey. arXiv:2402.02716 [cs.AI] https://arxiv.org/ abs/2402.02716 [15] Subbarao Kambhampati, Karthik Valmeekam, Lin Guan, Mudit Verma, Kaya Stechly, Siddhant Bhambri, Lucas Saldyt, and Anil Murthy. 2024. Position: LLMs can’t plan, but can help planning in LLM-modulo frameworks. In Proceedings of the 41st International Conference on Machine Learning (Vienna, Austria) (ICML’24). JMLR.org, Article 921, 13 pages. [16] Hannah Kim, Kushan Mitra, Chen Shen, Dan Zhang, and Estevam Hruschka. 2025. AIPOM: Agent-aware Interactive Planning for Multi-Agent Systems. In Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing: System Demonstrations, Ivan Habernal, Peter Schulam, and Jörg Tiede- mann (Eds.). Association for Computational Linguistics, Suzhou, China, 85–96. doi:10.18653/v1/2025.emnlp-demos.7 [17]Joongwon Kim, Bhargavi Paranjape, Tushar Khot, and Hannaneh Hajishirzi. 2024. Husky: A Unified, Open-Source Language Agent for Multi-Step Reasoning. arXiv:2406. [cs.CL] [18]Boyi Li, Philipp Wu, Pieter Abbeel, and Jitendra Malik. 2025. Interactive Task Planning with Language Models. Transactions on Machine Learning Research (2025). https://openreview.net/forum?id=Vmf WywWuYQ [19]Xinyi Li, Sai Wang, Siqi Zeng, Yu Wu, and Yi Yang. 2024. A survey on LLM-based multi-agent systems: workflow, infrastructure, and challenges. Vicinagearth 1, 1 (2024), 9. [20] Anthony Zhe Liu, Xinhe Wang, Jacob Sansom, Yao Fu, Jongwook Choi, Sun- gryull Sohn, Jaekyeom Kim, and Honglak Lee. 2025. Interactive and Expressive Code-Augmented Planning with Large Language Models. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), Wanxiang Che, Joyce Nabende, Ekaterina Shutova, and Moham- mad Taher Pilehvar (Eds.). Association for Computational Linguistics, Vienna, Austria, 20330–20354. doi:10.18653/v1/2025.acl-long.994 [21]Shuodi Liu, Yingzhuo Liu, Zi Wang, Yusheng Wang, Huijia Wu, Liuyu Xiang, and Zhaofeng He. 2025. Select-Then-Decompose: From Empirical Analysis to Adaptive Selection Strategy for Task Decomposition in Large Language Models. In Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing, Christos Christodoulopoulos, Tanmoy Chakraborty, Carolyn Rose, and Violet Peng (Eds.). Association for Computational Linguistics, Suzhou, China, 5454–5477. doi:10.18653/v1/2025.emnlp-main.278 [22]Damien Masson, Sylvain Malacria, Géry Casiez, and Daniel Vogel. 2024. Direct- GPT: A Direct Manipulation Interface to Interact with Large Language Models. In Proceedings of the 2024 CHI Conference on Human Factors in Computing Systems (Honolulu, HI, USA) (CHI ’24). Association for Computing Machinery, New York, NY, USA, Article 975, 16 pages. doi:10.1145/3613904.3642462 [23]David J. Moore. 2025.A Taxonomy of Hierarchical Multi-Agent Sys- tems: Design Patterns, Coordination Mechanisms, and Industrial Applications. arXiv:2508.12683 [cs.MA] https://arxiv.org/abs/2508.12683 [24] Hussein Mozannar, Gagan Bansal, Cheng Tan, Adam Fourney, Victor Dibia, Jingya Chen, Jack Gerrits, Tyler Payne, Matheus Kunzler Maldaner, Madeleine Grunde-McLaughlin, Eric Zhu, Griffin Bassman, Jacob Alber, Peter Chang, Ricky Loynd, Friederike Niedtner, Ece Kamar, Maya Murad, Rafah Hosn, and Saleema Amershi. 2025. Magentic-UI: Towards Human-in-the-loop Agentic Systems. arXiv preprint arXiv:2507.22358 (2025). [25]Justin Reppert, Ben Rachbach, Charlie George, Luke Stebbing, Jungwon Byun, Maggie Appleton, and Andreas Stuhlmüller. 2023.Iterated De- composition: Improving Science Q&A by Supervising Reasoning Processes. arXiv:2301.01751 [cs.CL] https://arxiv.org/abs/2301.01751 [26]Yijia Shao, Vinay Samuel, Yucheng Jiang, John Yang, and Diyi Yang. 2026. Collab- orative Gym: A Framework for Enabling and Evaluating Human-Agent Collabo- ration. In The Fourteenth International Conference on Learning Representations. https://openreview.net/forum?id=GDYueXtKXT [27]Lijun Sun, Yijun Yang, Qiqi Duan, Yuhui Shi, Chao Lyu, Yu-Cheng Chang, Chin- Teng Lin, and Yang Shen. 2025. Multi-Agent Coordination across Diverse Appli- cations: A Survey. arXiv:2502.14743 [cs.MA] https://arxiv.org/abs/2502.14743 [28] Yashar Talebirad and Amirhossein Nadiri. 2023. Multi-Agent Collaboration: Harnessing the Power of Intelligent LLM Agents. arXiv:2306.03314 [cs.AI] https: //arxiv.org/abs/2306.03314 [29]Khanh-Tung Tran, Dung Dao, Minh-Duong Nguyen, Quoc-Viet Pham, Barry O’Sullivan, and Hoang D. Nguyen. 2025. Multi-Agent Collaboration Mechanisms: A Survey of LLMs. arXiv:2501.06322 [cs.AI] https://arxiv.org/abs/2501.06322 [30]Karthik Valmeekam, Matthew Marquez, Sarath Sreedharan, and Subbarao Kamb- hampati. 2023. On the planning abilities of large language models: a critical investigation. In Proceedings of the 37th International Conference on Neural Infor- mation Processing Systems (New Orleans, LA, USA) (NIPS ’23). Curran Associates Inc., Red Hook, NY, USA, Article 3320, 13 pages. [31] Lei Wang, Chen Ma, Xueyang Feng, Zeyu Zhang, Hao Yang, Jingsen Zhang, Zhiyuan Chen, Jiakai Tang, Xu Chen, Yankai Lin, Wayne Xin Zhao, Zhewei Wei, and Ji-Rong Wen. 2024. A survey on large language model based autonomous agents. Frontiers of Computer Science 18, 6 (2024), 186345. [32]Zexin Wang, Jingjing Li, Quan Zhou, Haotian Si, Yuanhao Liu, Jianhui Li, Gaogang Xie, Fei Sun, Dan Pei, and Changhua Pei. 2025. A Survey on AgentOps: Cate- gorization, Challenges, and Future Directions. arXiv preprint arXiv:2508.02121 (2025). [33] Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed H. Chi, Quoc V. Le, and Denny Zhou. 2022. Chain-of-thought prompting elicits reasoning in large language models. In Proceedings of the 36th International Conference on Neural Information Processing Systems (New Orleans, LA, USA) (NIPS ’22). Curran Associates Inc., Red Hook, NY, USA, Article 1800, 14 pages. [34] Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li, Erkang (Eric) Zhu, Li Jiang, Xiaoyun Zhang, Shaokun Zhang, Ahmed Awadallah, Ryen W. White, Doug Burger, and Chi Wang. 2024.AutoGen: Enabling Next- Gen LLM Applications via Multi-Agent Conversation. In COLM 2024. https://w.microsoft.com/en-us/research/publication/autogen-enabling- next-gen-llm-applications-via-multi-agent-conversation-framework/ [35]Henry Peng Zou, Wei-Chieh Huang, Yaozu Wu, Yankai Chen, Chunyu Miao, Hoang Nguyen, Yue Zhou, Weizhi Zhang, Liancheng Fang, Langzhou He, Yangn- ing Li, Dongyuan Li, Renhe Jiang, Xue Liu, and Philip S Yu. 2025. A survey on large language model based human-agent systems. Authorea Preprints (2025). How to Steer Your Multi-Agent System: Human-LLM Collaborative PlanningACM CAIS ’26, May 26–29, 2026, San Jose, CA, USA A Implementation Details Our prototype AMBIPOM is implemented as a web application with a React frontend communicating via FastAPI, and a Python backend handling core logic. The system is driven by an LLM-based planner and execution agents, each specialized for different tasks. In our experiments, the planner and execution agents are configured to use GPT-4o and GPT-4o-mini, respectively. A.1 Planner Prompts We provide the prompts used by AMBIPOM’s planner for plan generation, replanning based on text feedback, subgraph replanning based on targeted text feedback, auto-split, and auto-merge. Prompt: Plan Generation You are an expert at breaking down tasks for planning. You will only have access to these agents: [code] - For PURE coding tasks: - Implementing or modifying code to meet a spec (e.g., parse/ transform text/JSON/CSV, write functions, simulate small programs, validate formats). - Algorithmic procedures best expressed as code (loops, data structures, regexes, parsing). - Debugging code or reorganizing/refactoring code. - NOT for mathematical derivations or symbolic reasoning. If a node mixes coding + math, split them: use [math] to derive, then [code] to implement. [math] - For mathematical reasoning nodes: - Solving sub-problems in math: derive formulas, manipulate expressions, do case analysis, solve equations/inequalities, compute with given numbers. - Identify and restate conditions/variables; produce machine- evaluable expressions or numeric results where inputs are available. - Do NOT write or reason about code here. Keep it math-only. - The task MUST be a variable-template instruction (no concrete numbers). Use variable names only. - Never include numeric literals, percent symbols (%), or signs in math tasks; bind all given numbers in the node's input values. - Every variable listed in "variables" field in the input list MUST appear verbatim in the task description text. - The task description MUST NOT reference any other nodes. - For [math] nodes: - For each v in variables field in the input list, the task MUST contain v as a standalone token (exact match). - Reject tasks where a near-variant appears (e.g., "total sale") instead of the exact variable name (e.g., total_sales). - If a quantity is needed but not bound, create an upstream node to bind it to a properly named variable, then reference that exact name. [search] - For retrieving specific factual knowledge from the Web ( history, sports, culture, geography, medicine, science, etc.). [commonsense] - For everyday reasoning that does not require Web retrieval (e.g., comparing magnitudes, widely-known facts, straightforward logical checks). ==================== GLOBAL INSTRUCTIONS ==================== Given a complex question or task, generate a structured, step-by-step plan to solve it. Each node MUST follow this JSON schema: "id": <int>, "task": "<a complete, self-contained instruction using ONLY variable names from this node's inputs; never include discovered values.>", // Do not mention any other nodes in the task description! "agent_name": "<agent_name>", // choose exactly one agent; if more than one seems needed, split into multiple nodes "input": ["variable": "<variable_name>", "value": "<value>"], // bind given constants here; leave′ if unknown. "output": ["<output_key>"], "prereq": [<node_id_1>, <node_id_2>, ...] Also output the dependency edges (a plan graph). Each edge indicates that an output from one node is used as an input name in another node : "src_node": <source node id>, "dest_node": <destination node id>, "src_output": "<output key from source>", "dest_input": "<input key expected by destination>" ============= PLANNING RULES ============= 1) Break the problem into independent, atomic nodes. 2) Each node is an INSTRUCTION only-describe what must be done, not the result. - You may include constants ONLY if they appear explicitly in the original problem statement. - Do not invent, look up, or leak unknown values into the plan; such values must be produced by earlier nodes or via [search]. - Do NOT mention any other nodes in the task description. - Do NOT mention any other nodes in the task description. - Do NOT mention any other nodes in the task description. 3) A single agent must be able to complete each node using ONLY: - the node's instruction, - the specified agent, and - outputs from its prereqs. 4) Do NOT reference "the original question" inside nodes. Rewrite what's needed directly into each node's instruction. 5) Use exactly one agent per node in the "agent_name" field. If multiple agents seem required, split the node. 6) Include any necessary variable names directly in the instruction so the executing agent has everything it needs. Use snake_case for output variable names. 7) Produce a valid DAG: - No isolated nodes. - A single sink node (the node with the highest id) is the final output node. 8) Edges: - Only create edges for actual data dependencies (where a later node's input name matches a prior node's output variable name). - Every edge must point from an existing output to a named input expected by the destination node. <given task> Prompt: Replanning <same system prompt as plan generation> A plan and user feedback are given to you. Your job is to fix the plan according to the user feedback. Conversation History: <conversation history> Plan: <entire plan> User Feedback: <user feedback> Prompt: Subgraph Replanning You are an expert at re-planning sub-graphs in task planning DAGs. You will be given: ACM CAIS ’26, May 26–29, 2026, San Jose, CA, USAHe et al. 1. A selected sub-graph (a set of nodes and connecting edges) as the focus for replanning. Your goal is to regenerate ONLY the selected sub-graph nodes, while keeping the interface (inputs/outputs defined by edges connecting to outside nodes) fully consistent. ==================== GLOBAL INSTRUCTIONS ==================== - Every new node generated inside the replanned sub-graph must use an id that is a negative integer. (Examples: -1, -2, -3, ...). - Do NOT use the original numeric IDs for new nodes. Keep original IDs only for nodes outside the replanned sub-graph. - Maintain the same **input and output variables** on the boundary edges of the selected sub-graph so that upstream and downstream connections remain valid. - All **edges from/to nodes outside the sub-graph must remain unchanged** in terms of: - Outside node IDs - Variable names - Inside the replanned sub-graph you may: - Add, remove, or restructure edges - Split or merge tasks across nodes - Introduce additional internal connections as long as the boundary interface to outside nodes remains consistent. - Do not modify nodes or edges outside the selected sub-graph. Each replanned node must follow this JSON schema: "id": -1, // Use negative integers (-1, -2, -3, ...) for all new nodes inside the replanned sub-graph "task": "<a complete, self-contained instruction using ONLY this node’s input variables. Do not mention other nodes.>", "agent_name": "<agent_name>", // [code], [math], [search], or [ commonsense] "input": ["variable": "<variable_name>", "value": "<value>"], "output": ["<output_key>"], "prereq": [<id_of_other_node>, ...] // Can be a negative ID ( inside sub-graph) or an original node id (outside sub-graph) Also output the dependency edges among the replanned sub-graph nodes: "src_node": <node id>, // negative ID (-) if inside sub-graph, positive original ID if outside "dest_node": <node id>, // negative ID (-) if inside sub-graph, positive original ID if outside "src_output": "<output key from source>", "dest_input": "<input key expected by destination>" ============= PLANNING RULES ============= 1. **Boundary consistency:** - Any variable appearing on incoming edges from outside the sub- graph must appear as an input in at least one replanned node. - Any variable appearing on outgoing edges to outside the sub- graph must be produced as an output by at least one replanned node. - Outside node IDs and boundary edge structures must remain exactly the same. 2. **Atomic instructions:** - Each node must remain atomic, executable by exactly one agent. - Split tasks if multiple agent types would be required. 3. **Self-contained tasks:** - Node instructions must not reference other nodes or "the original question." - Use variable names verbatim from inputs/outputs. 4. **Valid DAG:** - No isolated nodes. - Exactly one sink node inside the replanned sub-graph. ======================== RESPONSE FORMAT (JSON) ======================== "nodes": [ <list of replanned node objects> ], "edges": [ <list of replanned edge objects> ] A sub-graph plan and user feedback are given to you. You job is to revise the subplan based on user's feedback Sub-graph Plan: <selected sub-graph> User Feedback: <targeted user feedback> Note: Must have the inputs/outputs interface defined by edges to connect to outside nodes. Prompt: Auto-Split <same system prompt as subgraph replanning> A sub-graph plan is given to you. You job is to split the sub-graph into a new plan. Keep the interface (inputs/outputs defined by edges connecting to outside nodes) fully consistent. Sub-graph Plan: <selected sub-graph> Note: Must have the inputs/outputs interface defined by edges to connect to outside nodes. Prompt: Auto-Merge <same system prompt as subgraph replanning> A sub-graph plan is given to you. You job is to merge the sub-graph into EXACTLY ONE node. Keep the interface (inputs/outputs defined by edges connecting to outside nodes) fully consistent. Sub-graph Plan: <selected sub-graph> Note: Must have the inputs/outputs interface defined by edges to connect to outside nodes. A.2 Execution Agents We implement four agents capable of solving selected datasets, similar to Kim et al. [17]. Each execution agent follows a task- specific pipeline that combines LLM reasoning with structured tool invocation: a Python execution tool for the Code Agent, a SymPy- based calculator for the Math Agent, and Google Custom Search or Brave Search APIs for the Search Agent. Note that the selection and design of these execution agents primarily serve as a proof of concept, demonstrating that any agent capable of producing structured outputs can be integrated into our system with minimal modification. We provide the prompts used for each agent below. A.2.1 Code Agent. How to Steer Your Multi-Agent System: Human-LLM Collaborative PlanningACM CAIS ’26, May 26–29, 2026, San Jose, CA, USA Code Agent Prompt: Code Generation Given the input question, the solution history that consists of steps for solving the input question and their corresponding outputs, and the current step that must be addressed to solve the input question, write code that solves the current step. - Write the code in Python. - Do not attempt to write code that directly answers the question. Write code that answers the given step. - For math questions, utilize the'pi' symbol and'Rational' from the sympy package for $π$ and fractions, and simplify all fractions and square roots without converting them to decimal values. - Example imports are provided below. Import any of these packages, as well as additional packages as needed. - Only generate the code, do not include any other text. - Print the result of the code - Convert the value of the result in string format before printing to json format - The result should in json format with keys as %s import math import numpy as np import sympy from datetime import datetime from math import comb, gcd, lcm from scipy.optimize import minimize from sympy import symbols, Eq, solve, expand, factor, Matrix from sympy.solvers.inequalities import solve_univariate_inequality from sympy.core.relational import LessThan --- Question: <given subtask> Code: A.2.2 Math Agent. Math Agent Prompt: Expression Generation You are a calculator assistant. Your job is to convert a math sub-task into a calculator-ready arithmetic expression **using only numbers** and basic operators: +, -, *, /, **, and parentheses. **DO NOT include any unknown variables** (e.g., "a", "b") in the output expression. Use only the provided input variable values if they are numeric. If an expression **cannot be fully evaluated** with the given numeric inputs, return null for that variable. ### Input Task: <given subtask> Output Variables: <expected output variables> ## Reasoning Requirement You must provide your reasoning in the "thought" field, explaining: - How you interpreted the mathematical problem - Which numeric values you used and why - How you constructed each expression - Why you couldn't form an expression (if applicable) ### Output Format If an expression can be formed: "thought": "...", "output_results": ["key": "...", "value": "...", ...] else: "thought": "...", "output_results": ["key": "...", "value": null, ...] **Again DO NOT include any unknown variables** (e.g., "a", "b") in the output expression. A.2.3 Search Agent. Search Agent Prompt: Search Query Generation Given the input question, write a concise, informative Google Search query for obtaining information regarding the input question. Do not use quotation --- Question: <given subtask> Search query Output Format: "thought": "...", "output_format": ["key": "...", "value": "..."] Search Agent Prompt: Response Generation You are a rewrite agent. Given the search question, the search results from the Google search api, answer the search question with the information in Search Results. Do not use your own knowledge to answer the question. Remove redundant information that is irrelevant to the question. Fill those information into a json format with keys as %s. If there is no information, fill in empty string. --- Question: <given subtask> Search results: <web search results> Output Format: "thought": "...", "output_format": ["key": "...", "value": "..."] Answer: A.2.4 Commonsense Agent. Commonsense Agent Prompt You are a commonsense agent. You can answer the given question with logical reasoning, basic math and commonsense knowledge. Fill those information into a json format with keys as %s. If there is no information, fill in empty string. --- Question: %s Output Format: "thought": "...", "output_format": ["key": "...", "value": "..."] Output: B User Study Details B.1 Task Questions We provide the 8 questions used in user study tasks in Table 4. B.2 Metrics Effectiveness. Effectiveness captures whether the system sup- ports producing correct and well-formed plans after collaborative revisions. We use the following measures: 2 •Task Success (final outcome accuracy). For each task, we assess whether the participant produced a correct final an- swer according to task-specific criteria. Because tasks differ in output type (exact numeric/string answer vs. computed estimates), we define per-task grading rules and apply them consistently across both conditions. The full task-by-task criteria are detailed in Table 5. •Plan Completeness (plan quality score). To evaluate the quality of the produced plan independent of the final answer, we score each plan using a manual rubric based on whether it contains the essential reasoning/retrieval steps required by the task. Each task is scored on a 0-3 scale, awarding one point per essential step present (up to three points). The task-specific essential steps and grading rubric are detailed in Table 6. 2 The effectiveness grading was conducted manually. One author first graded all cases using the task-specific rubrics, and a second author independently verified the anno- tations. Any disagreements were resolved through discussion until a consensus was reached. ACM CAIS ’26, May 26–29, 2026, San Jose, CA, USAHe et al. Table 4: Task questions used in the user study (§ 5.1.2). Each pattern has two paired questions designed for matched difficulty. TypeQuestion Stepwise Math Reasoning Tom buys a Michael Jordan autographed trading card for $30,000 and spends $10,000 on PSA grading. After grading, the card’s value increases by 210% of the original purchase price. How much profit did he make? Josh decides to try flipping a house. He buys a house for $80,000 and then puts in $50,000 in repairs. This increased the value of the house by 150%. How much profit did he make? Multi-Hop Computation What is the distance in kilometers between the birthplaces of the NBA Sixth Man of the Year in 1995 and 2023? What is the distance in kilometers between the city of birth of the NBA Rookie of the Year in 2005 and 1987? Listed Retrieval & Aggregation What is the average number of chapters in the Game of Thrones series? What is the average number of chapters in the Harry Potter series? Top-K Retrieval & Aggregation What is the top 5 university tuition mean on the East Coast for resident students? What is the top 5 university tuition mean on the West Coast for resident students? Efficiency. Efficiency captures the time and interaction effort re- quired to complete a task. We report: (1) Task Completion Time (from task start to final submitted answer), (2) Interaction Fre- quency, measured as the total number of individual user operations (e.g., text feedback, targeted feedback, node/edge edits, merge/split, undo/redo), and (3) Conversation Turns, defined as the number of discrete interaction–execution cycles (i.e., each cycle is a sequence of user actions culminating in a single node execution or an “Ex- ecute All” run). We compute these measures from the interaction logs and compare them across conditions. B.3 User Study Questionnaire B.3.1 Background Survey. (1) Your User ID: _______________ (2)How familiar are you with Large Language Models (LLMs)? 1 (Not at all familiar)· 7 (Extremely familiar) (3)How frequently do you use LLMs in your work or daily life? • Never • Rarely (A few times a month) • Occasionally (A few times a week) • Frequently (Daily use) • Constantly (Integrated into most of my work/life) (4) Which of the following LLMs have you used? (Select all that apply) ChatGPT, Gemini, Claude, Llama, Other: ___________ (5)In what ways have you interacted with LLMs? (Select all that apply) General user (chat-based tools), Work-related tasks, LLM- powered product development, LLM research/development, Other: _______ (6)How well do you understand LLM limitations (halluci- nation, bias, context limits)? 1 (Not at all)· 7 (Extremely well) (7) I trust LLM-generated information to be accurate. 1 (Strongly Disagree)· 7 (Strongly Agree) (8) I usually verify information provided by an LLM before using it. 1 (Strongly Disagree)· 7 (Strongly Agree) B.3.2 Baseline System Questionnaire (1 = Strongly Disagree, 7 = Strongly Agree). Text Feedback (1) It was easy to provide textual feedback on the plan. (2)My text feedback led to plan modifications that matched my intent. (3) Providing textual feedback required a lot of mental effort. Direct Manipulation (Basic Operations) (1) It was easy to modify the plan using direct manipulation operations (add/edit/remove nodes/edges). (2)My direct manipulation edits led to plan modifications that matched my intent. (3) Providing feedback by direct manipulation required a lot of mental effort. How to Steer Your Multi-Agent System: Human-LLM Collaborative PlanningACM CAIS ’26, May 26–29, 2026, San Jose, CA, USA Table 5: Task success criteria for the user-study questions in Table 4, used in manual grading. TypeOutputSuccess Criterion Stepwise Math ReasoningNumeric/stringExact match to the ground-truth answer after normalization (e.g., commas/whitespace). Multi-Hop ComputationDistance (km)Final distance value is within±10% of the reference answer. Listed Retrieval & AggregationNumber of chaptersFinal average chapter count is within±10% of the reference answer. Top-K Retrieval & AggregationTuition amountFinal value passes a manual reasonableness check (expected scale: tens of thousands USD). If an explicit formula is provided, it must reflect an average (sum÷ 5). Table 6: Plan completeness rubric for the user-study questions in Table 4, used in manual grading. One point per essential step (max 3). TypeEssential Steps (Up to 3 Points) Stepwise Math Reasoning(1) Set up the correct equation/relations; (2) perform the required intermediate computations; (3) produce the final answer from the computed values. Multi-Hop Computation(1) Identify the target player(s); (2) retrieve birthplace(s); (3) obtain coordinates and compute distance. Listed Retrieval & Aggregation(1) Determine the scope (which books count under the stated condition); (2) obtain chapter counts (per book or total); (3) compute the average. Top-K Retrieval & Aggregation(1) Identify a set of top universities; (2) retrieve tuition for each school; (3) compute the average. Overall Satisfaction (1) Overall, I was satisfied with the resulting plan after using this system. (2) I felt in control of how my feedback changed the plan. B.3.3AMBIPOM Questionnaire (1 = Strongly Disagree, 7 = Strongly Agree). Text Feedback (1)It was easy to provide general textual feedback on the entire plan. (2) It was easy to provide targeted textual feedback by selecting specific steps. (3)My textual feedback (general or targeted) led to plan modifi- cations that matched my intent. (4)Providing textual feedback (general or targeted) required a lot of mental effort. Direct Manipulation (Basic + Advanced Operations) (1)It was easy to modify the plan using manual direct manipu- lation operations (add, edit, remove, merge, split, duplicate). (2)It was easy to use LLM-assisted direct manipulation opera- tions (auto-merge / auto-split). (3)My direct manipulation edits (manual or assisted) led to plan modifications that matched my intent. (4)Providing feedback by direct manipulation required a lot of mental effort. (5)I trusted the LLM-assisted operations (auto-merge or auto- split) to make appropriate changes. Overall Satisfaction (1)Overall, I was satisfied with the resulting plan after using this system. (2) I felt in control of how my feedback changed the plan. B.3.4 Post-Experiment Survey. (1) Preferred interaction mode for structural plan modifi- cations: Text Feedback, Targeted Text Feedback, Manual Direct Ma- nipulation, LLM-Assisted Direct Manipulation (2)Preferred interaction mode for semantic or ambiguous modifications: Text Feedback, Targeted Text Feedback, Manual Direct Ma- nipulation, LLM-Assisted Direct Manipulation (3)Overall preferred interaction mode for plan modifica- tions: Text Feedback, Targeted Text Feedback, Manual Direct Ma- nipulation, LLM-Assisted Direct Manipulation (4)Aspects of providing feedback that were most helpful or frustrating: _________ (5)When did you prefer using text vs. direct manipula- tion? Why? _________ (6) Would you consider using this system in daily or work planning tasks? Why or why not? _________ (7) Additional comments: _________ B.4 Detailed Results B.4.1RQ 1: How do advanced interaction types (TF, DM ℎ푖푔ℎ ) affect user performances in terms of effectiveness and efficiency? We evalu- ate each final plan completed by users using the task success and plan completeness rubrics described in § 5.1.4. In the main task, each participant completed 8 tasks. Given our sample size (n=13) and within-participant design, we focus on paired comparisons on the shared tasks and report descriptive statistics and within-participant differences rather than relying on large-sample significance testing. ACM CAIS ’26, May 26–29, 2026, San Jose, CA, USAHe et al. H1: Advanced interaction types (TF, DM ℎ푖푔ℎ ) produce better qual- ity plans than basic ones (GF, DM 푙표푤 ). To test H1, we compare plan quality between advanced types and basic types using rubric-based measures (task success and plan completeness). On average, par- ticipants produced higher-quality plans using the basic types than using the advanced types (task success: 0.712 vs. 0.635; plan com- pleteness score: 2.904 vs. 2.808). These comparisons do not support H1, suggesting that advanced features did not help users improve the plan and produce better quality. H2: high-level structural interactions (DM ℎ푖푔ℎ ) are faster with lower cognitive load than low-level structural interactions (DM 푙표푤 ). To test H2, we compare the baseline system (DM 푙표푤 ) and AMBIPOM (DM ℎ푖푔ℎ ) on three self-contained outcomes: (1) efficiency (task com- pletion time), (2) mental effort (NASA-TLX), and (3) matched inten- tion (7-point self-report) that captures how well the system output aligned with participants’ intended edits. Efficiency. Participants completed tasks slightly faster with DM 푙표푤 than with DM ℎ푖푔ℎ (8.163 vs. 8.256 minutes on average). Matched intention. Participants reported slightly higher matched intention for DM 푙표푤 than for DM ℎ푖푔ℎ (6.385 vs. 6.231). Mental effort. Partici- pants reported higher cognitive load with DM 푙표푤 than with DM ℎ푖푔ℎ (4.385 vs. 3.923). These descriptive comparisons partially support H2: DM ℎ푖푔ℎ reduced cognitive load, but it was slightly slower and matched user intent marginally less than DM 푙표푤 . To further understand participants’ perceptions of semantic text feedback relative to structural interactions, we compare these two interaction modes within each system. In the baseline system, participants reported that GF matched their intention less than DM 푙표푤 (5.615 vs. 6.385), while requiring less mental effort (4.000 vs. 4.385). Participants also reported greater ease-of-use for GF than for DM 푙표푤 (5.692 vs. 5.308). These results suggest that in the baseline system, semantic text feedback felt easier and less effortful, but at the cost of lower perceived alignment with users’ intent. In AMBIPOM, participants reported a similar pattern: text feed- back (GF+TF) matched their intention less than structural edits (DM 푙표푤 +DM ℎ푖푔ℎ ) (5.769 vs. 6.231), while requiring less mental effort (3.154 vs. 3.923). Participants also rated the ease of use of additional interaction options. LLM-assisted DM + ℎ푖푔ℎ received the highest ease- of-use rating (6.000), followed by GF and TF (both 5.846), while manual DM received the lowest ease-of-use rating (5.231). These comparisons suggest that semantic interaction consistently reduced mental effort but was perceived as less aligned with users’ intent than structural interaction; notably, LLM-assisted DM + ℎ푖푔ℎ was rated as the easiest option in AMBIPOM. H3: Targeted text yields fewer conversational turns than general chat. To test H3, we compare interaction length between the base- line system and AMBIPOM using two measures: (1) the number of conversational turns and (2) the total number of editing interac- tions (text or DM operations). Participants had more conversation turns in the baseline system than in AMBIPOM (3.615 vs. 3.404), but they performed fewer interactions in the baseline system than in AMBIPOM (29.750 vs. 45.357). These comparisons support H3: the target replanning reduced conversational turns compared to general chat, while its richer feature set led participants to perform more operations during editing. B.4.2 RQ 2: How do users choose among interaction types for dif- ferent plan modifications, and what recurring patterns emerge in collaborative refinement? Users did not “pick a type”; they assembled hybrid workflows per iteration. In the post-task survey, overall interaction type prefer- ences were broadly distributed across two structural types and two semantic types (DM + ℎ푖푔ℎ : 5; TF: 4; GF: 4; DM: 0). Importantly, DM was not selected as a primary type, but it was still used. Partici- pants used DM for modifications that required fine-grained control, especially in semantic nuance and ambiguous cases where they wanted precise local changes (§ B.4.2). In practice, participants rarely stayed within one type throughout iterations. Instead, they assembled hybrid workflows that alternated between making larger changes via semantic interactions and repairing local details via structural interactions. A common sequence was: (1) review and/or execute the current plan, (2) apply targeted or global text feedback to structurally revise the plan, (3) use manual or LLM-assisted DM to refine task descriptions or reconnect edges, and (4) re-execute to validate the updated plan. These observations suggest that type selection primarily served as a sequencing strategy during collabo- rative refinement rather than as a stable personal preference. Intentions for structural modification pulled strongly toward LLM- assisted DM; semantic modification were more mixed. We hypothe- sized that users intending structural modifications (i.e., graph-level changes like merging and branching) would prefer LLM-assisted DM + ℎ푖푔ℎ , whereas users intending semantic/ambiguous modifica- tions (i.e., changing intent or clarifying steps) would prefer TF. This hypothesis was strongly supported for structural modifications but only weakly supported for semantic/ambiguous modifications. For graph-level changes, participants reported preferring LLM-assisted DM (DM + ℎ푖푔ℎ : 7; GF:4; TF: 2; DM: 0). In think-aloud and logs, partic- ipants used LLM-assisted DM + ℎ푖푔ℎ to rapidly decompose or consoli- date structure. For example, users used auto-split to turn a single dense node into a well-formed subgraph or auto-merge to remove redundant nodes. Several participants described auto-split and auto- merge as the most helpful features. In contrast, when participants worked on semantic or ambiguous modifications, preferences were evenly distributed (TF: 4; GF:3; DM + ℎ푖푔ℎ : 3; DM: 3). Rather than converging on a single type, participants chose a different type de- pending on the amount of semantic change required. For instance, clarifying an underspecified step or resolving a variable mismatch often required localized restructuring. In practice, many semantic changes required localized structural edits (i.e., splitting a complex step into a subgraph and reconnecting inputs/outputs). As a result, participants frequently paired TF (within a targeted region) with DM (to confidently perform fine-grained adjustments). Type choice was mediated by an effort-control-risk trade-off. Par- ticipants implicitly treated DM as high-control but high-effort, LLM-assisted DM + ℎ푖푔ℎ as a structural leverage with bounded risk, TF as high semantic leverage with bounded scope, and the GF as the lowest authoring effort but the highest verification burden. How to Steer Your Multi-Agent System: Human-LLM Collaborative PlanningACM CAIS ’26, May 26–29, 2026, San Jose, CA, USA Across participants, type choice reflected an implicit trade-off be- tween effort, control, and rewrite risk. P8 mentioned that it was a “trade-off between DM (know what will happen but more effort) and text (easy)”. DM was consistently treated as the most controllable option, but also the most labor-intensive, including heavily manual editing, variable selection, edge connecting, and layout organiza- tion. Consistent with this, participants used DM primarily for local, low-risk operations, such as repairing edge connections, tightening input/output variables, or making brief description edits, especially when they already knew what needed to change (as P1 and P10 noted, DM felt preferable for minor modifications). GF reduced mechanical effort but introduced uncertainty. P12 framed GF as “rolling a dice,” especially for global-plan replanning. P12 worried that global replanning could “blow up their plan” and therefore avoided replanning entire graphs. LLM-assisted DM + ℎ푖푔ℎ occupied a middle ground by providing structural leverage with minimal instruction. Participants used auto-split for routine decomposition and as idea-seeking when uncertain how to proceed (P7). These dynamics align with participants’ interface requests aimed at reduc- ing DM overhead and verification burden: P1 requested auto-save for input/output edits; P8 suggested to have “visual difference’ af- ter revisions; and P7 asked for loop/iteration support to reduce repetitive manual text editing. Collaborative refinement showed two recurring rhythms: review- first versus execute-first. Participants diverged into two stable re- finement rhythms that determined whether they executed or edited. Most participants (10/13) adopted a review-first rhythm: they in- spected the plan graph node by node, cleaned unnecessary nodes, and attempted to make the plan “correct enough” before execut- ing it. A smaller group (3/13) followed an execute-first rhythm: they executed early to surface failures and used results to guide replanning. Despite this difference, both groups converged on the same iterative structure: broad edits via text feedback (targeted or global), followed by local DM patches, followed by re-execution. Task context shaped where effort was put. Decomposition-heavy tasks (i.e., tuition/books) often elicited text-based feedback, while multi-hop questions often pulled users toward DM for duplication, edge wiring, and intermediate verification. Users used text feedback as an executable specification (mostly prescriptive), switching to diagnostic feedback when debugging. We analyzed 178 text feedback messages across two systems: the base- line system supported only GF, whereas AMBIPOM supported both GF and TF. In the baseline system, participants provided 97 GF. In AMBIPOM, participants used TF slightly more often than GF (42 vs. 39). Across both systems, participants tend to use GF when they anticipate plan-wide changes, such as large decompositions, the insertion of missing intermediate nodes, and revisions to the output variables. In the GF, they often referenced explicit node IDs (i.e., “copy node 1. . . ”, “modify node 5. . . ”). By contrast, when participants viewed the issue as localized, such as an input mismatch, a single node too complex, or steps needing duplication, they more often used the TF (i.e., “split this node into X nodes”). Feedback style was overwhelmingly prescriptive/instructive (169/178), where users provide commands to rewrite the plan graph (i.e., “split”, “connect”, “use output from node X”). This pattern occurred in both the GF and TF, indicating that participants treated replanning as specifying an algorithm rather than as providing high- level guidance. The minority diagnostic feedback (9/178) occurred primarily during debugging: users first identified a correctness breakdown (e.g., incorrect formulas, incorrect variable semantics, or outputs that did not match the task). In these moments, users wrote feedback more like bug reports that named the mismatch and requested correction, sometimes followed by a prescriptive restatement of the intended computation. Trust increased in-task but verification declined later in sessions: a trust-fatigue paradox that interacts with type choice. Participants reported an increase in trust in LLM-assisted DM + ℎ푖푔ℎ from pre-task background LLM trust to in-task experience (3.620 to 5.538 on a 7-point scale). They also self-reported a strong verification habit (M = 5.310, SD = 1.18). However, observations in the user study revealed a consistent pattern of verification decay over time: par- ticipants often checked intermediate results early on, but reduced verification in the second half of the session as they rushed toward task completion. Across participants, we observed three recurring verification behaviors: (1) manual recomputation (especially for numeric tasks), (2) inspection of intermediate node outputs and ex- ecution traces to diagnose failures, and (3) lighter checks later in the session due to fatigue (i.e., accepting plausible-looking outputs with- out re-checking all dependencies). This shift created a trust-fatigue paradox: trust in LLM-assisted DM + ℎ푖푔ℎ increased with experience, while verification effort decreased. Verification behaviors were also influenced by type choice. When participants anticipated higher risk or uncertainty, they tended to limit changes by using DM and TF to localize errors. When they were time-constrained, fatigued, or perceived the changes as low-risk, they often accepted LLM- generated results without checking. Overall, the increase in trust did not translate into consistently rigorous verification. Instead, verification appeared as a constraint resource that diminished with fatigue, shifting participants toward faster but potentially riskier interaction strategies. C Experiment Details C.1 Detailed Integration Results Complementing the main results in Table 1, Table 7 reports per- operation integration success rates across all conditions, including boundary-flexible variants. C.2 Boundary Analysis Complementing the analysis in § 6.5, we further analyze TF+B and TF+B+P, which extend TF and TF+P, respectively, by allowing flexible boundary interfaces during reintegration. Overall, integra- tion success rates increase from TF to TF+B, TF+P, and TF+B+P (Table 7). This pattern suggests that both boundary flexibility and full-plan context improve reintegration success, with full-plan con- text providing a slightly larger benefit than boundary flexibility alone. Combining both mechanisms, as in TF+B+P, yields the high- est success rate among targeted replanning conditions. A similar trend appears for LLM-assisted merge operations: TF 푚푒푟푔푒 +B≥ TF 푚푒푟푔푒 . ACM CAIS ’26, May 26–29, 2026, San Jose, CA, USAHe et al. Table 7: Integration success rates by operation type and feedback condition. “–” indicates not applicable. OperationGF TF TF split TF merge TF+P GF-to-DMTF+B TF split +B TF merge +B TF+B+P Add Node1.000 0.870–0.9200.8200.900–0.945 Change Task Description 1.000 1.000–1.0000.8601.000–1.000 Change Node Agent1.000 1.000–1.0001.0001.000–1.000 Merge Sequential1.000 0.995–1.0001.0000.5401.000–1.0001.000 Merge Parallel1.000 0.995–0.9851.0000.720 1.000–1.0001.000 Split Sequential1.000 1.0001.000–1.000–1.0001.000–1.000 Split Parallel1.000 1.0001.000–1.000–1.0001.000–1.000 However, boundary flexibility also affects structural deviation (Table 2). Within targeted replanning, allowing boundary interfaces to be updated can reduce integration failures, but it may also lower plan stability. Compared with boundary-freezing variants, TF and TF+P, boundary-flexible variants, TF+B and TF+B+P, can intro- duce additional structural changes because edits to the selected subgraph may propagate through its interfaces with the unchanged portions of the plan. The auto-merge vs. auto-split asymmetry ob- served in § 6.5 is amplified under boundary-flexible reintegration. For parallel split edits, both TF+B and TF 푠푝푙푖푡 +B show a large in- crease in GED (17.180 and 17.220) compared with other refinement settings (Table 2). This suggests that allowing boundary interfaces to change during reintegration, when combined with split oper- ations, can trigger revisions beyond the intended subgraph and produce plan topologies that diverge sharply from the gold struc- ture. C.3 Naturally Occurring Faulty Plans To evaluate revision on naturally occurring faulty plans, we prompted three planner models of varying capability (GPT-3.5 Turbo, GPT- 4o-mini, and GPT-5-mini) to generate plans for the benchmark questions (§ 6.2). Each model was run once per instance, yielding 200 plans per model. Stronger planner models produced faulty plans much less fre- quently. Out of 200, GPT-3.5 Turbo generated 51 faulty plans and 16 error plans, GPT-4o-mini generated 28 faulty plans (no error plans), and GPT-5-mini generated only 5 faulty plans (no error plans). Here, faulty plans preserve the expected plan structure but contain incomplete or incorrect planning content, whereas error plans deviate from the required format and cannot be parsed. Man- ual inspection showed that failures concentrated in edge-linking errors and input/output variable mismatches rather than in overall logical structure, with many plans containing multiple entangled defects. To assess revision quality in this setting, we conducted a repair evaluation on the 51 faulty plans from GPT-3.5 (the noisiest planner: 26 from Stepwise Math Reasoning, 4 from Multi-Hop Computation, 15 from Listed Retrieval & Aggregation, 6 from Top-K Retrieval & Aggregation), simulating GF and TF using a strong LLM (GPT-5.4). We report execution accuracy of revised plans. GF outperformed TF on three of four subsets (Stepwise Math Reasoning: 0.615, Listed Retrieval & Aggregation: 0.133, Top-K Retrieval & Aggregation: 0.333). Both methods failed on Multi-Hop Computation, and TF re- covered almost no plans elsewhere (Listed Retrieval & Aggregation: 0.067; otherwise 0). This gap reflects two factors. First, LLM-simulated targeted se- lection and feedback are systematically lower-quality than LLM- simulated global feedback: TF must both identify the faulty subgraph and formulate a localized repair, compounding error opportunities. Next, natural failures are often globally distributed across the plan rather than localized, making them better suited to holistic revi- sion than local repair. The Multi-Hop case illustrates the upper bound: when faults span the plan structure, even GF cannot fully recover. This strengthens our main synthetic-benchmark finding (§6.5): naturally distributed defects, like our synthetic break types, favor holistic revision over local repair.

Instant research discovery