Paper deep dive
Improving the Efficiency of Language Agent Teams with Adaptive Task Graphs
Elizabeth Mieczkowski, Alexander Ku, Tiwalayo Eisape, Dilip Arumugam, John Matters, Katherine M. Collins, Ilia Sucholutsky, Thomas L. Griffiths
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 93%
Last extracted: 7/8/2026, 10:50:10 AM
Summary
LATTE (Language Agent Teams for Task Evolution) is a novel orchestration framework for multi-agent LLM teams that utilizes a shared, dynamically evolving coordination graph to balance structured coordination with adaptive task allocation. It introduces a hybrid lead-worker model with explicit graph mutation operators, demonstrating significant improvements in token efficiency, wall-clock time, and accuracy over static, hierarchical, and decentralized baselines across data analysis, debugging, and code generation tasks.
Entities (17)
Relation Signals (13)
LATTE → uses → Dynamic Coordination Graph
confidence 95% · agents operating within the LATTE framework construct and maintain a shared, evolving coordination task graph.
LATTE → reduces → Token usage
confidence 94% · LATTE reduces token usage, wall-clock time, communication, and coordination failures
LATTE → reduces → Wall-clock Time
confidence 94% · LATTE reduces token usage, wall-clock time, communication, and coordination failures
LATTE → evaluatedon → Library Extension
confidence 93% · Task 3: Library Extension. Agents extended a Python text-processing library
LATTE → evaluatedon → Exploratory Data Analysis
confidence 93% · We evaluate LATTE against several existing multi-agent frameworks across three newly-designed collaborative domains: exploratory data analysis
LATTE → evaluatedon → Debugging
confidence 93% · Task 2: Debugging. Agents debugged an existing repository against a test suite
Graph Mutation Operators → modify → Dynamic Coordination Graph
confidence 93% · a set of graph mutation operators allow the team to restructure coordination as execution unfolds.
LATTE → coordinates → Lead Agent
confidence 92% · a Lead responsible for maintaining coordination structure and a set of Workers responsible for executing assigned subtasks.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Large language models (LLMs) are increasingly deployed in teams, yet existing coordination approaches often occupy two extremes. Highly structured methods rely on fixed roles, pipelines, or task decompositions assigned a priori. In contrast, fully unstructured teams enable adaptability and exploration but suffer from inefficiencies such as error propagation, inter-agent conflicts, and wasted resources (measured in time, tokens, or file operations). We introduce Language Agent Teams for Task Evolution (LATTE), a framework for coordinating LLM teams inspired by distributed systems, where processors must operate under partial observability and communication constraints. In LATTE, a team of agents collaboratively construct and maintain a shared, evolving coordination graph which encodes sub-task dependencies, individual agent assignment, and the current state of sub-task progress. This protocol maintains consistency while empowering agents to dynamically allocate work, adapt coordination, and discover new tasks. Across multiple collaborative tasks and a variety of base models, we demonstrate how LATTE reduces token usage, wall-clock time, communication, and coordination failures (e.g. file conflicts and redundant outputs) while matching or exceeding the accuracy of standard designs including MetaGPT, decentralized teams, top-down Leader-Worker hierarchies, and static decompositions.
Tags
Links
- Source: https://arxiv.org/abs/2605.06320v1
- Canonical: https://arxiv.org/abs/2605.06320v1
Trouble viewing inline? Open PDF directly →
Full Text
89,991 characters extracted from source content.
Expand or collapse full text
Improving the Efficiency of Language Agent Teams with Adaptive Task Graphs Elizabeth Mieczkowski 1∗ Alexander Ku 1 Tiwalayo Eisape 1 Dilip Arumugam 1 John Matters 1 Katherine M. Collins 1,2,3 Ilia Sucholutsky 4 Thomas L. Griffiths 1 1 Princeton University 2 University of Cambridge 3 MIT 4 New York University Abstract Large language models (LLMs) are increasingly deployed in teams, yet existing coordination approaches often occupy two extremes. Highly structured meth- ods rely on fixed roles, pipelines, or task decompositions assigned a priori. In contrast, fully unstructured teams enable adaptability and exploration but suffer from inefficiencies such as error propagation, inter-agent conflicts, and wasted resources (measured in time, tokens, or file operations). We introduce Language Agent Teams for Task Evolution (LATTE), a framework for coordinating LLM teams inspired by distributed systems, where processors must operate under partial observability and communication constraints. In LATTE, a team of agents col- laboratively construct and maintain a shared, evolving coordination graph which encodes sub-task dependencies, individual agent assignment, and the current state of sub-task progress. This protocol maintains consistency while empowering agents to dynamically allocate work, adapt coordination, and discover new tasks. Across multiple collaborative tasks and a variety of base models, we demonstrate how LATTE reduces token usage, wall-clock time, communication, and coordination failures (e.g. file conflicts and redundant outputs) while matching or exceeding the accuracy of standard designs including MetaGPT, decentralized teams, top-down Leader-Worker hierarchies, and static decompositions. 1 Introduction Collaboration can empower groups to achieve tremendous feats [50,20], but it comes with substantial coordination costs. In complex domains such as software development, distributing work across a team can outperform even the most skilled programmer [9,54], but also incurs substantial overhead [6]. What happens when one collaborator modifies a core function that others depend on? In what order should interdependent tasks be executed? How should work be allocated when team members differ in speed or reliability? And how can teams prevent local errors from cascading through the system? In practice, these challenges arise routinely, including concurrent edit conflicts [15], super-linear communication overhead [6], dependency misalignment [7,32], delays from distribution [21], heterogeneous productivity [45], and stragglers [10]. Collaboration can dramatically amplify capability, but only when coordination is effectively managed. Recent work has shown that LLM teams can improve accuracy and problem-solving by distributing tasks, roles, and context across multiple agents [2,5,29,49,56,61], demonstrating emergent coordination [38]. Despite these successes, the design of LLM teams remains fundamentally limited. Modern LLMs derive much of their power from their ability to flexibly adapt to new contexts and tasks [13]. In contrast, most existing LLM team architectures impose rigid coordination structures, assigning fixed roles or pre-specifying task decompositions prior to execution [22,40]. We argue that ∗ Code: https://github.com/emieczkowski/latte Preprint. arXiv:2605.06320v1 [cs.MA] 7 May 2026 LATTECommon LLM team frameworks a)Pipeline b) Leader-Worker c) Decentralized managerengineerscientistreporter repo/ plan.md main.py src/ repo/ plan.md repo/ plan.md main.py src/ analysis.py repo/ plan.md main.py src/ analysis.py report.tex lead repo/ plan.md repo/ main.py analysis.py repo/ report.tex repo/ plan.md main.py src/ analysis.py report.tex Phase 0 lead “Perform exploratory data analysis and report any interesting findings” preprocess & filter G 0 Phase 1 lead preprocess & filter worker_1 worker_1, preprocess and filter this CSV file. Report back shape, names, etc... Phase 2 lead preprocess & filter worker_1 Based on the data, we should explore the following: ... distrib- utions DISCOVER correl- ations time patterns worker_1, continue with distrs. worker_2, compute corrs. worker_3, look at time patterns. worker_1 G 1 G 2 worker_2worker_3 frontier F 2 Phase N lead preprocess & filter distrib- utions correl- ations time patterns G N worker_2 worker_1 bimodal trimodal verify outliers worker_3 RELEASE ASSIGN VERIFY COMPLETE CLAIM GRAPH MUTATION OPERATORS CLAIMVERIFYDISCOVER ASSIGNCLOSERELEASE COMPLETE in_progressdone pendingassigned Figure 1: LATTE. Most existing LLM team designs are either highly structured (a. pipeline systems; b. Leader-Worker hierarchies) or unstructured (c. decentralized teams). (d) LATTE provides teams with a dynamic coordination graph that they collectively maintain and adapt. For example, in a data analysis task, the Lead initializesG 0 and assigns Worker 1 to preprocess. As Worker 1 learns about the data, it spawns parallel subtasks on the frontier (DISCOVER) which the Lead then ASSIGNs to Workers 2 and 3. As this process continues, the Lead can RELEASE stragglers and CLOSE completed subtasks while Workers CLAIM frontier tasks proactively to avoid idleness. The shared graph serializes coordination decisions while preserving parallelism. constraining LLM teams in this way limits their capacity for dynamic adaptation [42] and introduces fragility, whereby failures or hallucinations in the Lead propagate downstream [24]. Unstructured or decentralized LLM teams are more flexible [31], yet face their own challenges. Without coordination scaffolding, agents frequently overwrite one another, produce inconsistent or incorrect outputs, and erroneously report task completion [35,46]. These failures worsen when tasks must be performed sequentially, where adding agents to a team leads to over-communication and performance degradation [26,35]. Self-coordinating teams often cannot outperform single expert models [37] and are unable to overcome failures propagated by individual agents [3]. This suggests a fundamental tension in designing LLM teams: structure is needed to improve coordination and inter-agent consistency, but over-specification suppresses the adaptability that makes LLMs powerful. To resolve this tension, we propose LATTE (Language Agent Teams for Task Evolution), a formal orchestration framework for LLM teams to explicitly represent and adapt their own coordination during execution (Figure 1). Drawing inspiration from distributed systems — where protocols enable reliable task scheduling under partial information and dynamic conditions [1,34,55] — agents operating within the LATTE framework construct and maintain a shared, evolving coordination task graph. In this graph, nodes represent subtasks that agents are assigned to, edges encode completion dependencies between subtasks, and a set of graph mutation operators allow the team to restructure coordination as execution unfolds. This graph serves as an evolving record of task decomposition, progress, roles, and active effort. Each agent proposes updates to the graph based on local context, which are reviewed and merged by a single agent. This division of labor reduces bottlenecks and single-points-of-failure that arise with hierarchical designs, provides explicit mechanisms for moni- toring stragglers, and naturally serializes updates to prevent divergent local views or inconsistencies. The resulting framework preserves coherence and efficiency without sacrificing the capacity for emergent, context-sensitive adaptation. Our contributions are as follows: 1.A formal orchestration framework for LLM teams via dynamic task graphs: We define a set of graph mutation operators (Discover, Assign, Claim, Complete, Release, Close, and Verify) with explicit preconditions, postconditions, and invariant-preservation guarantees which culminate in a rigorous execution protocol for multi-agent LLM coordination. We demonstrate that the graph structure induces desirable runtime properties such as maximal parallelism via frontier nodes. 2.A hybrid centralized-decentralized model: We introduce a two-tier coordination model in which worker agents propose structural modifications to the graph and a lead orchestrator accepts 2 or rejects them, preserving global consistency while enabling local adaptability. This division of labor is grounded in a probabilistic account of task decomposition. 3. LLM team interpretability: LATTE externalizes coordination during task execution, providing ways to interpret and audit team behavior. Our evaluation provides a suite of coordination metrics (overwrite rate, concurrent conflicts, wasted characters, idle rounds, and straggler tail latency) that address a systematic gap in how multi-agent LLM systems are benchmarked. 4.Empirical validation: LATTE consistently reduces token consumption, wall-clock time, inter- agent messages, file overwrites, consistency conflicts, and total output all while achieving higher accuracy than alternatively-structured and widely-used LLM team implementations. Together, these results suggest that explicit coordination structures maintained by agents themselves are a viable path towards LLM teams that are simultaneously more efficient, interpretable, and adaptive. 2 Related Work Prior work on LLM team coordination clusters around three patterns. Static systems like MetaGPT and ChatDev assign fixed functional roles and task structures before execution begins [22,40]. While this simplifies scheduling, static assignments may struggle when new dependencies emerge or workloads shift mid-execution. Hierarchical or centralized frameworks such as HuggingGPT and recent meta-agent approaches use a lead agent to plan, dispatch, and synthesize work across subordinates [47,28]. Centralization can enforce consistency but creates bottlenecks and single points of failure, which are especially acute in LLM teams where the Lead may hallucinate, crash, or fail to consolidate distributed progress [46]. Decentralized teams avoid bottlenecks by letting agents operate autonomously, improve diversity, and distribute long contexts across agents [14,29]. However, agents operating on local views of task state can produce conflicting or redundant outputs, and scaling the number of agents can degrade performance, particularly in tasks requiring sequential reasoning, expert agent assignment, or consistency [26, 37, 35]. Task graphs from distributed computing offer a natural improvement to task decomposition and assignment: nodes represent tasks, edges encode precedence constraints, and schedulers assign work across processors efficiently [51,36]. Classic schedulers like HEFT compute globally optimized assignments before execution; dynamic variants and work-stealing approaches such as NABBIT assign tasks online as they become available [25,1]. However, these systems assume well-defined tasks and explicit control mechanisms. Extending task graphs to LLM teams requires supporting agents that autonomously discover, modify, and claim tasks in natural language. To our knowledge, LATTE is the first framework to bridge this gap: LLM teams jointly construct, maintain, and revise a shared task graph as an online, dynamic coordination structure during execution. We provide an extended discussion of related work in Appendix A1. 3 LATTE: Language Agent Teams for Task Evolution We establish four key desiderata for a structured LLM team execution framework motivated by the limitations of prior architectures. D1. Hybrid coordination: To avoid the bottlenecks of fully centralized systems and the inconsistency of fully decentralized ones, coordination should be hybrid. Decisions affecting shared state (e.g., graph updates or artifacts) must be centrally mediated, while task execution should be opportunistic to allow for parallel progress. D2. Adaptive scaling: The framework should deploy agents efficiently, dynamically activating agents based on the current workload while maximizing parallelism when dependencies allow. D3. Fault tolerance and monitoring: Because agents may stall, hallucinate, or produce null outputs, the system must support active monitoring and dynamic reallocation to detect and reassign tasks from unresponsive agents. It should also support auditing, where agents can proactively identify and flag high-uncertainty outputs that warrant additional quality control. 3 D4. Context scoping: To prevent memory overload and confusion, each agent should receive a scoped context. Workers should see only their local subtask, while the Lead’s view is restricted to the coordination graph rather than the full execution history. 3.1 Dynamic coordination graph The set of agentsA =ℓ∪Win a LATTE team belong to one of two types: a Leadℓresponsible for maintaining coordination structure and a set of WorkersWresponsible for executing assigned subtasks. Coordination proceeds through a shared dynamic coordination graph that explicitly tracks task progress, agent assignments, and shared state as execution unfolds. Definition 1 (Dynamic Coordination Graph). A dynamic coordination graphG t at roundt ∈ 1,...,Tis a directed acyclic graphG t = (V t , E t , λ t ). Here,V t is a finite set of nodes, each corresponding to a subtask.E t ⊆ V t × V t is the set of dependency edges between subtasks such that(u,v) ∈ E t implies that subtaskvcannot begin untiluis complete.λ t : V t → (A ∪ ⊥) × Sassigns each node an agent and a status, where⊥denotes unassigned and S :=pending, assigned, in_progress, done, verified. A strength of the coordination graph is encoding opportunities for parallelism during task execution. Definition 2 (Frontier). The frontierF t ⊆ V t at roundtis the set of pending nodes with no unsatisfied dependencies: F t :=v ∈ V t | status(v) = pending and∀(u,v)∈ E t , status(u) = done. F t determines which subtasks are immediately executable, and thus corresponds to the number of Workers that can proceed in parallel at t. 3.2 Graph mutation operators The asymmetry in information between Lead and Workers directly determines operator permissions. Workerw i , reasoning from local traced (i) t about its subtaskv, has sufficient information to propose local changes, such as discovering new subtasks encountered during execution (DISCOVER) and certifying its subtask’s completion (COMPLETE). It lacks visibility beyondv, preventing safe and holistic evaluation of proposals with graph-wide consequences, such as forcing completion of nodes whose downstream effects it cannot observe (CLOSE). The Leadℓmaintains global visibility into G t and exclusively controls operators with graph-wide consequences, such as RELEASE to reassign stalled work and VERIFY to intercept errors. Unlike the other operators, task acquisition need not be centralized. Rather than requiringℓto ASSIGN every subtask, idle Workers may proactively claim available work directly fromv ∈ F t via CLAIM(v). This mirrors work-stealing or self-scheduling principles in distributed computing [39,1], where fast processors claim ready tasks from a shared queue rather than waiting on a central scheduler, reducing overhead and improving wall-clock time. Concurrent claims on the samev ∈ F t are resolved by the orchestrator, preserving serialization without centralizing acquisition. OperatorCallerOutput DISCOVER(v, deps) ℓ,wAdd pending node v with deps ASSIGN(v,w)ℓAssign pending v to Worker w CLAIM(v)wWorker w claims node v COMPLETE(v)wMark v as finished by its w RELEASE(v)ℓReturn v to pending CLOSE(v)ℓForce-complete v VERIFY(v)ℓSpawn verification for v Table 1: Graph mutation operators. Accordingly, LATTE pro- vides a set of graph mu- tation operators with ex- plicit preconditions, post- conditions, and invariant- preservation guarantees (Ta- ble 1, Appendix A3). Un- like prior multi-agent LLM frameworks, where coordi- nation contracts are implicit in role prompts, LATTE makes these contracts ex- plicit and verifiable for every operator. DAG invariance. All operators preserve the DAG invariant onG t . DISCOVER is the only operator that adds edges toG t , and its preconditionv /∈ V t guarantees no self-loops. Additionally, requiring deps⊆ V t with the resulting graph acyclic ensures no cycles are introduced. All remaining operators modify only λ t and leave (V t ,E t ) unchanged. 4 Probabilistic motivation. This Leader-Worker division of labor can also be interpreted through a probabilistic lens, viewing the dynamic evolution of the task graph as an approximate posterior inference problem. To enable context scoping, LATTE decouples the graph updating process into proposal (by the Workers) and evaluation (by the Lead), which is conceptually grounded in sampling procedures such as Metropolis-Hastings. Further details of this motivation can be found in Appendix A2. 3.3 LATTE execution The full execution protocol is described in Algorithm A4.5. LATTE proceeds in two phases: a preliminary planning phase followed by an iterative execution loop over the dynamically evolving coordination graph. During planning,ℓis given the task description and initializesG 0 by proposing an initial decomposition of the problem via DISCOVER operations. During execution, at each round t = 1,...,T, agents are selectively dispatched to operate on the current graphG t . Each round consists of five steps: (1) heartbeat monitoring (i.e., periodic liveness checks) to flag stragglers or stalled Workers toℓ; (2) frontier identification to computeF t , the queue of available tasks; (3) dispatching for agents that are in-progress, assigned to new frontier tasks, andℓwhen necessary; (4) parallel execution of all selected agents; and (5) termination, which returns all task outputs and G t . 3.4 Coordination properties The LATTE protocol equips LLM teams with the structural tools to satisfy the four design desiderata (D1-D4) introduced in Section 3.1. D1. Hybrid coordination: To balance consistency with adaptability, the Leadℓmaintains exclusive control over operators with graph-wide consequences (ASSIGN, VERIFY, CLOSE), while Workers woperate autonomously within their local scope. Crucially, LATTE enables self-scheduling: idle Workers may invoke CLAIM(v) for anyv ∈ F t , allowing for opportunistic execution that reduces Lead overhead and improves wall-clock time [39]. All structural updates toG t are serialized, preventing race conditions and inconsistencies to shared state. D2. Adaptive scaling: At each roundt, the number of Workers dispatched by LATTE equals min(|F t |,|W|). This ensures maximal parallelism givenG t ; no valid protocol can dispatch more Workers attwithout violating a dependency constraint. Agents are activated only when there is available work, eliminating idle computation. D3. Fault tolerance and monitoring: The heartbeat mechanism flags Workers that have been assigned but remain inactive forHrounds, surfacing potential stalls toℓbefore they block progress. Upon detecting a straggler,ℓmay invoke RELEASE(v) to return the task to a pending state, making it available for immediate re-assignment or self-scheduling. In addition, rather than mandating an expensive review of every subtask, LATTE supports emergent verification. The VERIFY operator is invoked selectively byℓon nodes judged to be high-risk or high-uncertainty. This allows the rigor of quality control to scale dynamically with the complexity of the task graph. D4. Context scoping: To mitigate context accumulation and token exhaustion, Workers receive only the description of their assigned subtask and its direct predecessors. The Lead receivesG t and agent messages but does not ingest individual Workers’ full execution traces. These constraints bound the context each agent must attend to, reducing reasoning errors caused by irrelevant information. 4 Experiments We evaluate LATTE against several existing multi-agent frameworks across three newly-designed collaborative domains: exploratory data analysis, debugging, and code generation. These domains were chosen to stress-test different coordination properties (parallelism, consistency, and adaptabil- ity). Experimental settings and prompt designs are provided in Appendices A4 and A5. Full task specifications and evaluation criteria are provided in Appendix A6. Each task rewarded different combinations of the coordination properties above: 5 A)Expected cost B) Accuracy-efficiency tradeoff Tokens / success Seconds / success Claude Sonnet 4-6 GPT 5.2 LATTELeader-Worker Dec. StaticMeta-GPT Mean accuracy Mean normalized token cost Figure 2: Efficiency-accuracy tradeoff. A) LATTE achieves greater efficiency than alternative frameworks. We measure expected cost (total tokens or wall-clock time weighted by trial completion rate) to account for runs in which teams fail to terminate. B) LATTE achieves higher task success with lower token consumption (normalized across tasks) on the accuracy-vs-token-cost Pareto frontier. Task 1: Exploratory Data Analysis. Agents performed exploratory analysis on an opaque dataset, requiring preprocessing, analysis, visualizations, and synthesis of findings. Correctness was evaluated by a private test suite checking whether agents correctly identified planted data properties. Task 2: Debugging. Agents debugged an existing repository against a test suite, requiring iterative test execution and code modification. This task rewards both parallelism (independent bugs can be diagnosed simultaneously) and consistency (some functions can only be verified after dependencies are fixed). We placed several bugs in a signal-processing library, and success required teams to pass all tests in a given suite. Task 3: Library Extension. Agents extended a Python text-processing library by completing two existing classes and building six new modules from stubs. The task has natural sequential dependencies, parallel modules, and a final integration step. Correctness was evaluated by a private test suite after completion. Unlike Tasks 1 and 2, the required functions are fully known in advance. We evaluate the performance of LATTE against four baseline team structures. We test Leader- Worker hierarchies, where a single Lead synthesizes and assigns tasks to four Workers; MetaGPT [22], representative of pipeline-based LLM teams with different roles (Product Manager, Architect, Project Manager, Engineer, QA Engineer); decentralized teams with 5 peer agents; and a static task graph ablation, in which the Lead initializes assignments based on its priorG 0 and agents cannot update the graph after planning. We maintained a team size ofN = 5to benchmark against MetaGPT. For each team structure, we tested two frontier base models: Claude Sonnet 4-6 (Anthropic; claude-sonnet-4-6) and GPT-5.2 (OpenAI;gpt-5.2). We ran 10 trials per condition for a total of 300 trials (5 conditions × 2 models × 3 tasks × 10 repetitions). Full implementation details are provided in Appendix A4 and A5. 5 Results 5.1 LATTE achieves higher accuracy and efficiency than existing LLM teams Across tasks and base models, LATTE consistently achieves a superior accuracy–efficiency tradeoff, Pareto-dominating existing LLM team structures (Fig. 2; Table 2). Computational cost. Using one-sided Mann-Whitney U tests on normalized, pooled costs across all tasks and models, LATTE achieves a mean token cost of47.5%, nearly half that of the next-best method, the static graph ablation (M = 86.9%,p < 0.01). All other baselines are also more 6 Table 2: Accuracy, token usage, and wall-clock time across successful trials per task (± SEM). LATTE Leader-Worker DecentralizedStaticMetaGPT Acc. (%) Agg. 80± 4 70± 5 74± 4 58± 5 34± 7 Data Analysis 96± 1 94± 1 93± 2 88± 3 75± 2 Debug 100± 0 90± 7 100± 0 44± 13 32± 11 Library Ext. 40± 2 23± 2 27± 2 40± 2 6± 4 Tokens (K) Agg. 148± 14 379± 51 419± 47 297± 40 397± 59 Data Analysis 122± 13 257± 60 271± 60 403± 93 390± 61 Debug 227± 33 642± 103 792± 73 286± 36 236± 41 Library Ext. 98± 9 169± 17 194± 25 140± 12 707± 188 Wall-clock (m) Agg. 3.5± 0.3 5.9± 0.6 3.7± 0.3 6.0± 0.6 11.5± 1.2 Data Analysis 3.2± 0.3 4.9± 0.9 2.9± 0.5 6.2± 0.6 8.7± 1.7 Debug 5.3± 0.6 9.1± 1.2 6.1± 0.4 6.2± 0.6 8.7± 1.7 Library Ext. 2.1± 0.2 3.6± 0.3 2.2± 0.2 3.4± 0.3 18.9± 3.4 expensive: MetaGPT (M = 228.7%,p < 0.01), Leader-Worker (M = 104.2%,p < 0.01), and decentralized (M = 120.9%, p < 0.01). Wall-clock time. LATTE (M = 66.7%) is faster than static graphs (M = 110.7%,p < 0.01), MetaGPT (M = 289.0%,p < 0.01), and Leader–Worker teams (M = 105.7%%,p < 0.01). Decentralized teams also have a higher mean latency than LATTE, though the difference is not statistically significant (M = 69.3%, p = 0.34). Task accuracy. LATTE achieves the overall highest task accuracy (79.7%), surpassing static graphs (57.6%,p < 0.01), fixed pipelines (MetaGPT;33.9%,p < 0.01), Leader-Worker teams (70.1%, p = 0.04), and decentralized teams (73.9%,p = 0.16). Consistent with our probabilistic motivation, LATTE achieves comparable accuracy to the static ablation on Task 3 (using substantially less wall-clock time and fewer tokens) but much greater accuracy on Tasks 1–2. When task structure is known in advance, the initial graphG 0 can be well-specified, leaving fewer subtasks for LATTE to dynamically discover. 5.2 LLM teams successfully utilize dynamic coordination graphs via LATTE Figure 3 demonstrates that LLM teams successfully utilize the full expressive power of the LATTE protocol to manage task complexity. DISCOVER is the most frequent operator, confirming that teams actively expand their coordination graphs as new requirements emerge. The Lead effectively delegates via ASSIGN, yet the high success rate of Worker-initiated CLAIM operations suggests that decentralized self-scheduling significantly reduces coordination bottlenecks. Notably, LATTE teams exhibit emergent fault tolerance through the selective use of recovery operators. The Lead invoked RELEASE in 36% of trials to reassign straggling tasks. Similarly, VERIFY was invoked in 19% of trials, demonstrating that the Lead can trigger verification when deemed necessary. Specifically, Leads triggered VERIFY more often in high-uncertainty, challenging trials, where teams took an average of 18.1 rounds to pass tests. In contrast, trials that completed successfully in 8.1 rounds on average contained no verification events. These behaviors are particularly encouraging as they indicate LATTE’s capacity for autonomous fault tolerance, monitoring, and strategic resource allocation. Crucially, these patterns are only observable because LATTE externalizes emergent coordination, providing concrete ways to interpret and audit team behavior. The evolving task graph makes otherwise hidden decisions directly observable. For example, Figure 3C demonstrates how team structure and progress evolve over time. In a Leader-Worker or decentralized team, mechanisms like selective verification would be invisible or buried in the message logs rather than recorded as explicit and structured coordination decisions. 5.3 LATTE induces better coordination Beyond aggregate performance, we report finer-grained coordination metrics to address a fundamental gap in evaluating teams: overwrites, concurrent writes, communication overhead, and wasted outputs are rarely measured in prior work, yet directly capture how often agents waste resources and interfere. 7 A)LATTE Operator Usage % of runs using operator B) Task graph growth over time |V| (size of graph) Round C) Example dynamic run (GPT 5.2, exploratory data analysis) Round 0: Lead plans 3 subtasks Round 1: Workers discover 3 more subtasks Round 5: Lead inserts VERIFY node Round 11: Tests pass, lead closes 3 stale tasks Infer columns T1 T2 T3 Generate findings Write report T1 T2 T3 T4 T5 T6 Create config Run analysis Write script T1 T2 T6 T4 T5 T3 T7 T8 Verify analysis Verify findings T1 T2 T6 T4 T5 T3T7 T8 Figure 3: LLM teams successfully utilize LATTE. A) LATTE teams emergently call all graph operators across rounds, demonstrating full utilization of the coordination toolkit. B) Dynamic coordination graphs grow larger than static ones over time. This reflects richer and more fine-grained understanding of which subtasks need to be executed, offering more opportunities for Workers to be deployed. In contrast, a smaller static graph represents a fixed, underspecified coordination structure that cannot adapt to task demands. C) A representative example of how a coordination graph evolves across rounds using GPT-5.2. As agents add edges and dependencies, the graph encodes emergent assignments and progress. Because coordination is represented explicitly, team behaviors can be tracked, interpreted, and diagnosed over time, a key advantage over black-box multi-agent systems. LATTE decreases inter-agent conflicts. In collaborative tasks with a shared state, agents may overwrite completed work, simultaneously edit the same text, or redundantly duplicate effort. Each conflict carries distinct costs in wasted tokens, corrupted state, and downstream debugging. LATTE mitigates these failure modes through explicit task assignment and dependency tracking, ensuring agents operate on disjoint subtasks in a well-defined order (Fig. 4A-C). The reductions are substantial. LATTE agents overwrite each other4.3×per trial on average, versus22.8×in Leader-Worker teams (p < 0.01) and35.4×in decentralized (p < 0.01): a5.3×and8.2×reduction respectively. Concurrent writes to the same function follow the same pattern:1.0×per trial versus8.5×in Leader-Worker (p < 0.01) and11.5×in decentralized (p < 0.01). These conflicts compound into wasted output. LATTE produces 5,236 discarded characters per trial on average, compared to 45,436 in Leader–Worker (p < 0.01) and 78,062 in decentralized (p < 0.01), corresponding to more than 40,000 and 70,000 extra characters of output that never appear in the final product. LATTE reduces costly communication. Communication overhead is also a meaningful cost in LLM teams. Agents tend to send excessive messages, consuming unnecessary tokens, introducing latency, and interrupting teammates with irrelevant information [35,59,8]. LATTE constrains this by making communication purposeful (Fig. 4D). Workers message the Lead only when blocked, needing clarification, or signaling dependencies for another agent. This structure produces measurably less communication. LATTE agents send20.4inter-agent messages per task, compared to31.4in Leader–Worker teams (p = 0.04) and34.8in decentralized teams (p < 0.01). LATTE agents also exchange leaner messages, with42,484characters sent versus50,073in Leader-Worker teams (p < 0.01) and60,394in decentralized teams (p < 0.01). These results show that LATTE reduces unnecessary communication and limits context accumulation per agent. LATTE selectively activates agents, reducing idle computation. LATTE restricts participation toF t , activating agents only when pending work exists. On average, agents are active for only 48.7%of rounds while maintaining high task performance (Fig. 4E). By contrast, decentralized teams activate all agents every round regardless of demand, inflating computation and communication costs. Leader-Worker teams fall in between, deploying agents for 80% of rounds. 8 A) Overwrites B) Concurrent writesC) Wasted output D) Communication overhead E) Inactivity Cross-agent overwrites Concurrent collisions Wasted characters Number of messages Message characters Proportion of rounds with - out agent deployed LATTELeader- Worker Dec.StaticLATTELeader- Worker Dec.StaticLATTELeader- Worker Dec.Static LATTELeader- Worker Dec.StaticLATTELeader- Worker Dec.Static LATTELeader- Worker Dec.Static Figure 4: LATTE improves coordination. (A) Overwrites: agents overwriting a prior agent’s work in a later round. (B) Concurrent writes: two agents simultaneously writing to the same function. (C) Wasted output: characters written that do not appear in the final output. (D) Communication overhead: number and volume of messages exchanged. (E) Inactivity: proportion of rounds with an agent suppressed. LATTE reduces A–D and increases E. LATTE mitigates stragglers. Finally, a key challenge in static systems are stragglers: agents that take disproportionately long to complete assigned tasks [11,35]. LATTE addresses this by monitoring node execution time and sending a heartbeat to the Lead when a threshold is exceeded, giving the Lead the option to RELEASE and reassign the task, or Workers the option to self-claim it. RELEASE is invoked in36%of runs, confirming that straggler mitigation emerges in practice. The impact on completion time is substantial. LATTE teams complete assigned nodes in 39.2s on average versus 75.6s for static teams (p < 0.01), and this gap widens at the tail: at the 95th percentile, 130s versus 294s for static teams (a2.3×reduction), showing this mechanism effectively prevents stragglers from blocking task completion. 6 Conclusion Inspired by task graphs and scheduling protocols in distributed systems, LATTE enables LLM teams to dynamically explore and solve problems while maintaining consistency and efficiency. Across settings, LATTE exhibits consistent gains in token and time efficiency, conflict resolution, and coordination quality while preserving the flexibility for agents to explore and refine solutions as tasks evolve. More broadly, LATTE challenges a core assumption in prior frameworks that coordination structure must be imposed by the system architect. Instead, allowing agents to maintain and revise their own coordination structure online empowers teams to adapt to evidence accumulated during execution. These results establish explicit, agent-maintained coordination as a principle for building LLM teams that are simultaneously more efficient, reliable, and adaptive. By reducing token consumption and wall-clock time, LATTE directly cuts the computational (and thereby financial) cost associated with LLM teams, conserving resources that would otherwise be spent on redundant communication and unresolved conflicts. Limitations. Several limitations point to promising directions for future work. First, LATTE introduces planning overhead from graph initialization which may outweigh its benefits on short or simple tasks where a single agent would suffice. A deeper analysis of this overhead is provided in Appendix A6.3. Second, our evaluation focuses on domains with natural subtask boundaries such as coding. The current operator set could be extended to support less structured forms of task discovery and decomposition, enabling LATTE to tackle a broader range of open-ended reasoning 9 tasks in future work. Third, we fix team size to benchmark fairly against baselines such as MetaGPT, leaving the question of how LATTE scales to future work. Fourth, LATTE teams demonstrate an emergent ability to identify where verification is needed, invoking VERIFY selectively rather than applying blanket review mechanisms to all agent outputs [23]. Understanding and strengthening these emergent verification mechanisms is a particularly promising direction, as targeted quality control may be key to reliable LLM team performance at scale. Finally, future work should explore fine-tuning or reinforcement learning on coordination outcomes, allowing teams to learn better graph constructions, task assignments, and communication protocols over time. Code Availability.An implementation of LATTE is available athttps://github.com/ emieczkowski/latte. Acknowledgments This work was supported by the National Defense Science and Engineering Graduate (NDSEG) Fellowship Program to EM, and ONR MURI N00014-24-1-2748 to DA and TG. References [1] Kunal Agrawal, Charles E Leiserson, and Jim Sukha. Executing task graphs using work-stealing. In 2010 IEEE International Symposium on Parallel & Distributed Processing (IPDPS), pages 1–12. IEEE, 2010. [2]Anthropic. How we built our multi-agent research system.https://w.anthropic.com/ engineering/multi-agent-research-system, June 2025. Anthropic Engineering Blog. [3] Frédéric Berdoz, Leonardo Rugli, and Roger Wattenhofer. Can AI agents agree? arXiv preprint arXiv:2603.01213, 2026. [4]Maciej Besta, Nils Blach, Ales Kubicek, Robert Gerstenberger, Michal Podstawski, Lukas Gianinazzi, Joanna Gajda, Tomasz Lehmann, Hubert Niewiadomski, Piotr Nyczyk, et al. Graph of thoughts: Solving elaborate problems with Large Language Models. Proceedings of the AAAI Conference on Artificial Intelligence, 38(16):17682–17690, 2024. doi: 10.1609/aaai.v38i16. 29720. [5] Aanisha Bhattacharyya, Abhilekh Borah, Yaman Kumar Singla, Rajiv Ratn Shah, Changyou Chen, and Balaji Krishnamurthy. Social agents: Collective intelligence improves LLM predic- tions. In The Fourteenth International Conference on Learning Representations, 2026. [6]Frederick P. Brooks. The Mythical Man-Month: Essays on Software Engineering. Addison- Wesley, Reading, MA, 1975. ISBN 0-201-00650-2. [7] Marcelo Cataldo, James D. Herbsleb, and Kathleen M. Carley. Socio-technical congruence: a framework for assessing the impact of technical and work dependencies on software de- velopment productivity. In Proceedings of the Second ACM-IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM), pages 2–11, Kaiserslautern, Germany, 2008. ACM. doi: 10.1145/1414004.1414008. [8] Mert Cemri, Melissa Z Pan, Shuyi Yang, Lakshya A Agrawal, Bhavya Chopra, Rishabh Tiwari, Kurt Keutzer, Aditya Parameswaran, Dan Klein, Kannan Ramchandran, et al. Why do multi- agent LLM systems fail? arXiv preprint arXiv:2503.13657, 2025. [9] Melvin E. Conway. How do committees invent? Datamation, 14(4):28–31, April 1968. [10] Jeffrey Dean and Luiz André Barroso. The tail at scale. Communications of the ACM, 56(2): 74–80, 2013. doi: 10.1145/2408776.2408794. [11]Jeffrey Dean and Sanjay Ghemawat. MapReduce: Simplified data processing on large clusters. Communications of the ACM, 51(1):107–113, January 2008. doi: 10.1145/1327452.1327492. [12]Thomas G Dietterich. Hierarchical reinforcement learning with the MAXQ value function decomposition. Journal of Artificial Intelligence Research, 13:227–303, 2000. 10 [13]Qingxiu Dong, Lei Li, Damai Dai, Ce Zheng, Jingyuan Ma, Rui Li, Heming Xia, Jingjing Xu, Zhiyong Wu, Baobao Chang, et al. A survey on in-context learning. In Proceedings of the 2024 conference on empirical methods in natural language processing, pages 1107–1128, 2024. [14]Yilun Du, Shuang Li, Antonio Torralba, Joshua B Tenenbaum, and Igor Mordatch. Improv- ing factuality and reasoning in language models through multiagent debate. In Forty-first International Conference on Machine Learning, 2024. [15]Gleiph Ghiotto, Leonardo Murta, Márcio Barros, and André van der Hoek. On the nature of merge conflicts: A study of 2,731 open source Java projects hosted by GitHub. IEEE Transactions on Software Engineering, 46(8):892–915, 2020. doi: 10.1109/TSE.2018.2871083. [16]Nakul Gopalan, Michael Littman, James MacGlashan, Shawn Squire, Stefanie Tellex, John Winder, and Lawson Wong. Planning with abstract Markov decision processes. In Proceedings of the International Conference on Automated Planning and Scheduling, volume 27, pages 480–488, 2017. [17]Thomas L Griffiths, Frederick Callaway, Michael B Chang, Erin Grant, Paul M Krueger, and Falk Lieder. Doing more with less: Meta-reasoning and meta-learning in humans and machines. Current Opinion in Behavioral Sciences, 29:24–30, 2019. [18]W. K. Hastings. Monte Carlo sampling methods using Markov chains and their applications. Biometrika, 57(1):97–109, 1970. doi: 10.1093/biomet/57.1.97. [19]Nicholas Hay, Stuart Russell, David Tolpin, and Solomon Eyal Shimony. Selecting computa- tions: Theory and applications. In Proceedings of the Twenty-Eighth Conference on Uncertainty in Artificial Intelligence, pages 346–355, 2012. [20]Joseph Henrich. The Secret of Our Success: How Culture is Driving Human Evolution, Domesticating Our Species, and Making Us Smarter. Princeton University Press, Princeton, NJ, 2015. ISBN 9780691166858. [21]James D. Herbsleb and Audris Mockus. An empirical study of speed and communication in globally distributed software development. IEEE Transactions on Software Engineering, 29(6): 481–494, 2003. doi: 10.1109/TSE.2003.1205177. [22]Sirui Hong, Mingchen Zhuge, Jonathan Chen, Xiawu Zheng, Yuheng Cheng, Jinlin Wang, Ceyao Zhang, Zili Wang, Steven Ka Shing Yau, Zijuan Lin, et al. MetaGPT: Meta programming for a multi-agent collaborative framework. In The Twelfth International Conference on Learning Representations, 2023. [23]Jen-tse Huang, Jiaxu Zhou, Tailin Jin, Xuhui Zhou, Zixi Chen, Wenxuan Wang, Youliang Yuan, Michael R Lyu, and Maarten Sap. On the resilience of LLM-based multi-agent collaboration with faulty agents. arXiv preprint arXiv:2408.00989, 2024. [24] Yongrae Jo and Chanik Park. Byzantine-robust decentralized coordination of LLM agents. arXiv preprint arXiv:2507.14928, 2025. [25] Theodore Johnson. A concurrent dynamic task graph. In 1993 International Conference on Parallel Processing-ICPP’93, volume 2, pages 223–230. IEEE, 1993. [26]Yubin Kim, Ken Gu, Chanwoo Park, Chunjong Park, Samuel Schmidgall, A Ali Heydari, Yao Yan, Zhihan Zhang, Yuchen Zhuang, Mark Malhotra, et al. Towards a science of scaling agent systems. arXiv preprint arXiv:2512.08296, 2025. [27] Samuel T Langlois, Oghenetekevwe Akoroda, Estefany Carrillo, Jeffrey W Herrmann, Shapour Azarm, Huan Xu, and Michael Otte. Metareasoning structures, problems, and modes for multiagent systems: A survey. IEEE Access, 8:183080–183089, 2020. [28]Ao Li, Yuexiang Xie, Songze Li, Fugee Tsung, Bolin Ding, and Yaliang Li. Agent-oriented planning in multi-agent systems. In The Thirteenth International Conference on Learning Representations, 2025. 11 [29]Junyou Li, Qin Zhang, Yangbin Yu, Qiang Fu, and Deheng Ye. More agents is all you need. arXiv preprint arXiv:2402.05120, 2024. [30]Nelson F Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, and Percy Liang. Lost in the middle: How language models use long contexts. Transactions of the Association for Computational Linguistics, 12:157–173, 2024. [31]Shuo Liu, Tianle Chen, Ryan Amiri, and Christopher Amato. Learning decentralized LLM collaboration with multi-agent actor critic. arXiv preprint arXiv:2601.21972, 2026. [32]Alan MacCormack, Carliss Baldwin, and John Rusnak. Exploring the duality between product and organizational architectures: A test of the “mirroring” hypothesis. Research Policy, 41(8): 1309–1324, 2012. doi: 10.1016/j.respol.2012.04.011. [33]Grzegorz Malewicz, Matthew H. Austern, Aart J. C. Bik, James C. Dehnert, Ilan Horn, Naty Leiser, and Grzegorz Czajkowski. Pregel: A system for large-scale graph processing. In Proceedings of the 2010 ACM SIGMOD International Conference on Management of Data (SIGMOD ’10), pages 135–146, Indianapolis, Indiana, USA, 2010. Association for Computing Machinery. doi: 10.1145/1807167.1807184. [34] Hongzi Mao, Malte Schwarzkopf, Shaileshh Bojja Venkatakrishnan, Zili Meng, and Mohammad Alizadeh. Learning scheduling algorithms for data processing clusters. In Proceedings of the ACM Special Interest Group on Data Communication (SIGCOMM), pages 270–288. ACM, 2019. doi: 10.1145/3341302.3342080. [35]Elizabeth Mieczkowski, Katherine M Collins, Ilia Sucholutsky, Natalia Vélez, and Thomas L Griffiths. Language model teams as distributed systems. arXiv preprint arXiv:2603.12229, 2026. [36]Philipp Moritz, Robert Nishihara, Stephanie Wang, Alexey Tumanov, Richard Liaw, Eric Liang, Melih Elibol, Zongheng Yang, William Paul, Michael I Jordan, and Ion Stoica. Ray: A distributed framework for emerging AI applications. In 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18), pages 561–577. USENIX Association, 2018. [37]Aneesh Pappu, Batu El, Hancheng Cao, Carmelo di Nolfo, Yanchao Sun, Meng Cao, and James Zou. Multi-agent teams hold experts back. arXiv preprint arXiv:2602.01011, 2026. [38] Joon Sung Park, Joseph C O’Brien, Carrie J Cai, Meredith Ringel Morris, Percy Liang, and Michael S Bernstein. Generative agents: Interactive simulacra of human behavior. In Proceed- ings of the 36th Annual ACM Symposium on User Interface Software and Technology, 2023. doi: 10.1145/3586183.3606763. [39]Constantine D. Polychronopoulos and David J. Kuck. Guided self-scheduling: A practical scheduling scheme for parallel supercomputers. IEEE Transactions on Computers, C-36(12): 1425–1439, December 1987. doi: 10.1109/TC.1987.5009495. [40]Chen Qian, Wei Liu, Hongzhang Liu, Nuo Chen, Yufan Dang, Jiahao Li, Cheng Yang, Weize Chen, Yusheng Su, Xin Cong, et al. Chatdev: Communicative agents for software development. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics, pages 15174–15186, 2024. [41]Anita Raja and Victor Lesser. A framework for meta-level control in multi-agent systems. Autonomous Agents and Multi-Agent Systems, 15(2):147–196, 2007. [42] Christoph Riedl. Emergent coordination in multi-agent language models. arXiv preprint arXiv:2510.05174, 2025. [43] Michael Rizvi-Martel, Satwik Bhattamishra, Neil Rathi, Guillaume Rabusseau, and Michael Hahn. Benefits and limitations of communication in multi-agent reasoning. arXiv preprint arXiv:2510.13903, 2025. [44] Stuart Russell and Eric Wefald. Principles of metareasoning. Artificial Intelligence, 49(1-3): 361–395, 1991. 12 [45]H. Sackman, W. J. Erikson, and E. E. Grant. Exploratory experimental studies comparing online and offline programming performance. Communications of the ACM, 11(1):3–11, 1968. doi: 10.1145/362851.362858. [46]Natalie Shapira, Chris Wendler, Avery Yen, Gabriele Sarti, Koyena Pal, Olivia Floody, Adam Belfki, Alex Loftus, Aditya Ratan Jannali, Nikhil Prakash, et al. Agents of chaos. arXiv preprint arXiv:2602.20021, 2026. [47]Yongliang Shen, Kaitao Song, Xu Tan, Dongsheng Li, Weiming Lu, and Yueting Zhuang. HuggingGPT: Solving AI tasks with ChatGPT and its friends in Hugging Face. In Advances in Neural Information Processing Systems 36 (NeurIPS 2023). Curran Associates, Inc., 2023. [48]Jason Sleight and Edmund Durfee. Multiagent metareasoning through organizational design. In Proceedings of the AAAI Conference on Artificial Intelligence, volume 28, 2014. [49]Kyle Swanson, Wesley Wu, Nash L Bulaong, John E Pak, and James Zou. The virtual lab of AI agents designs new SARS-CoV-2 nanobodies. Nature, 646(8085):716–723, 2025. [50]Michael Tomasello, Malinda Carpenter, Josep Call, Tanya Behne, and Henrike Moll. Un- derstanding and sharing intentions: The origins of cultural cognition. Behavioral and Brain Sciences, 28(5):675–691, 2005. [51]Haluk Topcuoglu, Salim Hariri, and Min-You Wu. Performance-effective and low-complexity task scheduling for heterogeneous computing. IEEE Transactions on Parallel and Distributed Systems, 13(3):260–274, 2002. [52]Maarten Van Steen and Andrew S Tanenbaum. Distributed Systems. distributed-systems.net, 2023. [53]Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Fei Xia, Ed Chi, Quoc V Le, Denny Zhou, et al. Chain-of-thought prompting elicits reasoning in large language models. Advances in Neural Information Processing Systems, 35:24824–24837, 2022. [54]Laurie Williams, Robert R Kessler, Ward Cunningham, and Ron Jeffries. Strengthening the case for pair programming. IEEE Software, 17(4):19–25, 2000. [55]Sung-Ho Woo, Sung-Bong Yang, Shin-Dug Kim, and Tack-Don Han. Task scheduling in distributed computing systems with a genetic algorithm. In Proceedings High Performance Computing on the Information Superhighway. HPC Asia’97, pages 301–305. IEEE, 1997. [56]Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li, Erkang Zhu, Li Jiang, Xiaoyun Zhang, Shaokun Zhang, Jiale Liu, et al. Autogen: Enabling next-gen LLM applications via multi-agent conversations. In First Conference on Language Modeling, 2024. [57]Yingxuan Yang, Chengrui Qu, Muning Wen, Laixi Shi, Ying Wen, Weinan Zhang, Adam Wierman, and Shangding Gu. Understanding agent scaling in LLM-based multi-agent systems via diversity. arXiv preprint arXiv:2602.03794, 2026. [58]Shunyu Yao, Dian Yu, Jeffrey Zhao, Izhak Shafran, Tom Griffiths, Yuan Cao, and Karthik Narasimhan. Tree of thoughts: Deliberate problem solving with large language models. Ad- vances in Neural Information Processing Systems, 36:11809–11822, 2023. [59]Guibin Zhang, Yanwei Yue, Zhixun Li, Sukwon Yun, Guancheng Wan, Kun Wang, Dawei Cheng, Jeffrey Xu Yu, and Tianlong Chen. Cut the crap: An economical communication pipeline for LLM-based multi-agent systems. arXiv preprint arXiv:2410.02506, 2024. [60]Terry Jingchen Zhang, Wenyuan Jiang, Yongjin Yang, Sirui Lu, Bernhard Schölkopf, and Zhijing Jin. Position: Science is collaborative—LLM for science should be too. In ICLR 2026 Workshop on Foundation Models for Science: Real-World Impact, 2026. Oral. [61]Yusen Zhang, Ruoxi Sun, Yanfei Chen, Tomas Pfister, Rui Zhang, and Sercan Arik. Chain of agents: Large language models collaborating on long-context tasks. Advances in Neural Information Processing Systems, 37:132208–132237, 2024. 13 [62]Denny Zhou, Nathanael Schärli, Le Hou, Jason Wei, Nathan Scales, Xuezhi Wang, Dale Schuurmans, Claire Cui, Olivier Bousquet, Quoc V Le, and Ed H Chi. Least-to-most prompting enables complex reasoning in large language models. In The Eleventh International Conference on Learning Representations, 2023. 14 Appendix A1 Related Work15 A1.1 LLM teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 A1.2 Task graphs and coordination protocols . . . . . . . . . . . . . . . . . . . . . . .16 A2 Probabilistic Motivation16 A3 Graph Mutation Operators18 A4 LATTE Implementation18 A4.1 Team composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 A4.2 Lead prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 A4.3 Worker prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 A4.4 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 A4.5 LATTE Execution Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 A5 Baseline implementations22 A5.1 MetaGPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 A5.2 Leader-Worker Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 A5.3 Decentralized Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 A5.4 Static Graph Ablation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 A5.5 Lead prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 A5.6 Worker prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 A6 Experiments27 A6.1 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 A6.2 Trials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 A6.3 Planning Overhead Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 A1 Related Work A1.1 LLM teams LLMs are increasingly deployed in multi-agent teams. In some settings, these teams outperform indi- vidual models by improving diversity and distributing long contexts across many agents [61,29,5,14]. As a result of these emergent cooperative abilities, LLM teams have achieved desirable results in do- mains such as scientific discovery [49,60] and software engineering [22,40]. Despite these successes, coordination remains a critical challenge. As multiple agents interact and contribute to a shared task, ensuring consistent, non-redundant, and well-structured collaboration becomes exceedingly difficult. Recent work has shown that scaling the number of agents does not reliably improve performance, and can in fact degrade results depending on task structure and agent heterogeneity [26,37,57,43]. In particular, performance deteriorates in settings requiring sequential reasoning or consistent shared states like software repositories [35]. Unstructured interaction can further Lead to failures such as hallucinated responsibilities, misinformation, and adversarial behavior among agents [46]. To overcome these challenges, various frameworks aim to improve team performance with explicitly structured task assignment and interaction. One common approach is to impose role-based and hier- archical decompositions. Systems like MetaGPT assign fixed functional roles (e.g., Product Manager, 15 Engineer) to agents performing collaborative software tasks [22], while ChatDev similarly adopts a fixed hierarchy with role-conditioned specialization [40]. Frameworks such as HuggingGPT [47] similarly use an LLM controller to plan and dispatch heterogeneous expert models against a fixed task taxonomy, but do not adapt the underlying decomposition during execution. More recent approaches introduce feedback-driven re-planning, where a meta-agent iteratively updates plans [28]. In single-agent settings, reasoning and planning can be structured as chains, graphs, or trees over intermediate steps, or as decompositions into simpler subproblems whose solutions feed forward, improving compositionality and generalization beyond the prompted exemplars [53, 58, 4, 62]. A1.2 Task graphs and coordination protocols Recent work identifies parallels between LLM teams and distributed computing systems. Agents with limited local information contend for shared resources, fail without warning, retry, race, and must produce a coherent shared output; notably, this is the exact regime distributed-computing engineers have spent decades modeling [11, 33, 36]. In both settings, critical tradeoffs arise between different coordination structures [52]. First, fully centralized architectures can avoid consistency conflicts by designating one Lead to assign tasks and serialize updates, but create bottlenecks and single- points-of-failure. Fully decentralized approaches are more scalable and robust, but agents operating independently on local views of task state can produce conflicting or redundant outputs. Second, static approaches commit to a fixed task assignment up front, which simplifies global scheduling but requires complete task visibility in advance. Thus, static assignments cannot adapt when tasks fail, new dependencies emerge, or workloads shift. Alternatively, dynamic approaches assign tasks online as they become available but require mechanisms to maintain consistency as the task evolves. Task graphs are used in distributed systems (as well as in reinforcement learning and planning [12,16]) to formalize this coordination problem. Nodes represent tasks, edges encode precedence dependencies, and the objective is to schedule tasks to processors efficiently [55,51]. Classic scheduling algorithms such as HEFT operate at the centralized, static end of both axes, computing a globally optimized assignment before execution begins [51]. Dynamic variants move along the second axis by making assignments online as tasks and dependencies become known [25]. Approaches like NABBIT enable both some decentralization and dynamic allocation using a shared task pool and work-stealing, so processors can autonomously claim ready tasks without a central Leader [1]. Learning-based schedulers such as Decima further adapt policies to workload structure at runtime [34], combining dynamic assignment with learned coordination. Ray similarly operationalizes online task-graph scheduling at scale through a sharded control store and bottom-up distributed scheduler, supporting dynamic task graphs whose structure is not known in advance [36]. Yet Ray’s dynamism is in execution scheduling, not task specification: nodes are well-typed remote functions and actor methods registered in advance, and the graph evolves only as those primitives are invoked at runtime. These approaches assume well-defined tasks and explicit control mechanisms, rather than agents that can flexibly and autonomously discover and modify tasks in natural language. These same assumptions persist even when porting over the concept of task graphs to hierarchical decision- making agents [12, 16]. A2 Probabilistic Motivation To motivate the division of labor between Lead and Workers, we develop a probabilistic account of team coordination as posterior inference over task graphs. Since the Lead and Worker agents have varying degrees of visibility, the costs associated with individual steps or rounds of this posterior inference varies between agents. Whereas (approximate) Bayesian inference is commensurate with thinking, thinking while balancing the costs of inference induces a higher-level problem of thinking about how to think or meta-reasoning [44,19,17]. We motivate LATTE as encapsulating a meta-reasoning approach to efficiently deploying team-wide computational resources towards the Bayesian inference problem of identifying the best task decomposition conditioned upon all observed data [41, 48, 27]. The inference problem. LetG t denote the team’s current task decomposition at roundt, or a hypothesis about how the global task should be decomposed and assigned. We treat the space of valid DAGs as a hypothesis space, and model the team’s goal as posterior inference: to findG t that 16 maximizesP(G t | D t ), whereD t denotes all evidence accumulated in roundt(e.g., execution logs, completed outputs, messages, and environment feedback). By Bayes’ theorem we have that P(G t | D t ) = P(D t | G t )P(G t ) P(D t ) . (1) The marginal likelihoodP(D t ) = P G P(D t |G)P(G)requires summing over the space of all valid task graphs, which is combinatorially intractable. Additionally, the likelihoodP(D t |G)has no closed form, asD t is comprised of outputs in natural language or execution traces whose probabilities cannot be evaluated directly. MCMC as a tractable alternative. Markov chain Monte Carlo offers a standard approach to posterior inference that sidesteps computingP(D t ). Rather than evaluating the posterior directly, we construct a Markov chain over task graphs whose stationary distribution isP(G t |D t ). At each step, a proposal G ′ is generated and accepted with probability: A(G t → G ′ t | D t ) = min 1, P(D t | G ′ t )P(G ′ t )Q(G t | G ′ t ,D t ) P(D t | G t )P(G t )Q(G ′ t | G t ,D t ) (2) whereQ(G ′ t | G t ,D t )is the proposal distribution. BecauseP(D t )appears in both numerator and denominator, it cancels exactly, making evaluation of the acceptance ratio feasible without computing the marginal likelihood. Leader-Worker decomposition as meta-reasoning. The remaining challenge is constructing a proposal distributionQthat is both tractable and expressive. Observe that one approach would be to take the Leadℓ, who has full visibility over the past interactions of all Worker agentsD t , and charge them with identifying a new proposalG ′ t ; without regard for the costs of inference, this approach might seem promising. However, this strategy places the onus upon a single agent (in this work, a single LLM) to process a considerable volume of information stored in the full historyD t before proceeding to reason over an exponentially large hypothesis space, both of which degrade LLM response reliability [30]. Rather than placing all the burdens of inference upon the Lead’s shoulders, an alternative and more cost-effective approach would be to empower the individual Worker agentsw i . In particular, one could obtain a new task decompositionG ′ t,i from each Workerw i . From there, one quick option for obtaining a new task decomposition is via simple merging of all Workers’ proposals: G ′ t = merge(G ′ t,1 ,G ′ t,2 ,...) . Alternatively, each new proposal could be treated as a point estimate in a particle filter and one could simply be chosen uniformly at random. Notably, this type of approach sits at the opposite extreme of the previous Leader-centric approach, where the costs of inference are reduced down to processing the individual local histories of each Workerd (i) t ⊂ D t . Unfortunately, as each one lacks global visibility, no one Worker agent is well poised to understand whether or not their proposals actually enhance global task performance for the entire team. While the preceding approaches either maximize or sacrifice inference quality and considerably increased or reduced cost, LATTE can obtain a more-efficient solution to the meta-reasoning problem and better balance the quality-cost trade-offs of inference by exploiting the structure ofG t . Specifi- cally, we will assign each Workerw i to a local subtaskg (i) t ⊂ G t and accumulates a local execution trace d (i) t ⊂ D t . Worker w i proposes a local update by sampling: g (i)′ t ∼ Q(·| g (i) t , d (i) t ) (3) Confining the proposal tog (i) t keeps each Worker’s task tractable sincew i attends to its local trace d (i) t rather than the full historyD t . The candidate global decomposition for roundtis then the union of local updates across all Workers G ′ t = S i g (i)′ t . The Leadℓmaintains global visibility ofG t and evaluates the acceptance ratio, either commiting G t+1 = G ′ t or retainingG t+1 = G t . Thus, Workers have sufficient local information to propose structural changes within their own scope, while the Lead has the global view needed to evaluate 17 whether a proposal improves the overall decomposition. Critically, this mirrors the Metropolis- Hastings acceptance step [18], where the evaluator need only approximate the ratio of unnormalized likelihoodsP(D t | G ′ t )P(G ′ t )/P(D t | G t )P(G t )(e.g. a comparison between two specific graphs) rather than integrating over the full hypothesis space; crucially, however, we do not claim that LATTE agents necessarily compute this ratio explicitly. Moreover, LATTE incurs a marginal increase in cost — for the Lead to assess the benefits of a proposed local update — beyond the purely local Worker update approach outlined above while capitalizing on the global visibility of the Lead to maintain high-quality inference. Overall, this framing provides a normative account of why the division of labor in LATTE is well-founded and what behaviors the associated LLMs are approximating. We formalize this division of labor as a set of graph mutation operators in the next section. A3 Graph Mutation Operators We define seven operators that mutate the task graph; each is invoked by the Leadℓ, a Workerw, or both. F t denotes the set of nodes whose dependencies are fully satisfied at time t. DISCOVER(v, deps) (ℓ,w) Requires v /∈ V t , deps⊆ V t , and that adding v preserves acyclicity. Adds v to V t , inserts edges from each dependency to v in E t , and initializes λ t (v)← (⊥, pending). ASSIGN(v,w) (ℓ) Requires status(v) = pending and w ∈W . Sets λ t (v)← (w, assigned). CLAIM(v) (w) Requires v ∈ F t and agent(v)∈⊥,w. Sets λ t (v)← (w, in_progress). COMPLETE(v) (w) Requires status(v) = in_progress and agent(v) = w. Sets λ t (v)← (w, done). RELEASE(v) (ℓ) Requires status(v)∈assigned, in_progress. Resets λ t (v)← (⊥, pending). CLOSE(v) (ℓ) Requires status(v)∈assigned, in_progress. Sets λ t (v)← (agent(v), done) without requiring the Worker to signal completion. VERIFY(v) (ℓ) Requires status(v) = done and v ver /∈ V t . Adds a verification node v ver to V t , inserts the edge (v,v ver ) into E t , and initializes λ t (v ver )← (⊥, pending). A4 LATTE Implementation A4.1 Team composition Each run consists of one Lead (Lead) andNWorker agents (named Dev1 through DevN;N = 4in all experiments). All agents run the same underlying model with the same sampling parameters. Lead agent. The Lead runs an isolated planning phase before execution begins. Given the natural- language task description, it has up to 5 turns to produce the initial task graph (nodes + dependency edges) via <discover_task> actions. During execution the Lead monitors progress, issues <as- sign_task> and <release_task> directives, and can mutate the graph (add nodes, close stale ones). Its context window is capped at the last 10 messages. Worker agents. Workers receive task assignments from the Lead and implement them. They can emit <claim_task>, <complete_task>, and <discover_task> to propose adding new subtasks to the graph. Their context window is capped at the last 20 messages. Concurrency. All agents run concurrently within a round — the orchestrator steps the Lead first, then dispatches Workers in parallel, collecting their responses before advancing to the next round. A4.2 Lead prompt You are a senior software engineer leading a team of developers working collaboratively on coding tasks. 18 Responsibilities: 1. Understand the overall project goals and requirements 2. Break down work and strategically assign tasks to team members 3. Monitor progress and coordinate the team 4. Help unblock teammates when they face issues 5. Review work for quality and consistency 6. Synthesize results and ensure successful project completion Work efficiently and delegate appropriately. Trust your teammates to handle their assignments, but provide guidance when needed. Keep communication clear and actionable. Parallelism: Teammates can self-assign from the ready queue — they do not need to wait for you. Your job is to keep the graph correct and handle failures, not to manually dispatch every task. That said, proactively assign tasks when you know a specific agent is the right fit (e.g. after unblocking a straggler, after a verification completes). When several tasks are ready, assign them all at once, one per available agent. However, be deliberate about what runs in parallel. Avoid assigning two agents to tasks that write to the same function simultaneously. A good rule: tasks that work on distinct functions or files can run in parallel; tasks that both modify the same shared data should be sequenced. When possible, build a wide graph, not a deep one. Only use ‘dependencies’ to express real implementation ordering (i.e. “I can’t start B until A’s output exists”). Don’t chain tasks sequentially just for safety — if two tasks touch different functions or files, they can run in parallel with no ‘dependencies‘ between them. With this structure, the moment task-analyze completes, all three implementation tasks become ready in parallel. Available Actions: Do NOT edit files yourself — focus on directing your team and verifying their work. 1. Assign a task to a teammate: <assign_task id="task-1" to="AgentName" /> 2. Broadcast a message to all teammates (use this to coordinate work): <broadcast>Your message here</broadcast> 3. Run a Python script and see its output: <run_script path="script.py" /> 4. Request status from agents: <request_status /> 5. Run tests: <run_tests /> 6. Graph updates. The task graph is a living document. Use <discover_task> to add new tasks whenever: (a) A teammate reports that tests are still failing after completing their task, (b) you notice a dependency was missed or a prior task produced incorrect output, (c) the project needs a verification or integration pass that wasn’t planned upfront. Example: if Dev2 finishes implementing a function but broadcasts that tests are still red, add a fix task immediately rather than waiting: 19 <discover_task id="fix-index" title="Fix index() API bug" dependencies="task-2"> Run <run_tests /> to see failures, fix search_lib.py, confirm all tests pass. </discover_task> The index function was implemented with dict input but the tests pass a list. 7. If a task is high-stakes — it is upstream of many other tasks, or its output is hard to validate later — you can request a verification pass by a second agent: <verify_task id="task-X" /> This inserts a lightweight review task into the graph that must complete before downstream tasks proceed. The verifying agent will check correctness and fix any issues. 8.Straggler mitigation. If a teammate has been assigned a task for several rounds without completing it, they may be stuck. Use this action to release the task back to pending so it can be reassigned: <release_task id="task-X" /> This clears the current owner and resets the task to pending. Then reassign it with <assign_task id="task-X" to="DevY" /> either to a different agent or the same one with clearer instructions. Broadcast a message explaining what the agent should do differently before reassigning. 9.If the test suite is passing but tasks are still marked "assigned" or "in_progress" (e.g. a teammate completed the work but forgot to emit <complete_task>), you can close them directly: <close_task id="task-X" /> Only use this after confirming with <run_tests /> that tests pass. This is the right action when: all tests are green, a task’s work is clearly done in the codebase, and the owning agent is no longer making progress on it. A4.3 Worker prompt You are a skilled software engineer working as part of a development team. Responsibilities: 1. Work on tasks assigned to you by the Lead. 2. Write clean, well-documented code. 3. To read an existing file’s contents directly, use: <read_file path="math_utils.py" /> This returns the file contents immediately — no script needed. Always prefer this over writing a helper script to print a file. To execute a script and see its output, use: <run_script path="script.py" /> This runs the file and returns stdout/stderr to you. Use this to verify your code works before marking a task complete. 20 Important:<run_script>takes a.pyfilename only — it is not a shell. Do not pass shell commands likels,head, orpython3 script.py. To list files, write a short Python script first with<edit_file>, then run it with<run_script>. Example: <edit_file path="check_files.py"> import os; print(os.listdir(’.’)) </edit_file> <run_script path="check_files.py" /> 4. Use <run_tests /> to run the test suite and check your work. Important: Do not mark a task complete if<run_tests />is still failing. If you finish your implementation and tests are still red, use<discover_task>to add a follow-up fix task rather than marking done and moving on. This keeps the problem visible to the whole team. 5. Communicate with the team Lead when blocked or in need of clarification. 6. Complete tasks thoroughly before moving to the next one. Be proactive, collaborative, and detail-oriented. Focus on producing high-quality work. Discovering New Tasks Use<discover_task>whenever you uncover work that isn’t already in the task list. When possible, build a wide graph, not a deep one. Only usedependenciesto express real implementation ordering (i.e., “I cannot start B until A’s output exists”). <discover_task id="new-task-id" title="Short title" dependencies="only-if-truly-required"> Clear description of what needs to be done and why. </discover_task> A4.4 Parameters Sampling. All agents use a temperature of0.7and a maximum output length of4,096tokens per call. Round limits. LATTE teams (and baseline teams) were given40rounds total to complete each task. They could complete tasks more quickly by marking tasks as complete (either through the Lead or Workers in a decentralized team). Success was then evaluated based on if their implementations passed the given task’s test suite. Heartbeat monitoring. We setH = 4for all experiments with LATTE. If a Worker was stuck on their subtask implementation for more than 4 rounds without emitting any action, the Lead was notified and prompted to intervene. Claim tie-breaking. Worker agents were allowed to self-claim tasks fromF t if idle. Concurrent claims were addressed via FIFO by processing order; when multiple Workers claim the same task in the same round, the orchestrator processes agents sequentially and the first claim processed wins, while subsequent claimants get an error message and must re-poll. API retry. Anthropic and OpenAI requests rely on their respective SDK retry logic. No per-call wall-clock timeout was set. 21 A4.5 LATTE Execution Protocol Algorithm 1 LATTE Execution Require: Task description τ , agentsA =ℓ∪W , max rounds T , heartbeat threshold H Ensure: Final task graph G T Phase 0: Planning G 0 ← ℓ.DISCOVER(τ)▷ Leader initializes coordination graph Phase 1: Execution for t = 1 to T do // 1. Heartbeat monitoring Flag to ℓ any w ∈W with no actions in H consecutive rounds // 2. Frontier identification F t ←v ∈ G t : STATUS(v) = pending, ∀u∈ DEPS(v) : STATUS(u) = done // 3. Agent dispatching Re-engage busy Workers that have received new context since last round Assign idle Workers to tasks in F t , at most one Worker per task Invoke ℓ if G t has changed, a heartbeat was flagged, or ℓ has been idle for H rounds // 4. Parallel execution All selected agents act in parallel: ℓ receives full graph G t ; Workers receive assigned task or F t Each agent emits actions⊆ DISCOVER, CLAIM, COMPLETE G t ← APPLY(G t−1 , all emitted actions) // 5. Termination check if∀v ∈ G t : STATUS(v) = done then return G t end if end for return G T A5 Baseline implementations A5.1 MetaGPT We use the original paper-release codebase of MetaGPT [22], corresponding to the version publicly available at the time of the ICLR 2024 submission (commit tagv0.1, authored April–August 2023) because it faithfully instantiates the fixed Standard Operating Procedure (SOP) described in the paper. Pipeline. MetaGPT structures collaboration as a fixed, sequential SOP over five role-conditioned agents: 1. ProductManager (Alice) translates the task description into a Product Requirements Docu- ment (PRD), user stories, and a competitive analysis. 2.Architect (Bob) receives the PRD and produces a system design document, including the Python package name, file structure, and API specifications. 3. ProjectManager (Eve) reads the system design and issues a task list to the Engineer. 4. Engineer (Alex,n_borg = 1) implements the assigned files sequentially, one file per action, emitting code blocks to shared memory. 5.QaEngineer (Edward,test_round_allowed = 5) watches for Engineer output and iterates a write-test→ run-code→ debug-error loop up to the allowed round count. Agents communicate exclusively through a shared publish-subscribe message bus: each role watches a fixed set of upstream action types and acts only when a matching message arrives. The task decomposition, which files to write, what each contains, and in what order, is determined entirely during the planning phases (steps 1–3) and cannot be revised during execution. Parameters. All agents use the same model and sampling parameters as the LATTE and baseline runs described in Appendix A4. Each MetaGPT run is allocatedn_round= 40total team rounds 22 to match the other team conditions. The QaEngineer is initialized withtest_round_allowed= 5, matching the upper bound of debug-and-fix cycles in the original paper. Mismatch between SOP outputs and task evaluation. Because each role in the sequential pipeline operates on the prior role’s output rather than the shared task environment, artifacts accumulate in locations determined by the Architect’s upfront design rather than by where the task expects them. More broadly, because the task decomposition is committed before any code is executed, the Engineer cannot discover latent task structure such as which functions share internal helpers, which bugs are actually present in a given file, or which data columns carry the signal of interest. On nonstationary tasks where the correct decomposition only becomes apparent during execution, the upfront plan is systematically misspecified, and the SOP provides no mechanism to revise it. A5.2 Leader-Worker Hierarchies Leader-Worker teams were implemented using a lightweight orchestrator with no task-graph infras- tructure. Agents could edit files, run scripts, run tests, and broadcast messages to teammates. Unlike the graph-based conditions, there was no planning phase and no task state. Coordination relied entirely on the Lead broadcasting directions and teammates editing files in response. At the start of each round the orchestrator appended the latest test output to every agent’s context window. The Lead then ran first, followed by allNteammates in parallel. After each round the orchestrator ran the test suite internally to detect success. A run was marked successful when all tests passed and the Lead certified task completion. Lead promptYou are a senior software engineer leading a team of developers working collabora- tively on coding tasks. Responsibilities: 1. Understand the overall project goals and requirements 2. Break down work and strategically assign tasks to team members 3. Monitor progress and coordinate the team 4. Help unblock teammates when they face issues 5. Review work for quality and consistency 6. Synthesize results and ensure successful project completion Work efficiently and delegate appropriately. Trust your teammates to handle their assignments, but provide guidance when needed. Keep communication clear and actionable. Available Actions: Do NOT edit files yourself — focus on directing your team and verifying their work. 1. Broadcast a message to all teammates (use this to coordinate work): <broadcast>Your message here</broadcast> 2. Run a Python script and see its output: <run_script path="script.py" /> Worker prompt You are a skilled software engineer working as part of a development team. Responsibilities: 1. Work on tasks assigned to you by the Lead. 2. Write clean, well-documented code. 3. To read an existing file’s contents directly, use: 23 <read_file path="math_utils.py" /> This returns the file contents immediately — no script needed. Always prefer this over writing a helper script to print a file. To execute a script and see its output, use: <run_script path="script.py" /> This runs the file and returns stdout/stderr to you. Use this to verify your code works before marking a task complete. Important:<run_script>takes a.pyfilename only — it is not a shell. Do not pass shell commands likels,head, orpython3 script.py. To list files, write a short Python script first with<edit_file>, then run it with<run_script>. Example: <edit_file path="check_files.py"> import os; print(os.listdir(’.’)) </edit_file> <run_script path="check_files.py" /> 4. Use <run_tests /> to run the test suite and check your work. Important: Do not mark a task complete if <run_tests /> is still failing. 5. Communicate with the team lead when blocked or in need of clarification. 6. Complete tasks thoroughly before moving to the next one. Be proactive, collaborative, and detail-oriented. Focus on producing high-quality work. A5.3 Decentralized Teams Decentralized teams used the same lightweight orchestrator and action vocabulary as the Leader- Worker condition, but with no designated Leader. To hold agent count constant across conditions, we instantiatedN+1symmetric peer agents (matching the1Lead+NWorker headcount of the other conditions). All agents ran in parallel every round with no sequential ordering; coordination relied solely on broadcast messages. As in the Leader-Worker condition, the latest test output was appended to every agent’s context at the start of each round, and success was detected by running the test suite internally and any agent marking task completion. Peer prompt You are a skilled software engineer working as part of a development team. Responsibilities: 1. Work on your tasks efficiently and effectively 2. Write clean, well-documented code 3. To read an existing file’s contents directly, use: <read_file path="math_utils.py" /> This returns the file contents immediately — no script needed. Always prefer this over writing a helper script to print a file. To execute a script and see its output, use: <run_script path="script.py" /> This runs the file and returns stdout/stderr to you. Use this to verify your code works before marking a task complete. 24 Important:<run_script>takes a.pyfilename only — it is not a shell. Do not pass shell commands likels,head, orpython3 script.py. To list files, write a short Python script first with<edit_file>, then run it with<run_script>. Example: <edit_file path="check_files.py"> import os; print(os.listdir(’.’)) </edit_file> <run_script path="check_files.py" /> 4. Use <run_tests /> to run the test suite and check your work. 5. Communicate with your teammates as needed. 6. Complete tasks thoroughly before moving to the next one. Be proactive, collaborative, and detail-oriented. Focus on producing high-quality work. A5.4 Static Graph Ablation The static condition used the same graph-based orchestrator as the dynamic condition, but with task discovery and reassignment disabled after the planning phase. During planning, the Lead received a prompt instructing it to emit a complete task graph upfront, specifying every task and its dependencies before execution began. Once planning concluded, the graph was frozen: mid-run task discovery (discover_task), straggler release (release_task), verification insertion (verify_task), and automatic fix-task injection on test failure were all disabled at the orchestrator level. Teammates could not self-assign; the Lead was responsible for assigning every task at the start of execution via assign_task. AllNteammates were dispatched every round regardless of task availability. If a teammate failed to complete an assigned task, no recovery mechanism was available. A5.5 Lead prompt You are a senior software engineer leading a team of developers working collaboratively on coding tasks. Responsibilities 1. Understand the overall project goals and requirements 2. Break down work and strategically assign tasks to team members upfront 3. Monitor progress and answer questions from teammates 4. Synthesize results and ensure successful project completion Work efficiently and delegate appropriately. Trust your teammates to handle their assignments. Parallelism Teammates do not self-assign — you must assign every task. Assign all ready tasks at the start, distributing work evenly across available agents. Be deliberate about what runs in parallel. Avoid assigning two agents to tasks that write to the same function simultaneously. A good rule: tasks that work on distinct functions or files can run in parallel; tasks that both modify the same shared data should be sequenced. When possible, build a wide graph, not a deep one. Only use ‘dependencies’ to express real implementation ordering (i.e. “I can’t start B until A’s output exists”). Don’t chain tasks sequentially just for safety — if two tasks touch different functions or files, they can run in parallel with no ‘dependencies‘ between them. With this structure, the moment task-analyze completes, all three implementation tasks become ready in parallel. Available Actions Do NOT edit files yourself — focus on directing your team and verifying their work. 25 1. Assign a task to a teammate: <assign_task id="task-1" to="AgentName" /> 2. Broadcast a message to all teammates (use this to coordinate work): <broadcast>Your message here</broadcast> 3. Run a Python script and see its output: <run_script path="script.py" /> 4. Request status from agents: <request_status /> 5. Run tests: <run_tests /> 6. Fixed plan. The task decomposition and assignments are fixed at the start. Once tasks are assigned, they run to completion without reassignment or modification. Your job is to: (a) Assign all tasks upfront based on the task graph and agent availability. (b) Answer teammates’ questions via broadcast if they get stuck. (c) Run tests at the end to confirm completion. You cannot release tasks, reassign workers, or insert new tasks once execution has begun. If a teammate fails to complete a task, the team absorbs that outcome — do not attempt to recover by reassigning. A5.6 Worker prompt You are a skilled software engineer working as part of a development team. Responsibilities 1. Work on tasks assigned to you by the Lead. 2. Write clean, well-documented code. 3. To read an existing file’s contents directly, use: <read_file path="math_utils.py" /> This returns the file contents immediately — no script needed. Always prefer this over writing a helper script to print a file. To execute a script and see its output, use: <run_script path="script.py" /> This runs the file and returns stdout/stderr to you. Use this to verify your code works before marking a task complete. Important:<run_script>takes a.pyfilename only — it is not a shell. Do not pass shell commands likels,head, orpython3 script.py. To list files, write a short Python script first with<edit_file>, then run it with<run_script>. Example: <edit_file path="check_files.py"> import os; print(os.listdir(’.’)) </edit_file> <run_script path="check_files.py" /> 26 4. Use <run_tests /> to run the test suite and check your work. Important: Do not mark a task complete if<run_tests />is still failing. If you finish your implementation and tests are still red, use<discover_task>to add a follow-up fix task rather than marking done and moving on. This keeps the problem visible to the whole team. 5. Communicate with the team lead when blocked or in need of clarification. 6. Complete tasks thoroughly before moving to the next one. Be proactive, collaborative, and detail-oriented. Focus on producing high-quality work. A6 Experiments A6.1 Setup Task 1: Exploratory data analysis Identifying meaningful patterns in a dataset is inherently time- consuming and open-ended. The process begins with preprocessing and filtering, which can be handled by a single agent. Subsequently, multiple agents can explore the data in parallel along diverse directions (e.g., characterizing distributions, identifying outliers, generating visualizations). A final agent can then aggregate and synthesizes these findings. Importantly, purely static task decompositions are likely to be suboptimal because the underlying structure of the data and promising directions only emerge during analysis. We first simulated a tabular HR dataset containing 400 employee records with eight deliberately opaque column names and no data dictionary. Three ground-truth properties were planted in the data: (1) employee satisfaction score is the dominant churn predictor, (2) salary follows a bimodal distribution reflecting two workforce tiers, and (3) churn rate varies substantially by department. Agents were tasked with producing three interdependent artifacts: aconfig.pyestablishing the shared column-name mapping and feature schema (the foundation all downstream scripts must import), a structuredfindings.jsonwith quantitative supporting evidence across five analytic categories (distributions, relationships, subgroup effects, outliers, and missing data), and a written summary.txtnarrative of at least 100 words. Correctness is evaluated by a private test suite that checks whether the true churn column was identified, whether the column–feature classification matches the data types, and whether each of the three planted properties appears in the findings with correct directional claims. Task 2: Debugging Debugging is another task which is inherently nonstationary; agents must run tests, read outputs, change the code to solve potentially multiple errors, and repeat the process until the problems are solved. It also rewards both parallelism and consistency, since multiple agents can simultaneously diagnose independent errors, yet some errors require changes to composite functions that can only be verified after dependencies are fixed. In Task 2, we planted 8 bugs (1 per function) in a Python signal-processing library covering a range of common numerical mistakes, such as a+1 in the normalization denominator or inequality errors. Unlike Task 1, in which performance was evaluated after the agents marked task completion, the team had access to the full test suite. Success required all tests in the public test suite to pass. Task 3: Library extension Finally, code generation is a task that is inherently time consuming; teams of agents can improve performance by working in parallel to generate independent parts of a codebase. In this task, agents were given a partially implemented Python text-processing library with three working files: aDocumentclass,Tokenizerclass, andutilsmodule. They must extend the existing classes and build six new modules from stub files:sentiment.py,keywords.py, summarizer.py,similarity.py,formatter.py, andpipeline.py. Each stage of generation required different numbers of agents: two existing classes must be extended first, which only required two agents to change; then, the new modules could be generated independently in parallel, and finally only one agent needed to integrate everything into the final pipeline. Agents were encouraged to write their own tests, and correctness was determined after they mark test completion by a private test suite which tests common outputs and edge cases. 27 A6.2 Trials For each base model, we ran a total of 150 trials (3 tasks, 5 team structures, 10 repetitions). For Claude Sonnet 4-6, this amounted to 2,136 API cells, 40.7M input tokens, and 8.5M output tokens (approximately $250). For GPT 5.2, this amounted to 4,582 API calls, 83.1M input tokens, 14M output tokens (approximately $260). A6.3 Planning Overhead Analysis LATTE’s adaptivity introduces two components of orchestration cost. First, an initial planning phase in which the Lead seeds the task graph: dynamic conditions seed a mean of 3.8 (±2.0) nodes in 14.5s, compared to 8.3 (±1.8) in 16.7s for static, which front-loads the full decomposition. Second, in-execution orchestration: the Lead remains active in, on average, 30.8% of of execution rounds under dynamic versus 14.8% for static, adding a mean of 0.9 extra lead-active rounds per run. While these are real costs, they do not outweigh the benefits that LATTE provides to teams for dynamic and complex tasks. Across all tasks and models, dynamic conditions complete in a mean of 9.8 rounds and 148K tokens, compared to 15.9 rounds and 297K tokens for static. Thus, each extra lead-active round of dynamic overhead yields approximately six fewer total rounds of Worker execution. 28