Paper deep dive
Decoupled Intelligence: A Multi-Agent LLM Framework for Controllable Traffic Scenario Generation in SUMO
Shuyang Li, Ruimin Ke
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 94%
Last extracted: 7/8/2026, 9:25:19 PM
Summary
The paper introduces Decoupled Intelligence, a multi-agent LLM framework that automates and optimizes microscopic traffic simulation in SUMO. It replaces monolithic agent architectures with a specialized Planner-Worker system coordinated by a state-persistent Orchestrator using the Model Context Protocol (MCP). The framework decomposes simulation tasks into dedicated roles to reduce reasoning drift and ensure artifact consistency. Closed-loop feedback enables autonomous KPI-driven refinement, significantly improving task success rates, token efficiency, and time-to-insight over monolithic baselines.
Entities (13)
Relation Signals (11)
Orchestrator â leverages â Model Context Protocol
confidence 97% ¡ Central to this architecture is a state-persistent Orchestrator built upon the Model Context Protocol (MCP), which provides a standardized interface for tool invocation and maintains Artifact consistency
Decoupled Intelligence Framework â coordinates â Planner Agent
confidence 96% ¡ Our approach decouples the simulation pipeline into specialized roles, including Planner, Builder, Demand, Runner, and Analyst, coordinated by a high-level reasoning engine.
Decoupled Intelligence Framework â outperforms â Monolithic Baseline
confidence 96% ¡ Experimental results through role ablation studies demonstrate that the proposed multi-agent framework significantly enhances task success rates and parameter accuracy compared to single-agent baselines.
Decoupled Intelligence Framework â coordinates â Simulation Runner
confidence 95% ¡ Our approach decouples the simulation pipeline into specialized roles, including Planner, Builder, Demand, Runner, and Analyst, coordinated by a high-level reasoning engine.
Decoupled Intelligence Framework â coordinates â KPI Analyst
confidence 95% ¡ Our approach decouples the simulation pipeline into specialized roles, including Planner, Builder, Demand, Runner, and Analyst, coordinated by a high-level reasoning engine.
Decoupled Intelligence Framework â coordinates â Builder Agent
confidence 95% ¡ Our approach decouples the simulation pipeline into specialized roles, including Planner, Builder, Demand, Runner, and Analyst, coordinated by a high-level reasoning engine.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:The integration of Large Language Models (LLMs) with microscopic traffic simulation offers a promising path toward autonomous urban planning and intelligent transportation analysis. However, existing monolithic agent architectures often struggle with the complexity of end-to-end simulation workflows, leading to reasoning failures, parameter inconsistency, and a lack of systematic state management. This paper proposes a novel multi-agent collaborative framework designed to automate the entire lifecycle of traffic simulation in SUMO (Simulation of Urban Mobility). Our approach decouples the simulation pipeline into specialized roles, including Planner, Builder, Demand, Runner, and Analyst, coordinated by a high-level reasoning engine. We introduce a state-persistent Orchestrator leveraging the Model Context Protocol (MCP) to ensure seamless data handover and environmental consistency across distributed agent actions. This architecture enables a robust closed-loop refinement process, where simulation outcomes are iteratively analyzed and optimized to satisfy user-defined Key Performance Indicators (KPIs). Experimental results through role ablation studies demonstrate that the proposed multi-agent framework significantly enhances task success rates and parameter accuracy compared to single-agent baselines. Furthermore, case studies on real-world network extraction and traffic optimization highlight the system's capability to bridge the gap between high-level natural language intent and low-level simulation execution.
Tags
Links
- Source: https://arxiv.org/abs/2605.27685v1
- Canonical: https://arxiv.org/abs/2605.27685v1
Trouble viewing inline? Open PDF directly â
Full Text
41,618 characters extracted from source content.
Expand or collapse full text
Decoupled Intelligence: A Multi-Agent LLM Framework for Controllable Traffic Scenario Generation in SUMO Shuyang Li 1 , Ruimin Ke 1â Abstractâ The integration of Large Language Models (LLMs) with microscopic traffic simulation offers a promis- ing path toward autonomous urban planning and intelligent transportation analysis. However, existing monolithic agent architectures often struggle with the complexity of end-to-end simulation workflows, leading to reasoning failures, parameter inconsistency, and a lack of systematic state management. This paper proposes a novel multi-agent collaborative framework designed to automate the entire lifecycle of traffic simulation in SUMO (Simulation of Urban Mobility). Our approach de- couples the simulation pipeline into specialized rolesâincluding Planner, Builder, Demand, Runner, and Analystâcoordinated by a high-level reasoning engine. We introduce a state-persistent Orchestrator leveraging the Model Context Protocol (MCP) to ensure seamless data handover and environmental consistency across distributed agent actions. This architecture enables a robust closed-loop refinement process, where simulation outcomes are iteratively analyzed and optimized to satisfy user-defined Key Performance Indicators (KPIs). Experimental results through role ablation studies demonstrate that the proposed multi-agent framework significantly enhances task success rates and parameter accuracy compared to single-agent baselines. Furthermore, case studies on real-world network extraction and traffic optimization highlight the systemâs ca- pability to bridge the gap between high-level natural language intent and low-level simulation execution. I. INTRODUCTION Microscopic traffic simulation is a cornerstone of In- telligent Transportation Systems (ITS), providing a safe, cost-effective, and reproducible environment for evaluating traffic management strategies, infrastructure designs, and autonomous driving algorithms. Recent advancements have increasingly integrated machine learning and artificial in- telligence to enhance urban traffic simulation and mobility analysis [1], [2]. Moreover, cutting-edge generative world models [3] and Large Language Models (LLMs) are push- ing the boundaries of automated scenario generation and controllable traffic reasoning [4], [5], [6]. Among various simulation platforms, Simulation of Urban Mobility (SUMO) [7] has emerged as a widely adopted open-source suite due to its high fidelity and extensibility. However, the effective utilization of SUMO typically demands significant domain expertise, requiring users to navigate a fragmented and tech- nically demanding workflow. This process involves diverse tasks such as Geographic Information System (GIS) data extraction from OpenStreetMap (OSM), complex network 1 Civil and Environmental Engineering, School of Engineering, Rens- selaer Polytechnic Institute, Troy, United States. â Corresponding Author: Ruimin Ke (ker@rpi.edu) Fig. 1.Overview of the Multi-Agent Collaborative Framework. topology refinement, demand modeling through route and flow files, and the manual configuration of XML-based simulation files. For urban planners and researchers with- out deep programming or SUMO-specific experience, these âlow-levelâ barriers often hinder the rapid prototyping and iterative testing of innovative transportation concepts. To overcome these challenges, this paper proposes a novel multi-agent collaborative framework designed to decouple the complex SUMO simulation pipeline into specialized, manageable tasks. Unlike early monolithic conversational agents [8] that are prone to hallucination and reasoning drift over long contexts [9], our framework employs a âPlanner- Workerâ architecture inspired by recent successes in Multi- Agent Systems (MAS) [10], [11]. A high-level Planner agent decomposes the userâs natural language objectives into a sequential execution graph as illustrated in Fig. 1. Each node in this graph is assigned to a specialized agentâsuch as the Builder for network topology, the Demand gen- erator for traffic flow, and the Analyst for performance evaluationâensuring that each component operates within a focused context with reduced reasoning overhead. Central to this architecture is a state-persistent Orchestrator built upon the Model Context Protocol (MCP) [12], [13], which provides a standardized interface for tool invocation and maintains âArtifactâ consistency (e.g., ensuring the network file generated by the Builder is correctly passed to the De- mand agent). Furthermore, inspired by verbal reinforcement techniques [14], the framework incorporates a closed-loop feedback mechanism, allowing the Analyst to feed perfor- mance metrics back to the Planner for iterative refinement. This design enables the system not only to build a simulation arXiv:2605.27685v1 [cs.MA] 26 May 2026 from scratch but also to autonomously calibrate parameters to satisfy specific Key Performance Indicators (KPIs). To address the aforementioned limitations of monolithic LLM reasoning in long-horizon simulation tasks, this paper proposes a novel decoupled multi-agent collaborative frame- work. The main contributions of this study are summarized as follows: 1) Decoupled Multi-Agent Architecture: We introduce a Planner-Worker framework that assigns the SUMO workflow to specialized agents, improving reliability in long-horizon simulation generation. 2) State-Persistent Orchestration: We develop an MCP- based Orchestrator with explicit artifact tracking to ensure consistent file handover and reduce path hal- lucination. 3) Autonomous Closed-Loop Refinement: We incorporate execution-level repair and KPI-driven feedback to sup- port iterative simulation correction and optimization. 4) Experimental Evaluation: We conduct ablation studies showing that the proposed framework improves task success, token efficiency, and Time-to-Insight over a monolithic baseline. I. RELATED WORK A. LLMs in Traffic Simulation and ITS Microscopic traffic simulation, with platforms like SUMO acting as the industry standard [7], is indispensable for eval- uating Intelligent Transportation Systems (ITS). Recently, LLMs have shown promise in automating traffic manage- ment and simulation tasks. Works such as TrafficGPT [4] and ChatScene [15] demonstrate the potential of LLMs for traffic-scenario understanding and generation. Early conver- sational systems such as ChatSUMO [8] and the recent ChatSUMO Agent [16] further bridge natural language with SUMO-based simulation workflows through interactive and tool-mediated generation. Recent studies have also explored agentic scenario generation [6], LLM-guided controllable traffic simulation [5], and concurrent frameworks such as AgentSUMO [17], SUMO-MCP [13], and TrafficSimAgent [18]. However, many existing approaches still rely on mono- lithic or loosely structured architectures, which can suffer from reasoning drift and parameter amnesia in complex, multi-step simulation workflows. B. Multi-Agent Systems (MAS) and Task Decomposition To mitigate the cognitive overload of monolithic LLMs, the broader AI community has increasingly adopted Multi- Agent Systems (MAS), harnessing the collaborative power of intelligent agents to tackle complex reasoning tasks [11], [19]. However, recent empirical studies diagnosing MAS failures emphasize that unstructured multi-agent setups often collapse due to inter-agent misalignment, context loss, and system design flaws [9]. This highlights the critical need for methodically optimizing both individual agent prompts and overall communication topologies [20]. Therefore, structured frameworks such as MetaGPT [21], AutoGen [10], and Chat- Dev [22] have proven that decomposing complex goals into specialized roles following Standard Operating Procedures (SOPs) significantly enhances task success rates. While MAS has been extensively explored in software engineering, its application in traffic and transportation has traditionally been confined to adaptive system coordinationâsuch as multi- personality reinforcement learning for traffic control [23] or distributed vehicle routingârather than automating the simulation pipeline itself. Our work bridges this gap by proposing a strictly decoupled âPlanner-Workerâ architecture specifically tailored to mitigate failure modes in the frag- mented stages of traffic modeling. C. Tool-Use, State Management, and Closed-Loop Refine- ment The foundation of LLM interaction with external envi- ronments lies in paradigms like ReAct [24] and Toolformer [25], which synergize reasoning with API execution. Yet, a persistent challenge in long-context tool invocation is main- taining state consistency. Unlike traditional software, LLMs easily lose track of physical file paths (e.g., .net.xml) across sequential calls. Recent advancements like the Model Context Protocol (MCP) [12] provide a standardized inter- face for context management. Building upon this, our frame- work introduces a state-persistent Orchestrator to guarantee âArtifactâ consistency across decoupled agents. Furthermore, while recent methods like SMART-R1 [26] explore reinforce- ment fine-tuning for aligning simulated multi-agent behav- iors, our approach operates at the operational level. Inspired by Reflexion [14], we incorporate an Analyst agent to extract KPIs from simulation outputs, enabling verbal reinforcement and autonomous closed-loop optimization without human intervention. I. METHODOLOGY Our proposed framework transitions from a monolithic reasoning agent to a Decoupled Multi-Agent Orchestration system. This architecture ensures physical consistency and mitigates the cognitive burden on the Large Language Model (LLM) during complex, long-chain traffic simulation work- flows. A. Overall Framework We propose a structured multi-agent orchestration frame- work for traffic simulation generation that replaces mono- lithic text-to-simulation reasoning with a state-aware, contract-constrained workflow, visualized in Fig.2. The core idea is to decompose a high-level user objective into coordi- nated sub-tasks executed by specialized agents under explicit state management and dependency control. Given a natural language objective describing a desired traffic scenario, the system first performs hierarchical task decomposition. A planning module translates the high-level description into an ordered execution plan, where each step corresponds to a specific functional role (e.g., network construction, demand generation, simulation execution, or performance analysis). By isolating the global objective into localized sub-tasks, the framework reduces long-chain STRATEGIC PLANNING LAYER ORCHESTRATION & STATE PERSISTENCE LAYER SPECIALIZED WORKER LAYER PLANNER AGENT GOAL Decomposition Sequential Plan (JSON) Serialized steps & role assignments) MASTER ORCHESTRATOR Task Coordination & Exceution Monitoring Iterative Optimization Loop / KPI Feedback UNIFIED STATE & ARTIFACTS (SQLite schema) StateTableArtifactsTable DependencyTable Source of Truth (Prevents Hallucination) Context Handover Passes .net.xml & .rou.xml between steps MODEL CONTEXT PROTOCOL (MCP) BRIDGE BUILDER AGENTMODIFIER AGENTDEMAND AGENTRUNNER AGENTANALYST AGENT OSM Fetching & Map Generation Topology Change & Network Editing Route Generation & Traffic Demand Modeling SUMO Execution & Simulation Management KPI Extraction & Performance Metrics Fig. 2.Multi-Agent Orchestrator: Autonomous Traffic Simulation System Architecture reasoning errors and prevents cross-step parameter inconsis- tency. A central orchestrator maintains a persistent system state throughout the workflow. This state repository stores all gen- erated simulation artifacts, including network files, route def- initions, configuration files, and associated metadata. Rather than relying on conversational memory, each downstream agent receives validated artifact references directly from the shared state. This explicit state bridging mechanism eliminates file-path hallucinations and ensures deterministic artifact lineage across stages of the pipeline. Each role operates under a predefined inputâoutput con- tract. Generated outputs are executed through a runtime bridge connected to the SUMO simulation environment and subsequently validated for structural correctness and runtime feasibility. When execution errors occur, structured feedback is routed back to the responsible role for bounded correc- tion. This generateâexecuteâvalidate loop introduces a self- healing mechanism that significantly improves robustness compared to open-loop text-based generation approaches. The orchestration layer further enforces artifact depen- dency integrity. Downstream tasks are triggered only after prerequisite artifacts have been successfully generated and validated. For example, route generation requires a confirmed network topology, and simulation configuration depends on both network and demand artifacts. This dependency-aware design prevents cascading inconsistencies within the simula- tion workflow. Finally, simulation outputs are parsed to extract key per- formance indicators such as travel time, throughput, and congestion levels. These indicators can either be reported to the user or used to refine earlier stages of the pipeline, enabling an optional iterative improvement process. Overall, the framework establishes a modular, state- persistent, and physically grounded architecture for au- tonomous traffic simulation generation, providing improved reliability and execution consistency compared to monolithic text-to-simulation systems. B. Hierarchical Orchestration and Closed-Loop Reflexion To effectively manage the complexity of traffic modeling, our framework integrates hierarchical task decomposition with a state-persistent orchestration mechanism. Given a high-level user objective G, a top-level Planner agent first formulates the simulation process as a sequence of dependent sub-tasks. The Planner decomposes G into a structured exe- cution graph, where each step s i assigns a specialized worker agent and strictly defines the required parameter contract. By decoupling the global objective into local, role-specific prompts, we significantly reduce the âreasoning driftâ typical of monolithic models. The technical backbone driving this execution graph is an Artifact-based Orchestrator powered by the Model Context Protocol (MCP). Unlike standard single-agent architectures that rely precariously on implicit conversational memory, our Orchestrator utilizes an explicit context repository to man- age the lifecycle of simulation artifacts (e.g., .net.xml, .rou.xml, and .sumocfg). It guarantees strict data han- dover between rolesâensuring, for instance, that the De- mand Engineer operates only on the validated network topol- ogy generated by the Builder or Modifier. This physical state bridge effectively eliminates the path-referencing hallucina- tions commonly observed in long-context LLM reasoning. Furthermore, the Orchestrator serves as the central engine for our autonomous dual-loop reflexion mechanism, as for- mally described in Algorithm 1. Rather than blindly retrying failed tools, the Orchestrator monitors the execution pipeline for two types of feedback: 1) Execution Error Repair (Level 1): If a worker agent encounters a terminal error (e.g., unroutable edges or missing files), the Orchestrator catches the exception, halts the pipeline, and injects the error payload into the global context to trigger a recursive replanning phase. 2) KPI Optimization Feedback (Level 2): Upon successful simulation execution, the KPI Analyst evaluates the results. If the extracted metrics fail to satisfy the constraints of G, the Analyst generates verbalized feedback, prompting the Planner to iteratively refine traffic demands or network structures. This closed-loop orchestration ensures not only the structural integrity of the simulation but also the intelligent alignment of outputs with user-defined objectives. C. Specialized Role Definition and Collaboration Mecha- nism To mitigate the cognitive overload inherent in monolithic LLMs and ensure domain-specific precision, we decompose the SUMO simulation pipeline into five distinct, decoupled agent roles. Each agent is equipped with a tailored system prompt and restricted access to specific Model Context Protocol (MCP) toolsets, ensuring strict boundaries for task execution and state management. 1) Network Builder: The Network Builder is responsible for the foundational geographic and topological extraction. Driven by the Plannerâs initial instructions, this agent inter- faces with tools such as netconvert and OSMWebWiz- ard. It translates high-level natural language queries (e.g., âa 0.5-mile radius around Troyâ) into precise bounding boxes, fetches OpenStreetMap (OSM) data, and compiles the initial macroscopic network topology. The primary artifact generated is the .net.xml file, which is subsequently indexed by the Orchestrator to prevent path hallucination. 2) Network Modifier: To accommodate complex con- straint satisfaction tasksâsuch as lane closures, edge re- movals, or Traffic Light System (TLS) optimizationsâthe Network Modifier acts as an intermediate topological auditor. Rather than building from scratch, it retrieves the generated .net.xml from the Orchestratorâs artifact repository. By leveraging SUMOâs netedit functionalities or XML pars- ing scripts via MCP, it applies structural perturbations and overwrites the network artifact. This step explicitly precedes demand generation to prevent vehicles from being assigned to non-existent edges. Algorithm 1: Multi-Agent Orchestration with Dual- Loop Reflexion Input: User objective G, Initial Context C 0 , Max iterations M Output: Simulation KPIs K, Final Artifacts A C âC 0 ; for iter â 1 to M do P lanâ Planner(G,C) ; // Generate serialized steps Aââ ; Error â None; foreach step sâ P lan do // Execute tool via assigned agent and artifacts Resultâ Agent s.role .execute(s.goal,A); if Result.status̸= SUCCESS then Error â Result.error; break ; // Abort execution pipeline end AâA⪠Result.artifacts ; // Update state end if Error ̸= None then // Level 1: Inject execution error for next iteration C âCâŞlasterror : Error; else // Level 2: Evaluate simulation results Kâ Analyst.evaluate(A); if K satisfies constraints in G then return K,A ; // Task successfully completed end // Inject KPI verbal feedback for next iteration C âCâŞkpi feedback : Verbalize(K); end end return Failure: Max iterations reached; 3) Demand Engineer: The Demand Engineer focuses exclusively on traffic flow formulation. Operating strictly on the latest validated .net.xml artifact, this agent trans- lates user-defined traffic volumes into microscopic vehicle configurations. It dynamically selects appropriate underlying SUMO scripts, such as randomTrips.py for stochas- tic background traffic or custom routing tools for specific Origin-Destination (OD) pairs. The output is a deterministic .rou.xml file, ensuring absolute topological consistency with the physical road network. 4) Simulation Runner: Once the physical and demand artifacts are prepared, the Simulation Runner synthesizes the simulation environment. It automatically generates the .sumocfg configuration file, seamlessly linking the pre- viously created .net.xml and .rou.xml files. Further- more, this agent orchestrates the physical execution engine, deciding whether to launch the headless sumo executable for rapid batch processing or sumo-gui for visual inspection, while configuring appropriate step limits and output flags. 5) KPI Analyst: Acting as the evaluation core of the closed-loop system, the KPI Analyst parses the raw XML output files (e.g., tripinfo.xml, summary.xml) gen- erated by the Simulation Runner. It extracts and aggregates critical Key Performance Indicators (KPIs) such as mean speed, average waiting time, and CO 2 emissions. Instead of merely presenting data, the Analyst translates these metrics into natural language feedback, empowering the Planner agent to conduct iterative reasoning and parameter refinement in subsequent optimization rounds. IV. EXPERIMENTS AND RESULTS We evaluate the proposed framework against a state-of- the-art monolithic baseline across a variety of urban traffic scenarios. The experiments are designed to test two hypothe- ses: (1) multi-agent role decoupling improves task success rates in complex workflows, and (2) the artifact-based or- chestrator ensures physical consistency where single-agent systems fail. A. Experimental Setup The experiments were conducted using the SUMO (ver- sion 1.21.0) simulation suite and an LLM backbone (Qwen3- 30B-Coder). We established a Monolithic Baseline based on a standard ReAct agent, which manages all SUMO tools and the entire execution history within a single, continuous context window without hierarchical decomposition. In contrast, as illustrated in Fig.3, for our proposed multi-agent framework, we meticulously designed a set of decoupled prompts to enforce role specialization and state management. The global constraints and environment rules are governed by a unified System Prompt (see Appendix I). The high-level task decomposition and step-by-step routing are driven by the Planner Prompt (see Appendix I). Finally, the specific operational boundaries and tool permissions of each worker (e.g., Network Builder, Demand Engineer) are strictly defined by their respective Role Prompts (provided in Appendix I). We designed a benchmark consisting of 30 traffic tasks categorized into three levels of complexity to evaluate both systems: ⢠L1 (Basic): Tasks requiring simple extraction of ge- ographical networks and qualitative traffic flows (e.g., âmedium trafficâ). ⢠L2 (Intermediate): Multi-step tasks requiring specific origin-destination (O-D) demand modeling and param- eter alignment across tools. ⢠L3 (Complex): Tasks enforcing structural network modifications (e.g., removing specific streets or closing lanes) strictly prior to demand generation. B. Performance Metrics We utilize the following metrics for quantitative evalua- tion: ⢠Success Rate (SR): Percentage of tasks that success- fully generate a valid .sumocfg and execute without physical errors. ⢠Average Token Consumption (Avg Tokens): The aver- age number of input and output tokens consumed by the LLM during the full task completion process. ⢠Time-to-Insight (TTI): The total wall-clock time from user input to the extraction of the first valid KPI. C. Role Ablation Study The ablation results across varying complexities are sum- marized in Table I. While both architectures perform reliably in basic scenarios (L1, L2), the monolithic baselineâs success rate (SR) degrades to 70.0% in complex L3 tasks. Analysis of failure logs indicates this degradation is primarily driven by Path Reference Errors and Reasoning Drift caused by over- whelming context windows. By explicitly managing state transitions via the Orchestrator, our multi-agent framework maintains a robust 90.0% SR. Beyond reliability, the decoupled âPlanner-Workerâ archi- tecture exhibits a profound efficiency advantage. By pro- viding each specialized agent with only the precise context required for its sub-task, the framework eliminates redun- dant reasoning overhead, reducing token consumption by approximately 50%. Consequently, the Time-to-Insight (TTI) is drastically accelerated; for instance, L3 pipelines are completed in just 8.3 seconds, compared to the baselineâs 41.4 seconds. TABLE I ABLATION STUDY BETWEEN MONOLITHIC BASELINE AND PROPOSED MULTI-AGENT FRAMEWORK ComplexityMetricsMonolithic BaselineMulti-Agent L1 (Basic) SR (%) â100.090.0 Avg Tokens â8529.24845.5 TTI (s) â19.86.2 L2 (Intermediate) SR (%) â100.0100.0 Avg Tokens â9690.35310.1 TTI (s) â22.77.3 L3 (Complex) SR (%) â70.090.0 Avg Tokens â11404.76028.7 TTI (s) â41.48.3 D. Closed-loop Autonomy Study To evaluate the autonomous feedback mechanism, we con- ducted a closed-loop refinement experiment by configuring the Analyst agent with 0 (open-loop), 1, and 2 maximum repair attempts (Table I). In intermediate (L2) and complex (L3) scenarios, open- loop execution struggles (30.0% SR) due to unresolved topological conflicts or unroutable demand pairs. However, enabling a single repair loop allows the system to diagnose and correct these errors via verbal reinforcement, yielding Planner agent: You are a TOP-LEVEL planner for a SUMO traffic simulation multi-agent system. Your job: Read USER_INPUT and the current simulation state. Decompose the task into a sequence of steps (1â5). For EACH step, write short natural-language instructions that include NECESSARY physical parameters for downstream agents. Parameter Alignment Contract (Include these in your natural language instructions): 1. For Builder: Must specify "city_name", "distance_miles" (e.g. 1.5), and "volume" (total trips). Other contracts for role agents ...... Instruction Style Examples: planner examples Planner Agent Prompt 'plan': ['step_id': 1, 'goal': 'Build a 1.5 km simulation network in Boston', 'agent_prompts': 'builder': 'Build a network for Boston with 1.5 miles radius and 1000 volume.', 'demand': â˛, 'modifier': â˛, 'runner_planner': â˛, 'analyst': â˛, 'step_id': 2, 'goal': 'Close Boylston Street in the network', 'agent_prompts': 'builder': â˛, 'demand': â˛, 'modifier': "Remove the edge with ID 'Boylston Street' from the generated network.", 'runner_planner': â˛, 'analyst': â˛, ...... 'step_id': 5, 'goal': 'Analyze the simulation results for average waiting time', 'agent_prompts': 'builder': â˛, 'demand': â˛, 'modifier': â˛, 'runner_planner': â˛, 'analyst': 'Analyze the simulation results focusing on waiting_time.'] User Input Builder Agent: Input: Build a network for Boston with 1.5 miles radius and 1000 volume. Output: 'action': 'BUILD_NET', 'params': 'type': 'build_from_realworld', 'city_name': 'Boston', 'distance_miles': 0.932056788, 'volume': 1000 Network generation Planner Agent Output 1 Create a 1.5 km simulation in Boston. Close 'Boylston Street', send 800 veh/hour from 'Newbury Street' to 'Beacon Street', execute the run, and report the average waiting time. 2 34 Fig. 3.Workflow of the top-level Planner agent for hierarchical task decomposition and parameter alignment. a significant 20% performance leap to a 50.0% SR. A second repair attempt maintains this SR, indicating that most recoverable errors are resolved within the first reflection cycle. This robustness introduces a necessary computational trade-off. Iterative debugging requires agents to parse error logs and synthesize corrections, proportionally increasing to- ken usage (e.g., from 3,981 to 9,214 in L3). Furthermore, an âoverthinkingâ phenomenon is observed in simple L1 tasks, where the SR temporarily drops from 90.0% to 80.0% before recovering, as the Analyst occasionally misinterprets benign zero-vehicle warnings as critical failures. Nonetheless, the closed-loop mechanism proves essential for satisfying com- plex physical constraints without human intervention. TABLE I IMPACT OF CLOSED-LOOP REFINEMENT ON TASK PERFORMANCE ComplexityMetrics0 Repairs1 Repair2 Repairs (Open-Loop)(Attempt)(Attempts) L1 (Basic) SR (%) â90.080.090.0 Avg Tokens â4969.15530.36752.6 L2 (Intermediate) SR (%) â30.050.050.0 Avg Tokens â3601.66829.58484.8 L3 (Complex) SR (%) â30.050.050.0 Avg Tokens â3981.66609.99214.1 E. Discussion The experimental results highlight that monolithic LLMs suffer from severe cognitive overload and âreasoning driftâ when simultaneously managing topology modifications, route generation, and parameter alignment. Our proposed hierarchical decomposition resolves this by confining spe- cialized agents to strict operational boundaries, ensuring topological constraints are physically validated before traf- fic demand is injected. Furthermore, the data reveals an efficiency paradox regarding token utilization and Time-to- Insight (TTI): while multi-agent orchestration introduces a marginal initial token overhead for planning, it drastically ac- celerates the overall TTI. By utilizing MCP for deterministic artifact handovers, the framework eliminates the prolonged, futile ReAct trial-and-error loops caused by hallucinated state transitions. Ultimately, this decoupled architecture shifts the computational focus from debugging low-level syntax errors to autonomously optimizing urban mobility KPIs. V. CONCLUSION This paper presented a decoupled âPlanner-Workerâ multi- agent framework to automate SUMO traffic simulations, overcoming the reasoning drift of monolithic LLMs through an MCP-based Orchestrator and a dual-loop reflexion mech- anism. Empirical evaluations demonstrate that in complex scenarios (L3), our architecture achieved a 90% success rate, halved token consumption, and accelerated Time-to-Insight (TTI) by a factor of five (from 41.4s to 8.3s). Furthermore, the autonomous error-recovery mechanism successfully sal- vaged failed executions, boosting the closed-loop success rate from 30% to 50% with minimal repair attempts. By proving the viability of KPI-driven autonomous optimization, this work lays the foundation for fully automated urban mobility laboratories. The benchmark tasks, prompt templates, and evaluation scripts will be released. Although the framework is model-agnostic at the tool-interface level, its practical re- liability depends on the backbone modelâs ability to produce schema-compliant JSON and follow role-specific constraints. We therefore expect smaller or less instruction-tuned models to show more frequent contract violations unless constrained decoding or external JSON validation is applied. System code will be released after internal review. Future research will scale this framework to city-level generative world mod- els by integrating multimodal foundation models, and apply reinforcement fine-tuning (e.g., R1-style policy optimization) to the Planner to further enhance its zero-shot reasoning and multi-step decomposition capabilities. ACKNOWLEDGMENT This work is funded through the IBM-RPI Future of Computing Research Collaboration. REFERENCES [1] H. Maheshwari, L. Yang, and R. W. Pazzi, âMachine learning advance- ments in urban traffic simulation: A comprehensive survey,â IEEE Open Journal of Intelligent Transportation Systems, 2025. [2] M. M. Haque, âSystematic review on the impact of ai-enhanced traffic simulation on u.s. urban mobility and safety,â ASRC Procedia: Global Perspectives in Science and Scholarship, vol. 1, no. 1, p. 833â861, 2025. [3] S. Tan, J. Luo, J. Lambert, H. Jeon, S. Kulshrestha, Y. Bai, D. Anguelov, M. Tan, and C. M. Jiang, âScenediffuser++: City-scale traffic simulation via a generative world model,â in Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), 2025. [4] S. Zhang, D. Fu, W. Liang et al., âTrafficgpt: Viewing, processing and interacting with traffic foundation models,â Transport Policy, vol. 150, p. 95â105, 2024. [5] Z. Liu, L. Li, Y. Wang, H. Lin, H. Cheng, Z. Liu, L. He, and J. Wang, âControllable traffic simulation through llm-guided hierarchical rea- soning and refinement,â in IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), 2025. [6] Y. Yao, S. Bhatnagar, M. Mazzola, V. Belagiannis, I. Gilitschenski, L. Palmieri, S. Razniewski, and M. Hallgarten, âAgents-llm: Aug- mentative generation of challenging traffic scenarios with an agentic llm framework,â in IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), 2025. [7] P. A. Lopez, M. Behrisch, L. Bieker-Walz, J. Erdmann, Y.-P. Fl Ě otgelow, R. Hilbrich, L. L Ě ucken, J. Rummel, P. Wagner, and E. WieĂner, âMicroscopic traffic simulation using sumo,â in 21st International Conference on Intelligent Transportation Systems (ITSC).IEEE, 2018, p. 2575â2582. [8] S. Li, T. Azfar, and R. Ke, âChatsumo: Large language model for automating traffic scenario generation in simulation of urban mobility,â IEEE Transactions on Intelligent Vehicles, 2024. [9] M. Cemri, M. Z. Pan, S. Yang, R. Tiwari, A. Kannan, B. Chopra, K. Keutzer, K. Ramchandran, M. Zaharia, L. A. Agrawal et al., âWhy do multi-agent llm systems fail?â arXiv preprint arXiv:2503.13657, 2025. [10] Q. Wu, G. Bansal, J. Zhang, Y. Wu, B. Li, E. Zhu, L. Jiang, X. Zhang, S. Zhang, J. Liu et al., âAutogen: Enabling next-gen llm applications via multi-agent conversation,â arXiv preprint arXiv:2308.08155, 2023. [11] K.-T. Tran, D. Dao, M.-D. Nguyen, Q.-V. Pham, B. OâSullivan, and H. D. Nguyen, âMulti-agent collaboration mechanisms: A survey of llms,â arXiv preprint arXiv:2501.06322, 2025. [12] Anthropic,âModelcontextprotocol(mcp)specification,â https://modelcontextprotocol.io, 2024. [13] C. Ye, G. Xiong, J. Shang, X. Dai, X. Gong, and Y. Lv, âSumo- mcp: Leveraging the model context protocol for autonomous traffic simulation and optimization,â arXiv preprint arXiv:2506.03548, 2025. [14] N. Shinn, F. Cassano, A. Gopinath, K. Narasimhan, and S. Yao, âReflexion: Language agents with verbal reinforcement learning,â in Advances in Neural Information Processing Systems (NeurIPS), vol. 36, 2023. [15] J. Zhang, C. Xu, and B. Li, âChatscene: Knowledge-enabled safety- critical scenario generation for autonomous vehicles,â in Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recog- nition (CVPR), 2024. [16] S. Li, M. Ma, T. Azfar, and R. Ke, âChatsumo agent: Anllm-basedagentforconversationaltrafficsimulation insumo,âTransportationResearchPartC:Emerging Technologies, vol. 190, p. 105759, 2026. [Online]. Available: https://w.sciencedirect.com/science/article/pii/S0968090X26002470 [17] M. Jeong, J. Chang, and Y. Yoon, âAgentsumo: An agentic frameworkforinteractivesimulationscenariogenerationin sumo via large language models,â 2025. [Online]. Available: https://arxiv.org/abs/2511.06804 [18] Y. Du, J. Zhang, J. Feng, Z. Liu, J. Yuan, and Y. Li, âTrafficsimagent: A hierarchical agent framework for autonomous traffic simulation with mcp control,â arXiv preprint arXiv:2512.20996, 2025. [19] Y. Talebirad and A. Nadiri, âMulti-agent collaboration: Harnessing the power of intelligent llm agents,â arXiv preprint arXiv:2306.03314, 2023. [20] H. Zhou, X. Wan, R. Sun, H. Palangi, S. Iqbal, I. Vuli Ě c, A. Korhonen, and S. Ě âO. ArÄąk, âMulti-agent design: Optimizing agents with better prompts and topologies,â 2026. [Online]. Available: https://arxiv.org/abs/2502.02533 [21] S. Hong, M. Zhuge, J. Chen, X. Zheng, Y. Cheng, C. Zhang, J. Wang, Z. Wang, S. K. Yau, Z. Lin et al., âMetagpt: Meta programming for a multi-agent collaborative framework,â in The Twelfth International Conference on Learning Representations (ICLR), 2024. [22] C. Qian, X. Cong, C. Yang, W. Chen, Y. Su, J. Xu, Z. Liu, and M. Ma, âCommunicative agents for software development,â in Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (ACL), 2024. [23] S. Huang, C. Sun, R.-Q. Wang, and D. Pompili, âToward adaptive and coordinated transportation systems: A multi-personality multi- agent meta-reinforcement learning framework,â IEEE Transactions on Intelligent Transportation Systems, vol. 26, no. 8, p. 12 148â12 161, 2025. [24] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao, âReact: Synergizing reasoning and acting in language models,â in International Conference on Learning Representations (ICLR), 2023. [25] T. Schick, J. Dwivedi-Yu, R. Dess ` Äą, R. Raileanu, M. Lomeli, L. Zettle- moyer, N. Cancedda, and T. Scialom, âToolformer: Language models can teach themselves to use tools,â in Advances in Neural Information Processing Systems (NeurIPS), vol. 36, 2023. [26] M. Pei, S. Shi, and S. Shen, âAdvancing multi-agent traffic simulation via r1-style reinforcement fine-tuning,â arXiv preprint arXiv:2509.23993, 2025. APPENDIX I SYSTEM PROMPTS USED IN THE MULTI-AGENT FRAMEWORK BASE_SYSTEM_PROMPT = """You are a specialized agent for a SUMO traffic simulation system. STRICT OUTPUT RULE: - Return EXACTLY ONE JSON object. No code fences, no extra text. - Schema: "action": "...", "params": ..., "reason": "...", "decision": "summary": "..." STRICT ROAD NAME RULE: - ALWAYS use original OSM "name" tags with SPACES (e.g., "Main Street"). - Do NOT use underscores or identifier-style strings. - If an input has underscores, convert them back to spaces. OPERATIONAL RULES: - If the latest observation contains "status":"error", use MODIFY to fix it based on âcandidatesâ. - Use deterministic seeds (seed=42) unless requested otherwise. - Choose STOP if the assigned goal is complete or no further action is needed. """ APPENDIX I PLANNER PROMPTS USED IN THE MULTI-AGENT FRAMEWORK PLANNER_SYSTEM_PROMPT = """You are a TOP-LEVEL planner for a SUMO traffic simulation multi-agent system. Your job: - Read USER_INPUT and the current simulation state. - Decompose the task into a sequence of steps (1--5). - For EACH step, write short natural-language instructions that include NECESSARY physical parameters for downstream agents. Return EXACTLY ONE JSON object with this schema: "status": "ok", "version": "v1", "plan": [ "step_id": <int>, "goal": "short description", "agent_prompts": "builder": "instruction string", "demand": "instruction string", "modifier": "instruction string", "runner_planner": "instruction string", "analyst": "instruction string" ], "reason": "explanation", "decision": "summary": "brief summary" Parameter Alignment Contract (Include these in your natural language instructions): 1. For Builder: Must specify "city_name", "distance_miles" (e.g. 1.5), and "volume" (total trips). 2. For Modifier (Network Modification): - Use ONLY if the user explicitly asks to modify, remove, or optimize the network/TLS. - Specify "op" (remove_edge, tls_optimize_and_apply) and "target_id" (edge_id or tls_id). 3. For Demand (CRITICAL Logic): - IF specific locations: Specify "from_edge", "to_edge", and "vph". * Example * : "Generate flow from Main Street to Congress Street with 800 vph." - ELSE: Specify "flows" (total vehicles). * Example * : "Generate 1200 random flows for the network." 4. For Runner: Specify if "gui" is needed and "steps" limit. 5. For Analyst: Specify the "metric" (mean_speed, co2, travel_time, or waiting_time). Pipeline Policy: - Sequence Logic: Network must be fully ready before Demand generation. - Standard flow (4 steps): Builder -> Demand -> Runner -> Analyst. - Modification flow (5 steps): Builder -> Modifier -> Demand -> Runner -> Analyst. - Each step MUST contain ONLY ONE active agent_prompt. All other agent_prompts in that step MUST be "". Rules: - Output MUST be valid JSON only. - Road name handling: Use original OSM names with spaces (e.g., "Main Street"). - If NO modification is requested, SKIP the modifier step entirely. Instruction Style Examples: - "Build a network for Troy with 0.5 miles radius and 1000 volume." (Builder) - "Remove the edge with ID â12345678â from the generated network." (Modifier) - "Generate 1200 random flows for the modified network." (Demand) - "Run simulation for 3600 steps with GUI enabled." (Runner) - "Analyze the simulation results focusing on travel_time." (Analyst) """ APPENDIX I ROLE PROMPTS USED IN THE MULTI-AGENT FRAMEWORK ROLE_PROMPTS = "builder": BASE_SYSTEM_PROMPT + """ You are the BUILDER Agent. Your sole responsibility is to generate network parameters. DECISION LOGIC: 1. If the instruction mentions a city name (e.g., "Troy", "Albany"), you MUST use "type": "build_from_realworld". 2. Only use "type": "roundabout" if the user explicitly asks for a generic roundabout. STRICT PARAMETER RULE: - For "build_from_realworld": - REQUIRED: "city_name" (string), "distance_miles" (float), "volume" (int). - Do NOT include "radius" or "lanes" unless building a roundabout. - Your "params" object MUST be flat. Do NOT wrap it in extra keys like "OSM". ACTION: "BUILD_NET" - Example Correct: "action": "BUILD_NET", "params": "type": "build_from_realworld", "city_name": "Troy", "distance_miles": 0.31, "volume": 1000 """, "demand": BASE_SYSTEM_PROMPT + """ You are the DEMAND Agent. Your role is to generate traffic. DECISION LOGIC: 1. IF the user specified specific streets or a path (e.g., "from Main St to State St"): - Use "type": "generate_flow_route" - Params: "from_edge": str, "to_edge": str, "vph": int 2. ELSE (If only âmedium trafficâ, â1000 vehiclesâ, or no specific path is mentioned): - Use "type": "build_routes_random" - Params: "flows": int (default flows to 1000 if not specified) STRICT RULE: - Do NOT hallucinate edge IDs. If the user mentions street names, use the street names as strings. - Only use âgenerate_flow_routeâ if both âfromâ and âtoâ locations are clear. """, "modifier": BASE_SYSTEM_PROMPT + """ You are the MODIFIER Agent. You modify an existing network. ACTION: "MODIFY" PARAMS CONTRACT (Required key "op"): - "remove_edge": "edge_id": str, "volume": number - "edge_set_speed": "edge_id": str, "vmax": number - "tls_optimize_and_apply": "tls_id": str, "cycle": float - "tls_set_program": "tls_id": str, "program_xml": str """, "runner_planner": BASE_SYSTEM_PROMPT + """ You are the RUNNER Agent. You execute the simulation. ACTION: "RUN" PARAMS CONTRACT: - Optional: "steps": int, "gui": bool GUIDANCE: Set gui to true only if explicitly requested. """, "analyst": BASE_SYSTEM_PROMPT + """ You are the ANALYST Agent. You interpret results. ACTION: "ANALYZE" PARAMS CONTRACT (Required key "metric"): - Values: "mean_speed", "co2", "travel_time", "waiting_time", or "all". """