ControlAgent: Automating Control System Design via Novel Integration of LLM Agents and Domain Expertise

## Abstract

Abstract Control system design is a crucial aspect of modern engineering with far-reaching applications across diverse sectors including aerospace, automotive systems, power grids, and robotics. Despite advances made by Large Language Models (LLMs) in various domains, their application in control system design remains limited due to the complexity and specificity of control theory. To bridge this gap, we introduce ControlAgent , a new paradigm that automates control system design via novel integration of LLM agents and control-oriented domain expertise. ControlAgent encodes expert control knowledge and emulates human iterative design processes by gradually tuning controller parameters to meet user-specified requirements for stability, performance (e.g. settling time), and robustness (e.g., phase margin). Specifically, ControlAgent integrates multiple collaborative LLM agents, including a central agent responsible for task distribution and task-specific agents dedicated to detailed controller design for various types of systems and requirements. In addition to LLM agents, ControlAgent employs a Python computation agent that performs complex control gain calculations and controller evaluations based on standard design information (e.g. crossover frequency, etc) provided by task-specified LLM agents. Combined with a history and feedback module, the task-specific LLM agents iteratively refine controller parameters based on real-time feedback from prior designs. Overall, ControlAgent mimics the design processes used by (human) practicing engineers, but removes all the human efforts and can be run in a fully automated way to give end-to-end solutions for control system design with user-specified requirements. To validate ControlAgent’s effectiveness, we develop ControlEval , an evaluation dataset that comprises 500 control tasks with various specific design goals. The effectiveness of ControlAgent is demonstrated via
extensive comparative evaluations between LLM-based and traditional human-involved toolbox-based baselines.
Our numerical experiments show that ControlAgent can effectively carry out control design tasks, marking a significant step towards fully automated control engineering solutions. Our code is available at https://github.com/ControlAgent/ControlAgent.git

## 1 Introduction

Recent advancements in large language models (LLMs) have spurred the development of sophisticated LLM agents, demonstrating remarkable capabilities in areas such as code generation, reasoning, tool use, and software development, among many other applications (Hong et al., ; Zhang et al., ; Mei et al., ; Wu et al., ; Liu et al., ; Talebirad and Nadiri, ; Li et al., ; M. Bran et al., ; Liu et al., , ; Zhuge et al., ). Despite these breakthroughs, the application of LLM agents in modern engineering design remains relatively underexplored. Building on the exciting progress in LLM reasoning, it seems natural to expect great potential of LLMs as modern engineering design assistants. By breaking down complex engineering design processes into smaller specific tasks, LLM agents could potentially improve both the productivity and efficiency of engineering workflows via reducing human efforts from practicing engineers.

Control design is a cornerstone of modern engineering, underpinning a wide range of applications in both daily life and industrial processes, such as automobile cruise control systems, home thermostats, industrial robot manipulators, aircraft autopilots, chemical process control in refineries, and power grid frequency regulation (Åström and Murray, ; Ogata, ; Boyd and Barratt, ; Anderson, ; Rivera et al., ). Conventional controller design often requires human expertise and iterative design protocols, which may involve tedious repeated computation work. For instance, Proportional-Integral-Derivative (PID) control has been widely used in industry, but its design process involves iterative tuning from practicing control engineers to meet conflicting requirements(^1^11Due to the fundamental trade-offs between performance and robustness, control design is intrinsically subtle with a multi-objective nature. For example, classical control aims to achieve fast reference tracking and disturbance rejection while also being insensitive to noise and robust to model uncertainty.) in terms of system performance and robustness (Ogata, ; Xu et al., ; Liu et al., ). It seems natural to ask whether LLMs can be leveraged to automate such tedious design processes and reduce the burden on human experts. In this paper, we provide an affirmative answer to this question via integrating LLM agents and control-oriented domain expertise in a novel manner.

Figure: Figure 1: General ControlAgent framework.
Refer to caption: x1.png

Specifically, our paper presents ControlAgent, an LLM-based framework that automates control system design by seamlessly integrating domain knowledge and tool utilization (see Figure 1).
ControlAgent encodes expert control knowledge and emulates human iterative design processes by gradually tuning controller parameters to meet user-specified requirements for stability, performance (e.g. settling time), and robustness (e.g., phase margin). ControlAgent integrates multiple collaborative LLM agents, including a central agent for task distribution and task-specific agents for detailed controller design across various systems and requirements, alongside a Python computation agent that performs complex control gain calculations and evaluations based on standard design information provided by the task-specific LLM agents. Utilizing a history and feedback module, ControlAgent enables task-specific LLM agents to iteratively refine controller parameters, mimicking the design processes of practicing engineers while eliminating human effort to provide fully automated, end-to-end solutions for control system design that meet user-specified requirements.
Figure 1 illustrates a general overview of the ControlAgent framework. Users simply provide the necessary task information, such as the dynamic systems to be controlled and the associated performance requirements. ControlAgent then analyzes the task, performs iterative design processes similar to practicing engineers, and returns the final design solution. Our contributions are threefold and summarized as below.

- 1.
We present ControlAgent, a first fully automated LLM-based framework that emulates human-like iterative design processes for control engineering. By integrating domain-specific human expertise into LLM agents and combining external tool use, ControlAgent systematically refines control designs based on prior designs without human intervention.
- 2.
We construct ControlEval, a thorough evaluation benchmark for classic control design, ranging from relatively simple first-order system designs to more complex higher-order system designs. This benchmark serves as a standard for evaluating LLM-based control design workflows.
- 3.
We conduct a comprehensive experimental study on ControlEval to validate the performance and robustness of ControlAgent, demonstrating superior performance of ControlAgent over both LLM-based and traditional toolbox-based baseline methods.

##### Unique Novelty.

Recently, there has been some work showing that LLMs have gained knowledge related to control engineering and can answer textbook-level control system questions to some extent (Kevian et al., ). However, going beyond the textbook level, LLMs still cannot generate practical control design in a reliable manner. Beside the computation errors, LLMs may also make various reasoning errors for practical control design. A key gap is that control design is intrinsically subtle due to the performance-robustness trade-off, and LLMs do not know how to mitigate such subtle trade-offs in a reliable way even if they are exposed to many different control methods. In this paper, we develop ControlAgent in a way that it mimics how practicing engineers mitigate such design trade-offs via PID tuning and frequency-domain loop-shaping (see Figure 1). Consequently, ControlAgent becomes reliable in designing controllers with satisfying performance and robustness.

## 2 Related Work

##### Classic Control Design.

Controller design is traditionally approached in a case-by-case manner, as it heavily depends on the specific applications at hand. Among various control strategies, PID control and loop-shaping remain the most widely used due to their simplicity and ease of implementation.
Over the years, a plethora of PID/loop-shaping tuning methods have been developed (Åström and Hägglund, ; Skogestad, ; Mann et al., ; Awouda and Mamat, ; O’dwyer, ; Padula and Visioli, ; Panda, ; Lequin et al., ; Skogestad, ). Despite these advancements, the tuning process still heavily relies on human expertise and manual intervention to identify suitable controller parameters that meet design criteria. ControlAgent aims to fill this gap via integrating LLM agents and human expert knowledge for automating control system design.

##### LLM for Engineering Design.

Several studies have explored the potential of LLMs in addressing various engineering domains (Ghosh and Team, ; Poddar et al., ; Alsaqer et al., ; Majumder et al., ). In addition, (Kevian et al., ; Syed et al., ; Xu et al., ) introduced benchmark datasets to evaluate the textbook-level knowledge of LLMs in control, transportation, and water engineering. AnalogCoder (Lai et al., ) is developed for analog circuits design, while SPICED (Chaudhuri et al., ) focused on the bug detection in circuit netlists with the aid of LLMs. Furthermore, AmpAgent (Liu et al., ) utilizes LLMs for multi-stage amplifier design.

##### LLM-based Agents.

LLM-based agents take textual or visual information as input for complex task solving, which has attracted a lot interests in both academia and industry recently (Wang et al., ). In particular, multi-agent systems leverage the interaction among multiple LLM agents for more complex tasks (Zhuge et al., ; Josifoski et al., ; Park et al., ; Li et al., ; Zhuge et al., ). For example, AutoGen (Wu et al., ) provides a generic multi-agent framework for various applications including coding, question answering, mathematics, etc. MetaGPT (Hong et al., ) is a multi-agent LLM framework inspired by the Standardized Operating Procedures developed from human protocol for efficient task decomposition and coordination.
Overall, the field of LLM agents is very active. See Appendix B.1 for a more comprehensive literature review.

## 3 Preliminary

This section briefly reviews the basic background of classic control. The field of control engineering focuses on the design, analysis, and implementation of feedback mechanisms that are used to regulate and steer dynamic systems to achieve desired outputs or behaviors (Åström and Murray, ; Ogata, ).
Application examples includes everyday devices like the heating and air conditioning as well as more advanced systems such as autonomous cars and airplane autopilots. First, we will review the notion of dynamical systems studied in classic control.

##### Dynamical System Models.

A dynamical system can be represented in various mathematical forms to describe the relationship between the inputs and outputs, including differential equations, state-space models, and transfer functions (Goodwin et al., ; Boyd and Barratt, ). The main objects studied in classic control design are linear time-invariant (LTI) systems, which can be represented in either time domain by a linear ordinary differential equation (ODE) or in frequency domain by an equivalent transfer function.
For instance,
the transfer function of an LTI system has the following form:

$$ $G(s)=\frac{b_{m}s^{m}+b_{m-1}s^{m-1}+\cdots+b_{1}s+b_{0}}{a_{n}s^{n}+a_{n-1}s^ {n-1}+\cdots+a_{1}s+a_{0}},$ (3.1) $$

where $s$ is the complex frequency variable in the Laplace domain.
It is common to assume that the system is proper ($m\leq n$) as this aligns with models for physical systems.
Notice that the system (3.1) has an equivalent time-domain ODE form that relates the input signal $u(t)$ to the output signal $y(t)$:

$$ $\displaystyle a_{n}\frac{d^{n}}{dt^{n}}\,y(t)+\ldots+a_{1}\frac{d}{dt}\,y(t)+a _{0}\,y(t)=b_{m}\frac{d^{m}}{dt^{m}}\,u(t)+\ldots+b_{1}\frac{d}{dt}\,u(t)+b_{0 }\,u(t)$ (3.2) $$

This form is general enough to model the dynamics of various practical systems such as automotive systems, robotics, and many others.
Importantly, there always exist gaps between models and reality. Classic
control design is highly successful in practice as control engineers use safety factors ("stability margins") that account for such model-reality gaps.

Figure: Figure 2: A feedback control system illustrating the reference $r$, measured output $y$, disturbance $d$, and noise $n$. The dynamical model $G(s)$ provides a mathematical approximation of the real physical system. The inherent mismatch between the real system and its mathematical model underscores the need for a robust controller $C(s)$ to ensure reliable performance despite modeling inaccuracies.
Refer to caption: x2.png

##### Classic Control Design.

Feedback control, shown in Figure 2, can be used to steer the plant output $y(t)$ to track a reference signal $r(t)$. This architecture: (a) uses a sensor to measure the output $y(t)$, (b) computes the tracking error $e(t)=r(t)-y(t)$, and (c) uses a control algorithm $C(s)$ to compute the input to the plant based on the error. Figure 2 depicts a standard feedback loop where the measured output $y(t)$ is used by the controller to compute the input to the system which then affects the output $y(t)$. This architecture is known as closed-loop control because
feeding the measurement back to the controller creates a loop around the plant.
A key lesson from modern control engineering is that the robustness
to disturbance and model uncertainty can be typically achieved by a closed-loop design equipped with sensing,
actuation, and feedback.
Classical control focuses on designing the controller $C(s)$ (which is an LTI system by itself and implemented on a microprocessor).
There are numerous, often conflicting, objectives for classic control design, and standard design requirements include:

- •
Closed-loop stability: A poorly designed system can cause a system to go unstable, i.e. signals can grow unbounded. The practical consequence is that the system or device can be destroyed leading to financial loss or even loss of life. To avoid this, closed-loop stabibility is a must.
- •
Fast reference tracking: The controller should be designed so that the system output tracks the desired reference command. This involves various performance metrics but mainly the system should respond quickly to changes in the reference command.
- •
Disturbance rejection:
Disturbances $d(t)$ are external signals that affect the plant dynamics. For example, the a car with a cruise control system is affected by forces due to wind gusts and hills. The controller should be designed so that disturbances have small effect on tracking.
- •
Actuator limits: The input signal generated by the controller should remain within allowable levels. For example the throttle (accelerator) on a car can only move by a certain amount. The command from the controller must remain within these allowable bounds.
- •
Rejection of sensor noise: The feedback controller relies on sensor measurements. It is typically required that any measurement
inaccuracies, e.g. noise, have small effect on tracking. Moreover, the noise should have a small effect on the control effort.
- •
Robustness to model-reality gap: As noted above, there exist some gaps between the model used for control design and the true systems that the controller is deployed on. The controller must be robust, i.e. insensitive, to such model-reality gaps that typically include errors due to parameter variations and unmodeled dynamics.

This multi-objective nature necessitates the performance/robustness
trade-offs, which lie at the core of classic control design.

##### Performance/Robustness Trade-offs.

The various design requirements roughly boil down to three main categories : i) closed-loop stability , ii) performance (e.g. tracking speed), and iii) robustness (see Appendix B.2 for definitions). The settling time $T_{s}$ is arguably the most important performance metric, since it measures the time required for the system’s response to reach within a specified percentage (e.g., 2% or 5%) of the steady-state value, and small $T_{s}$ just implies fast reference tracking.
Robustness is also crucial. As illustrated in Figure 2, there always exist a gap between the dynamical model used for control design and the real physical system which the controller is deployed on. It is a must to make the controller robust against the model-reality gap.
In this context, phase margin is typically recognized as the most important robustness metric (Chang and Han, ; Ho et al., ), and on the conceptual level, large phase margin implies strong robustness.
Since achieving small settling time (fast tracking) and large phase margin (robustness) are competing objectives, practicing control engineers typically use settling time and phase margin as tuning knobs for navigating the performance/robustness trade-offs in classic control design. There are many secondary metrics (e.g. gain margin, etc) that can be used to provide fine-grained descriptions for the six control design requirements mentioned above. However, it is known from control practice that PID and loop-shaping design with settling time and phase margin being tuning knobs can be sufficient in addressing the complicated performance/robustness trade-offs involving all six control design requirements simultaneously. One main goal of our study is to develop the first LLM-based framework that can automatically address such subtle performance/robustness trade-offs in control design.

Figure: Figure 3: The controller design process of ControlAgent, showcasing interactions between the User, Central agent, Python agent, History and Feedback module, and Task-Specific Agents to design a controller that meets stability, phase margin, and settling time requirements.
Refer to caption: x3.png

## 4 ControlAgent

Figure: Figure 4: Workflow of the task-specific agent in ControlAgent. The design history and feedback are dynamically updated based on previous iterations. ControlAgent refines its designs iteratively, incorporating user instructions and feedback at each step. By the third iteration, ControlAgent achieves a final design that satisfies the user’s requirements, achieving a settling time of less than 0.3 seconds (as shown in the time response plot) and maintaining a phase margin consistently greater than $70^{\circ}$ (as depicted in the Bode plot).
Refer to caption: x4.png

In this section, we present ControlAgent, detailing its agent architecture, iterative design mechanisms, and communication protocols. An overview of ControlAgent has been illustrated in Figure 1,

##### Agent Design.

We break down the complex controller design into smaller and more specific tasks, requiring the collaboration of agents with different skills and expertise. ControlAgent compromises three types of agents:

- 1.
Central agent $\mathcal{A}_{c}$ acts as the task distributor, processes user inputs and assigns specific requests to the sublevel agents based on the nature of the controller design task.
- 2.
Task-specific agent $\mathcal{A}_{\text{spec}}$ receives the user request and high-level task analysis from the central agent, and encodes with domain-specific expertise to initiate the controller design process, following the iterative methodology discussed below.
- 3.
Python computation agent $\mathcal{A}_{p}$ carries out the complex computation steps involved in controller design and performance evaluations, ensuring reliable controller synthesis and evaluations.

For illustrations, Figure 3 presents an example of the controller design workflow within ControlAgent. The user initially provides the system’s dynamic model (represented as a transfer function) along with the specified design criteria on closed-loop stability, settling time, and phase margin. The central agent subsequently analyzes the task and delegates it to a specialized task-specific agent, tailored to the task’s requirements. Each task-specific agent, endowed with domain-specific expertise, initiates the design process upon receiving the assignment. The designed controller is evaluated by the Python agent, while a history and feedback module archives the design process and generates valuable feedback to enable iterative refinement.

Figure: Algorithm 1 Iterative Controller Design Process of ControlAgent

##### Iterative Design via Structured Memory Design.

ControlAgent relies on the iterative design and feedback mechanism to mimic the design processes used by practicing engineers (see Figure 4). Traditional controller design by control engineers often involves a cycle of trial and error, requiring fine-tuning of controller parameters based on observed feedback. Similarly, for LLM agents to perform control system design effectively, they must follow an iterative design process. This involves accessing previous designs and performance metrics, and using feedback to refine their outputs to improve the performance and robustness of the controller configuration.
However, storing all past outputs of LLM agents and simply reusing them in the next iteration is impractical due to the context window limitations of LLMs. To address this, ControlAgent manages memory through an efficient structured memory buffer $\mathcal{M}$ that retains only essential information: the previously designed controller parameters and their associated performances, rather than complete historical outputs. This strategy allows the agent to recall crucial details from past iterations without exceeding memory capacity.
In addition, ControlAgent also dynamically evaluates the current performance in comparison to user requirements. If the current design does not meet the requirements, a feedback $\mathcal{F}$ is created, encoded, and then incorporated into the input prompt for the LLM agent in the next iteration.

We summarize the iterative design process of ControlAgent as in Algorithm 1, and provide some detailed explanations here.
The input prompt to the LLM agents consists of four main components:

- 1.
Design instruction: the design instruction $\mathcal{E}_{\text{spec}}$ is distilled from domain expertise for each specific task to enhance the LLM agents’ capabilities in controller design with particular focus on mitigating performance/robustness trade-offs via PID or loop-shaping with settling time and phase margin being used as the tuning knobs.
- 2.
User requirements: the user requirements $\mathcal{U}$ are provided directly by the user.
- 3.
Memory and feedback: this component includes the retrieval of previous design parameters from the structured memory buffer $\mathcal{M}$, along with automatically generated feedback to highlight the deficiencies of the current design.
- 4.
Response instruction: the response instruction $\mathcal{R}$ specifies the response format to ensure that key information can be extracted efficiently.

Upon receiving the task requirements from the central agent $\mathcal{A}_{c}$, the task-specific LLM agent $\mathcal{A}_{\text{spec}}$ iteratively designs a new controller based on the provided instructions, previously failed designs, and feedback. During each iteration, $\mathcal{A}_{\text{spec}}$ generates a new controller design, which is then stored in the memory buffer. Subsequently, a Python agent $\mathcal{A}_{p}$ retrieves the design and conducts evaluations. If the current design satisfies the user-defined requirements, the iteration process halts, and the successfully designed controller is returned. Otherwise, a feedback signal is generated by comparing the current performance against the user requirements, and the process continues to the next iteration until the maximum iteration count is reached.

## 5 ControlEval

Since no suitable open-source dataset is currently available for validating ControlAgent, we developed a new evaluation dataset, called ControlEval, to serve this purpose. ControlEval consists of 10 distinct types of control tasks based on various systems and requirements. For each task type, we construct 50 individual systems, each paired with its corresponding design requirements, resulting in a comprehensive dataset of 500 control tasks. ControlEval includes a diverse set of
dynamical systems such as first-order stable and unstable systems, second-order stable and unstable systems with varying response speed modes, first-order systems with time delay, and general higher-order systems. The design criteria for each task involve a combination of closed-loop stability, settling time (to quantify tracking performance), and phase margin (to assess robustness). These are three key metrics for classic control design.
For first and second-order stable systems, we further differentiate between three different speeds of response defined by the variation in settling time: fast, moderate, and slow. The fast mode requires the system to converge to its steady-state value within a short period of time, which is typical for applications that demand quick response times, such as servo motor control systems (Krah and Klarenbach, ) and quadcopter flight control systems (Bramlette and Barrett-Gonzalez, ). In contrast, the slow mode requires a more gradual convergence, which is more suitable in scenarios where the dynamic system model is less precise and less aggressive control is desired, such as wind turbine control (Ossmann et al., ).
Some samples from ControlEval are provided in
Table 1 including the system types, system dynamical models, response mode, and the associated design requirements.

**Table 1: System models and their corresponding control design criteria.**
| System Type | 1st-order stb | 2nd-order stb | 1st-order w/ delay | Higher-order System |
| --- | --- | --- | --- | --- |
| System Model | $\dfrac{2.19}{s+10.99}$ | $\dfrac{5.88}{s^{2}+1.43s+0.91}$ | $\dfrac{8.79e^{-0.14s}}{s+4}$ | $\dfrac{225}{s^{3}+14.2s^{2}+46s+40}$ |
| Response Mode | Moderate | Slow | (-) | (-) |
| Stability | $\checkmark$ | $\checkmark$ | $\checkmark$ | $\checkmark$ |
| Settling Time Range | $T_{s}\in[0.04,0.58]$ | $T_{s}\in[12.70,34.04]$ | $T_{s}\in[0.63,6.68]$ | $T_{s}\in[1.05,8.4]$ |
| Phase Margin | $\phi_{m}\geq 81.74^{\circ}$ | $\phi_{m}\geq 61.57^{\circ}$ | $\phi_{m}\geq 44.06^{\circ}$ | $\phi_{m}\geq 62.54^{\circ}$ |

Due to inherent limitations in the control of unstable systems, systems with time delays, and higher-order systems, it is not always possible to satisfy arbitrary combinations of performance/robustness requirements (Stein, ; Seron et al., ; Freudenberg and Looze, , , ). Therefore, human experts have carefully curated the dataset to ensure that the task requirements are feasible and achievable.
Further information on the dataset can be found in Appendix D.

## 6 Experimental Results

In this section, we present a comprehensive set of experiments to evaluate the performance of ControlAgent on the ControlEval.
GPT-4o is used as the main underlying base LLM for both the central agent and task-specific agents, and study on comparing different base LLMs is also presented. The detailed prompts for ControlAgent can be found in Appendix E.1. Additionally, we compare ControlAgent against two different baseline categories: LLM-based and control toolbox-based baselines.

LLM-based Baselines: We consider four LLM-based baseline approaches utilizing GPT-4o: zero-shot prompting, zero-shot Chain-of-Thought (CoT), few-shot, and few-shot CoT. In the zero-shot approach, we directly provide the user requirements and ask the LLM to perform the controller design without additional guidance. The CoT variant enhances this by prompting the LLM to explicitly conduct the design step-by-step. For the few-shot approach, we present the LLM with several examples of successful controller designs to guide its process. In the few-shot CoT setting, the prompt not only includes the successful designs but also details the step-by-step reasoning process required to create a successful controller. The detailed prompt for each setting can be found in Appendix E.2.

Control Toolbox-based Baseline: We also considered the widely used control toolbox for PID design: PIDtune (MathWorks, ) from MathWorks as a baseline. This toolbox is human-involved as the user needs to specify a proper value of crossover frequency as an input to optimize the controller gains, whereas ControlAgent tunes crossover frequency automatically without any human effort. Further details on how we set up PIDtune are reported in Appendix C.

Evaluation Metrics:
We use two main metrics to evaluate the performance of ControlAgent and baseline methods. Specifically, we use Average Successful Rate (ASR) to measure the effectiveness of control designs across multiple independent trials for each method, and we use Aggregate Successful Rate (AgSR) to evaluate the success designs on a system-by-system basis, where one system is considered successfully designed if at least one of the multiple independent trials results in a successful controller design. The formal definition of ASR and AgSR can be found in Appendix C.

**Table 2: Average Success Rate (ASR, %) of baseline methods and ControlAgent on ControlEval for various system types and response modes. The best result for each task is highlighted in bold. The results show that ControlAgent consistently outperforms all other LLM-based and toolbox-based baselines (except the first-order system with delay) across all categories, demonstrating its effectiveness and robustness in handling diverse control tasks.**
| System Type | 1st-ord stb | 2nd-ord stb | 1st-ord ustb | 2nd-ord ustb | w/ dly | Hgr-ord |  |  |  |  |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Response Mode | fast | moderate | slow | fast | moderate | slow | (-) | (-) | (-) | (-) |
| Zero-shot | 8.0 | 19.2 | 10.0 | 14.0 | 18.4 | 13.2 | 5.2 | 0.4 | 15.6 | 2.0 |
| Zero-shot CoT | 26.8 | 3.2 | 0.4 | 12.4 | 18.8 | 12.0 | 4.4 | 0.8 | 8.8 | 8.0 |
| Few-shot | 12.4 | 19.6 | 15.6 | 12.0 | 12.4 | 15.2 | 14.0 | 29.2 | 11.6 | 12.0 |
| Few-shot CoT | 11.2 | 21.6 | 21.2 | 7.6 | 14.0 | 25.6 | 6.0 | 22.4 | 16.0 | 16.4 |
| PIDtune | 56.0 | 90.4 | 86.4 | 81.6 | 98.8 | 77.6 | 30.4 | 10.8 | 100.0 | 50.0 |
| ControlAgent | 100.0 | 100.0 | 100.0 | 100.0 | 98.8 | 90.8 | 97.2 | 96.8 | 97.2 | 82.0 |

### 6.1 Main Results

Table 2 shows the ASR of ControlAgent and various baseline methods on the ControlEval benchmark. The best results for each task are highlighted in bold. Our key observations are given below.

##### ControlAgent consistently outperforms all baseline methods.

ControlAgent achieves significantly higher ASR across all control tasks compared to both LLM-based and traditional toolbox-based baselines (with the sole exception of the first-order system with time delay, where ControlAgent achieves the second-best result at 97.2%). This superior performance is evident not only for simpler first-order and second-order stable systems but also for more complex cases, such as unstable systems and higher-order systems. The ability of ControlAgent to maintain high success rates across diverse system types showcases the potential of integrating LLMs with domain expertise, making it a highly reliable tool for automated control system design.

##### ControlAgent can solve easy tasks perfectly.

For relatively simpler systems, such as first/second-order stable systems, ControlAgent achieves perfect scores (100% ASR) across all response modes (fast, moderate, and slow). This indicates that ControlAgent is capable of flawlessly handling straightforward control problems, meeting all user-defined performance requirements.

##### PIDtune outperforms LLM-based baselines on most control tasks.

It is noteworthy that PIDtune, a control toolbox-based method, performs better than LLM-based baselines (e.g., Zero-shot and Few-shot) on most control tasks, except for second-order unstable systems. This suggests that LLMs alone or simple prompt engineering methods are not sufficient to solve many control tasks effectively. The results highlight the gap between standard LLM capabilities and traditional control toolboxes. ControlAgent bridges this gap by employing an iterative controller design procedure that integrates LLMs, control domain expertise, and tool utilization to mimic how practicing control engineers mitigate the performance/robustness trade-offs in classic control design.

##### Aggregating results from multiple trials significantly boosts overall performance.

Figure 5 illustrates the ASR and AgSR for ControlAgent and the baseline methods for first-order stable systems (averaged across fast, moderate, and slow modes) and higher-order system, respectively. We run each method for five independent trials. The results show that each method significantly improves its success rate, highlighting the advantage of aggregating results from multiple trials to boost overall performance. ControlAgent remains one of the top-performing methods, achieving high success rates across all methods. More AgSR results can be found in Appendix C.

Figure: Figure 5: ASR and AgSR for first-order stable systems (averaged across fast, moderate, and slow modes) and higher-order system.
Refer to caption: x5.png

### 6.2 Ablation Study

In this section, we perform ablation study on the ControlAgent.

**Table 3: Ablation study results (ASR and average iteration number) for ControlAgent and its various component configurations. The ablated versions exclude specific components, such as iterative refinement, user instructions, the Python agent, and feedback incorporation.**
|  | ControlAgent | w/o-iterative | w/o-instruction | w/o-python agent | w/o-feedback |  |  |  |  |  |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
|  | ASR | iteration # | ASR | iteration # | ASR | iteration # | ASR | iteration # | ASR | iteration # |
| fast | 100.0 | 2.74 | 28.4 | (-) | 70.4 | 4.84 | 76.0 | 4.34 | 85.6 | 4.45 |
| moderate | 100.0 | 1.78 | 33.2 | (-) | 60.4 | 6.38 | 85.2 | 3.71 | 92.4 | 3.05 |
| slow | 100.0 | 2.19 | 4.0 | (-) | 56.4 | 6.39 | 71.2 | 5.19 | 94.0 | 2.46 |

##### Effect of Key Components in ControlAgent:

To investigate the impact of different components within ControlAgent on its overall performance, we compare the ASR and the average number of iterations required for successful design across three response modes for first-order stable systems. The results, shown in Table 3, indicate that the complete version of ControlAgent achieves a perfect ASR (100%) across all response modes with the fewest iterations, underscoring the effectiveness of its integrated design. In contrast, removing the iterative design process leads to a drastic decline in ASR, particularly for the slow response mode, where the ASR drops to just 4%. Similarly, excluding design instructions or the Python agent significantly reduces the ASR and increases the number of iterations needed for success, highlighting the critical role these components play in improving design efficiency. Although ControlAgent performs reasonably well without feedback, the increased average iteration count shows that feedback is essential for faster convergence. Overall, these findings demonstrate that each component is vital to the robustness and efficiency of ControlAgent. Figure 6 demonstrates that increasing the maximum number of iterations consistently improvement in ASR across all response modes (fast, moderate, and slow) for first-order and second-order stable systems. As the number of iterations increases, ControlAgent has more opportunities to refine its design, which translates into higher success rates. This trend indicates that allowing more iterations enhances ControlAgent’s ability to meet control design criteria, particularly for complex scenarios that may require additional iterations to achieve optimal results.

Figure: Figure 6: The effect of the number of iterations on ASR across different response modes (Fast, Moderate, and Slow). Left: first order stable systems; right: second order stable systems.
Refer to caption: x6.png

**Table 4: ASR (%) and average number of iterations for ControlAgent using different base LLMs across three response modes (fast, moderate, and slow) for first-order stable systems. The highest ASR and lowest iterations highlighted in bold.**
| Base LLM | GPT-4o | Claude-3.5 Sonnet | GPT-4-turbo | Gemini-1.5-pro | GPT-3.5-turbo |  |  |  |  |  |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
|  | ASR | iteration # | ASR | iteration # | ASR | iteration # | ASR | iteration # | ASR | iteration # |
| fast | 100.0 | 2.74 | 98.4 | 2.66 | 94.0 | 3.82 | 86.8 | 2.96 | 49.2 | 6.84 |
| moderate | 100.0 | 1.78 | 99.2 | 2.05 | 98.4 | 2.55 | 86.4 | 2.41 | 97.2 | 3.01 |
| slow | 100.0 | 2.19 | 97.2 | 2.18 | 99.2 | 2.14 | 85.6 | 2.67 | 77.6 | 4.18 |

##### Results on Different Base LLMs:

Table 4 presents the performance of ControlAgent with different base LLMs, including GPT-4o, Claude-3.5 Sonnet, GPT-4-turbo, Gemini-1.5-pro, and GPT-3.5-turbo. The results indicate that all state-of-the-art LLMs achieve reasonably good performance, with most models attaining high ASR values across different response modes. GPT-4o stands out by achieving a perfect ASR (100%) in all response modes and requiring the fewest iterations in the moderate mode. Similarly, Claude-3.5 Sonnet and GPT-4-turbo perform competitively; notably, Claude-3.5 achieves near-perfect ASR and has the lowest iteration count for the fast and slow modes. Although there is still a performance gap for Gemini-1.5-pro and GPT-3.5-turbo, these findings suggest that the state-of-the-art LLMs perform similarly, demonstrating that ControlAgent is flexible and adaptable to a variety of LLM configurations.

## 7 Limitations and Future Work

In this paper, we introduced ControlAgent, an advanced LLM-powered framework for automated control system design. Despite the strong performance of ControlAgent across a range of control tasks, several limitations indicate avenues for future research and enhancement. One primary constraint is that the current implementation of ControlAgent is tailored to LTI systems and conventional control strategies, such as loop-shaping and PID controllers. Future work can expand ControlAgent’s capabilities by considering complex nonlinear systems and integrating advanced control strategies, such as adaptive and robust controllers. Another compelling direction involves utilizing different base LLMs for distinct roles, leveraging their unique strengths and expertise. For instance, incorporating fine-tuned, smaller LLMs for specialized tasks within control system design could improve efficiency and reduce dependence on proprietary models. Finally, the evaluation dataset, ControlEval, could be further extended to include more complex control tasks, such as real-world systems and hardware implementations, providing a more comprehensive assessment of ControlAgent’s practical utility. We provide more detailed discussions on the future research directions in Appendix A.

#### Ethics Statement

In developing ControlAgent, we carefully considered the ethical implications of our work and took steps to ensure responsible research practices. All experiments were conducted using simulation environments and synthetic datasets, with no involvement of human subjects, thereby avoiding any privacy, security, or legal compliance concerns. ControlAgent’s focus on automated control system design raises the possibility of its deployment in critical applications, such as industrial automation, autonomous vehicles, and robotics. Improper use or deployment of AI-driven control systems in such domains could result in unintended outcomes. To mitigate these risks, we emphasize the need for rigorous testing, validation, and adherence to established safety standards before applying ControlAgent to real-world systems.

In terms of transparency and accessibility, the use of proprietary LLMs may limit broader access and reproducibility. To address this, future work will explore the use of open-source LLMs to enhance accessibility and facilitate community collaboration. Additionally, since ControlAgent’s performance depends on LLMs that could inherit biases from their training data, ongoing research will focus on mitigating bias and ensuring fairness in control system recommendations. The authors declare no conflicts of interest or external sponsorship that influenced the findings or interpretations in this study. Overall, we are committed to developing and applying ControlAgent ethically, with careful consideration of its societal impact and potential risks.

#### Reproducibility Statement

We have taken several measures to ensure the reproducibility of our results. Detailed descriptions of the experimental setup, hyperparameters, and configurations are provided in Section 6 of the main paper and Appendix C. Specifically, the architecture of ControlAgent and the LLM prompt structures are outlined in Section 4 and Appendix E. We also provide comprehensive descriptions of the ablation studies and baseline comparisons in Section 6 to aid in reproducing the results. The dataset used in our experiments, including details on dataset generation and control design criteria, is thoroughly described in Appendix D.

## Acknowledgements

X. Guo, D. Kevian, U. Syed, and B. Hu acknowledge the support from the OpenAI
Researcher Access Program. Huan Zhang acknowledges the support from the AI2050 program at Schmidt Sciences (AI 2050 Early Career Fellowship).

## Appendix

## Appendix A ControlAgent: Future Outlook

In this section, we explore the future prospects of ControlAgent. We believe that ControlAgent represents a foundational initial step toward automated control system design using LLMs. Further research is necessary to expand its capabilities, enabling it to tackle more complex and realistic control challenges.

### A.1 Expansion to Nonlinear Systems and Advanced Control Strategies

The current scope of ControlAgent is limited to Linear Time-Invariant (LTI) systems and conventional control strategies, which, although widely used in many industrial applications, restrict its applicability to a subset of control problems. However, in real-world scenarios, many systems exhibit nonlinear behavior, time-varying dynamics, or other complexities that are not sufficiently captured by LTI models. Future research should aim to incorporate advanced control strategies, such as nonlinear control methods [Sastry, ] (e.g., Lyapunov control, sliding mode control, backstepping, etc.), as well as adaptive and robust control frameworks [Zhou and Doyle, ]. Expanding ControlAgent to handle these complex dynamics would significantly broaden its applicability to industries requiring sophisticated control solutions, such as robotics, aerospace, and automotive engineering. Additionally, leveraging the creative potential of LLMs could lead to innovative control strategies beyond the scope of traditional human-designed approaches [, Gómez-Rodríguez and Williams, ].

### A.2 Modular Integration of Different LLMs

The architecture of ControlAgent currently relies on a single base LLM for both central LLM agent and task-specific LLM agent. A promising research direction involves the modular integration of various LLMs based on their specific expertise. For example, specialized LLMs fine-tuned for mathematical reasoning, optimization, or control theory could be assigned to different roles within the overall framework of ControlAgent. This modular approach could leverage smaller, more focused models to handle niche aspects of control design. In addition, using open-source LLMs for non-critical tasks would reduce the reliance on proprietary models, making ControlAgent more accessible and adaptable.

### A.3 Extending the ControlEval Dataset for Comprehensive Validation

ControlEval includes various control tasks that predominantly feature LTI systems. Extending ControlEval to include more complex tasks, such as real-world control systems and hardware-in-the-loop simulations, would provide a more robust validation of ControlAgent’s capabilities. Additionally, including scenarios that test the robustness and adaptability of ControlAgent to external disturbances, model uncertainties, and unmodeled dynamics would further establish its practical utility and readiness for real-world deployment.

## Appendix B More Discussions on Related Work and Control Background

### B.1 More Related Work

##### Classic Control Design

PID controllers have been a cornerstone of control system design. The widespread adoption of PID controllers is attributed to their simplicity, robustness, and effectiveness in managing a wide range of dynamic systems. Theoretical advancements have focused on optimizing PID parameters to achieve a desired performance, with methods such as Ziegler-Nichols tuning rules [Ziegler and Nichols, ] providing a heuristic-based starting point for controller tuning. Over the years, a range of adaptive and robust PID tuning techniques have been proposed, extending the PID controller’s applicability to nonlinear, time-varying, and uncertain systems [Ang et al., , Åström and Murray, ].

Loop shaping is another powerful approach to control system design, rooted in frequency domain techniques and aimed at shaping the open-loop transfer function to achieve specific performance and robustness goals [Ogata, ]. The central idea behind loop shaping is to design controllers that provide sufficient bandwidth, disturbance rejection, and stability margins by directly manipulating the system’s frequency response. Loop shaping approaches use tools like Bode plots to tailor the system’s gain and phase characteristics [Doyle et al., ]. The importance of loop shaping is evident in its continued application across various industrial domains, including process control [Morari and Zafiriou, ], aerospace [Blight et al., ], and mechatronics [Ohnishi, ], showcasing its effectiveness in addressing real-world control challenges. Nevertheless, all the existing control design methods still heavily rely on the domain expertise and human intuition. ControlAgent makes an meaningful initial step towards automating the control system design by integrating LLM agents and human expert knowledge.

##### LLMs for Engineering Design

LLMs are increasingly being explored across various engineering domains due to their versatility and capacity for solving complex tasks. In the domain of electric grids, for instance, GridFM [Hamann et al., ] has been introduced as a foundation model capable of addressing a wide range of challenges, such as power flow estimation, grid expansion planning, and electricity price forecasting. Similarly, an agent-based framework proposed in [Jia et al., ] leverages techniques such as Chain-of-Thought (CoT) and Retrieval-Augmented Generation (RAG) to enhance LLMs’ ability to perform power system simulations using previously unseen tools.
In software engineering, LLM4SE [Hou et al., ] provides a comprehensive survey on the application of LLMs in this domain, showcasing their achievements so far while also identifying open challenges and promising future research directions. For materials science, models like MatBERT [Trewartha et al., ], a variant of the BERT architecture, and MatSciBERT [Gupta et al., ], trained on a vast corpus of materials science literature, have set new benchmarks in the field.
Moreover, Mechanical Design Agent (MDA) [Lu et al., ] demonstrates the use of LLMs for generating CAD models directly from text commands, highlighting advancements in automated design processes. In aviation, the RoBERT model, fine-tuned for domain-specific tasks, has achieved an impressive 82.8% accuracy in knowledge tasks [Nielsen et al., ], demonstrating the potential of LLMs in highly specialized fields.

##### LLM Agents

The existing research on LLM-based agents can be categorised into single-agent and multi-agent systems. The single-agent systems utilize a single LLM for various applications such as task planning [Ge et al., , Deng et al., ], API tool using [Schick et al., , Parisi et al., , Tang et al., ], web browsing [Nakano et al., , Deng et al., ], and reasoning [Yao et al., , Hao et al., , Xiang et al., , Yu et al., , Ouyang et al., ].
On the other hand, multi-agent systems such as Generative Agents [Park et al., ] simulates human behaviors by creating a town of 25 agents to study social understanding. CAMEL [Li et al., ] employs role-play techniques to study the behaviors and capabilities of a agents society. Some works explore the competitive multi-agent systems that involves agents debate, negotiate and competition to improve its performance in negotiation
skills, question-answering [Fu et al., , Du et al., , Chan et al., , Liang et al., ].
ChatDev [Qian et al., ] developed a chat-powered software development framework in which specialized agents driven by LLMs.

### B.2 More Background on Classic Control

Here we review a few control-theoretic concepts that are crucial for classic control design. A fundamental requirement in most control engineering applications is closed-loop stability [Goodwin et al., , Boyd and Barratt, ]. For an LTI system with a transfer function $G(s)$, it is considered to be stable if all poles of the transfer function (i.e., the roots of the denominator) have negative real parts. The closed-loop stability means that the closed-loop transfer function from the reference signal $r(t)$ to the output signal $y(t)$ has to be stable. In the control language, the sensitivity function and the complementary sensitivity function are both required to be stable. Mathematically, we require all the roots of $1+G(s)C(s)=0$ to have strictly negative real parts.

For a stable LTI system, the settling time $T_{s}$ is the time for the output to converge within $\pm 2\%$
of the steady-state value given that the input is a step function. Slightly different definitions are sometimes used, e.g. 5% or
1% settling times.
Since PIDtune uses the 2% settling time as default, we also adopt 2% settling time in our study.
The settling time is one main measure for the system speed of response.

For a stable LTI system, the phase margin is the amount of allowable
variation in the phase of the plant before the closed-loop becomes unstable, and the gain margin is the amount of allowable variation in the gain of the plant before
the closed-loop becomes unstable. As shown in Figure 4, phase margin can be determined from Bode plots. Phase margin is typically viewed as the most important robustness metric for classic control design.

## Appendix C More on Experimental Study

### C.1 More on the Experimental Setup

##### LLM-based Baselines.

We evaluate four LLM-based baseline approaches: zero-shot prompting, zero-shot Chain-of-Thought (CoT), few-shot, and few-shot CoT. For the few-shot baselines, we provide two demonstration examples tailored to the specific task type. For instance, in the case of first-order unstable system design, the few-shot setting includes two examples demonstrating successful controller designs for unstable first-order systems, along with the associated control design criteria. In the few-shot CoT setting, we further include detailed reasoning steps to illustrate the process of designing a successful controller for the given demonstration examples. A complete example of the few-shot CoT prompt is provided in Appendix E.2. All LLM-based baselines are implemented using GPT-4o, with model hyperparameter settings detailed in Table 5.

##### Control Toolbox-based Baseline.

We use the widely employed control design toolbox PIDtune as a baseline, which provides various settings for tuning PID controllers for linear and higher-order systems. To ensure a fair comparison, we incorporate control domain knowledge to specify appropriate inputs, such as phase margin and crossover frequency, to PIDtune, enabling it to achieve the desired control design criteria in a single step. Specifically, we use two distinct configurations to establish PIDtune as a baseline:
For first and second-order systems (both stable and unstable), PIDtune is configured with the desired phase margin and open-loop crossover frequency. The phase margin is directly derived from the task requirements, while the crossover frequency is determined as $C/T_{s}$, where $C\in[3,5]$ is a constant, and $T_{s}$ is the required settling time. For each trial, $C$ and $T_{s}$ are randomly sampled within their specified ranges to align with the design specifications.
For higher-order systems, the relationship between the crossover frequency and the settling time $T_{s}$ is not clear in general. As a result, only the phase margin requirement is supplied to PIDtune to optimize the PID gains.

##### Parameter Setup for ControlAgent.

In ControlAgent, the maximum number of iterations is configured based on the difficulty of the task. For relatively straightforward tasks, such as stable first-order and stable second-order systems, the maximum number of iterations is set to 10. For more challenging tasks, including first-order systems with delay, unstable first-order systems, and unstable second-order systems, the maximum iteration count is increased to 20. Finally, for the most difficult tasks, such as higher-order systems, the maximum number of iterations is set to 30 to allow for additional refinement and ensure that the desired control criteria are met.

##### LLM hyperparameters.

Table 5 presents the hyperparameter settings used for each LLM model in this study, including model versions, temperature settings, and maximum token limits.

**Table 5: Hyperparameter configurations for each LLM model used in this study.**
| Model | Hyperparameters |
| --- | --- |
| GPT-4o | model = gpt-4o-0806, temperature = 0, max_tokens = 1024 |
| GPT-4-turbo | model = gpt-4-turbo, temperature = 0, max_tokens = 1024 |
| GPT-3.5-turbo | model = gpt-3.5-turbo-0125, temperature = 0, max_tokens = 1024 |
| Claude-3.5 | model = claude-3-5-sonnet-20240620, temperature = 1, max_tokens = 1024 |
| Gemini Pro 1.5 | model = gemini-1.5-pro, temperature = 1, max_tokens = 8192 |

### C.2 Evaluation Metric

##### Average Successful Rate

Suppose for each control task, our evaluation dataset consists of $N$ sample systems and the associated predefined criteria, such as stability, phase margin, settling time. Let $S_{i,j}$ denote the outcome of the $j$-th trial for the $i$-th system, where $S_{i,j}=1$ if the design is successful and $S_{i,j}=0$ otherwise. The averaged successful rate for trial $j$ is computed as

$$ $\text{ASR}_{j}=\frac{1}{N}\sum_{i=1}^{N}S_{i,j},$ $$

and the overall ASR across all $T$ trials is given by

$$ $\text{ASR}=\frac{1}{T}\sum_{j=1}^{T}S_{j}.$ $$

This metric provides insight into the average performance of the controller design over multiple trials for each system, reflecting its consistency.

##### Aggregate Successful Rate

This metric evaluates success on a system-by-system basis, where a system is considered successfully designed if at least one of the $T$ independent trials results in a successful design. Specifically, the aggregated success for system $i$ is:

$$ $\text{AgSR}_{i}=\begin{cases}1&\text{if }\sum_{j=1}^{T}S_{i,j}>0,\\ 0&\text{otherwise }.\end{cases}$ (C.1) $$

The overall AgSR across all systems is then computed as

$$ $\text{AgSR}=\frac{1}{N}\sum_{i=1}^{N}\text{AgSR}_{i}.$ $$

This metric is generally higher than the ASR since it only requires one successful trial per system for the entire system to be considered a success. It reflects the best controller design for each system, providing a more lenient evaluation of the controller’s overall performance.

In the experimental study, for each control task, we have $N=50$ and we ran each control tasks for five trails ($T=5$) for both ControlAgent and baseline methods.

### C.3 More Experimental Results

#### C.3.1 More Results on AgSR

Table 6 shows the AgSR of ControlAgent and various baseline methods on the ControlEval benchmark. The best results for each task are highlighted in bold. Our key observations are given below.

##### ControlAgent consistently outperforms all baseline methods.

ControlAgent achieves significantly higher AgSR across all control tasks compared to both LLM-based and traditional toolbox-based baselines. This superior performance is evident not only for simpler first-order and second-order stable systems but also for more complex cases, such as unstable and higher-order systems. While PIDtune performs well for first-order and second-order stable systems, as well as first-order systems with time delay, it struggles in more challenging scenarios like first-order unstable, second-order unstable, and higher-order systems. In these cases, ControlAgent’s effectiveness becomes more apparent, especially as the complexity of the problem increases.

It is important to note that because of the inherent randomness in the answers generated by LLMs, individual runs of ControlAgent may yield different outcomes. However, when looking at aggregate results across multiple iterations, ControlAgent achieves 100% success across all design problems except for higher-order systems, where it still achieves an impressive 96%. While this falls short of 100%, it is a significantly better result than any other toolbox-based method and LLM-based baselines, and given the difficulty of higher-order system design, this accuracy is very promising.

**Table 6: AgSR (%) of baseline methods and ControlAgent.**
| System Type | 1st-ord stb | 2nd-ord stb | 1st-ord ustb | 2nd-ord ustb | w/ dly | Hgr-ord |  |  |  |  |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Response Mode | fast | moderate | slow | fast | moderate | slow | (-) | (-) | (-) | (-) |
| Zero-shot | 36.0 | 56.0 | 32.0 | 36.0 | 46.0 | 26.0 | 14.0 | 2.0 | 48.0 | 6.0 |
| Zero-shot CoT | 66.0 | 12.0 | 2.0 | 34.0 | 48.0 | 40.0 | 14.0 | 2.0 | 38.0 | 24.0 |
| Few-shot | 32.0 | 58.0 | 50.0 | 44.0 | 38.0 | 38.0 | 28.0 | 52.0 | 36.0 | 28.0 |
| Few-shot CoT | 36.0 | 66.0 | 68.0 | 26.0 | 40.0 | 60.0 | 18.0 | 62.0 | 60.0 | 36.0 |
| PIDtune | 94.0 | 100.0 | 100.0 | 98.0 | 100.0 | 100.0 | 68.0 | 42.0 | 100.0 | 50.0 |
| ControlAgent | 100.0 | 100.0 | 100.0 | 100.0 | 100.0 | 100.0 | 100.0 | 100.0 | 100.0 | 96.0 |

#### C.3.2 ASR vs AgSR

In Figure 7, we present the ASR and AgSR results for ControlAgent and other baseline methods across first-order and second-order stable systems. ControlAgent consistently outperforms all other methods in both ASR and AgSR metrics. While PIDTune delivers results comparable to ControlAgent in these cases, all other methods show significantly lower ASR values. However, their AgSR is noticeably higher than their ASR, which can be attributed to the inherent randomness in LLM-generated responses. This highlights the benefit of aggregate success, where the variability of LLM outputs improves performance over multiple iterations.

Figure: Figure 7: ASR and AgSR for different methods on first-order and second-order stable systems (averaged successful rate for three response speed types).
Refer to caption: x7.png

As we shift to more challenging unstable systems, Figure 8 further illustrates ControlAgent’s increasing effectiveness. In these cases, the performance of the other methods declines sharply compared to their results on stable systems, as the complexity of the control design increases. Interestingly, this is where the limitations of randomness in LLMs become evident, both ASR and AgSR remain low for other methods, as even multiple iterations fail to improve their performance meaningfully. In contrast, few-shot-cot outperforms PIDTune in these harder scenarios, showcasing the potential of in-context learning when dealing with complex control tasks.

Figure: Figure 8: ASR and AgSR for different methods on first-order and second-order unstable systems (averaged successful rate for three response speed types).
Refer to caption: x8.png

In Figure 9, we examine first-order systems with delay and higher-order systems. For the first-order systems with delay, the performance trends mirror those of stable systems, with ControlAgent and PIDtune maintaining their strong lead. However, for higher-order systems, the accuracy of all methods, except ControlAgent, drops significantly. Despite the increased complexity of higher-order systems, ControlAgent continues to demonstrate impressive performance, highlighting its ability to handle even the most difficult control design problems. This underscores ControlAgent’s robustness and adaptability, making it a clear leader among the tested methods.

Figure: Figure 9: ASR and AgSR for different methods on first-order with delay and higher order systems.
Refer to caption: x9.png

**Table 7: ASR (%) of baseline methods and ControlAgent on ControlEval. The best result for each task is highlighted in bold. The results demonstrate that the ControlAgent outperforms all other LLM-based and toolbox-based baseline methods across all categories.**
| System Type | 1st-ord stb | 2nd-ord stb | 1st-ord ustb | 2nd-ord ustb | w dly | Hgr-ord stb | Hgr-ord ustb |  |  |  |  |  |  |  |  |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Response Mode | fast | moderate | slow | fast | moderate | slow | fast | moderate | slow | fast | moderate | slow | (-) | (-) |  |
| 0-shot | 8.0 | 19.2 | 10.0 | 14.0 | 18.4 | 13.2 | 5.2 | 5.6 | 0.8 | 0.4 | 0.4 | 2.4 | 15.6 | 4.0 | 0.0 |
| 0-shot CoT | 26.8 | 3.2 | 0.4 | 12.4 | 18.8 | 12.0 | 4.4 | 6.4 | 2.8 | 0.8 | 0.0 | 0.4 | 8.8 | 16.0 | 0.0 |
| 2-shot | 12.4 | 19.6 | 15.6 | 12.0 | 12.4 | 15.2 | 14.0 | 26.8 | 0.4 | 29.2 | 4.0 | 0.8 | 11.6 | 18.4 | 5.6 |
| 2-shot CoT | 11.2 | 21.6 | 21.2 | 7.6 | 14.0 | 25.6 | 6.0 | 54.4 | 16.0 | 22.4 | 3.6 | 1.2 | 16.0 | 22.4 | 10.4 |
| PIDtune | 58.4 | 89.6 | 84.0 | 84.4 | 98.0 | 82.0 | 32.4 | 3.2 | 0.0 | 11.2 | 0.0 | 0.0 | 100.0 | 48.0 | 60.0 |
| ControlAgent | 100.0 | 100.0 | 100.0 | 100.0 | 98.8 | 90.8 | 97.2 | 98.0 | 90.8 | 96.8 | 90.8 | 94.8 | 99.6 | 72.0 | 61.6 |

### C.4 Gain Margin Consideration

It is also important to highlight that control design can be evaluated using various metrics, with settling time and phase margin being two of the key ones we used. In this section, we further explore the effectiveness of ControlAgent by evaluating another important robustness metric: gain margin. For this analysis, we focus on comparing the designs produced by ControlAgent and PIDtune, our two best-performing methods, both of which already satisfy the settling time and phase margin requirements. We then examine how well their designs perform in terms of gain margin.

Typically, a good control design should have a gain margin within $\pm 6$ dB to ensure robustness against model uncertainty. As shown in Table 8, ControlAgent consistently outperforms PIDtune across nearly all scenarios, with the only exception being the first-order system with time delay. Notably, when comparing Table 8 with Table 2, we observe an interesting trend: every ControlAgent design that meets the settling time and phase margin requirements also inherently satisfies the gain margin criterion. This is a crucial result, as gain margin is typically another requirement that control engineers strive to achieve for robust designs.

In contrast, PIDtune’s performance drops significantly when evaluated by gain margin, especially in more complex systems such as unstable and higher-order systems. This widening performance gap underscores ControlAgent’s superior ability not only to meet the basic design requirements but also to inherently balance robustness, making its designs more resilient to model uncertainties.

**Table 8: ASR of PIDtune and ControlAgent on ControlEval for various system types with gain margin as an extra requirement.**
| System Type | 1st-ord stb | 2nd-ord stb | 1st-ord ustb | 2nd-ord ustb | w/ dly | Hgr-ord |  |  |  |  |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Response Mode | fast | moderate | slow | fast | moderate | slow | (-) | (-) | (-) | (-) |
| PIDtune | 56.0 | 90.4 | 86.4 | 65.2 | 54.8 | 75.2 | 0.0 | 0.0 | 100.0 | 16.0 |
| ControlAgent | 100.0 | 100.0 | 100.0 | 100.0 | 98.8 | 90.8 | 97.2 | 96.8 | 97.2 | 82.0 |

### C.5 Evolution of ControlAgent Design

In this subsection, we analyze how ControlAgent’s performance evolves over iterations to achieve the desired design. Figure 10 illustrates the simplest case, where ControlAgent is tasked with controlling first-order stable systems. Initially, all three response modes experience substantial settling time errors. However, these errors decrease rapidly, particularly in the slow scenario, which is the easiest to manage. This is because a slower system response reduces sensitivity to phase margin violations, making it easier to meet performance requirements. The moderate scenario, however, requires a few additional iterations to reach the design objectives. As shown in the right plot of Figure 10, the fast scenario presents the most challenge, with a significant phase margin error early on. However, as the iterations progress, ControlAgent successfully reduces both the phase margin and settling time errors, demonstrating its ability to optimize system performance even in scenarios where there is a clear trade-off between performance and robustness.

Figure: Figure 10: The behavior of ControlAgent across iterations for first-order stable systems. The left figure shows the change in settling time error, while the right figure tracks the phase margin error, both improving over iterations.
Refer to caption: x10.png

For each scenario, the design requires that the settling time $T_{s}$ falls within a specified range, $T_{s}\in[T_{s_{\min}},T_{s_{\max}}]$, and that the phase margin $\phi$ meets or exceeds a minimum threshold, $\phi\geq\phi_{\min}$. During each iteration, if the settling time is within this range, the steady-state error is set to zero. Similarly, if the designed phase margin exceeds the required minimum, the phase margin error is set to zero. However, if the designed settling time $T_{s}$ exceeds $T_{s_{\max}}$, the steady-state error is computed as:

$$ $\text{Settling Time Error (\%)}=\frac{T_{s}-T_{s_{\max}}}{t_{s_{\max}}-T_{s_{ \min}}}\times 100$ $$

Conversely, if the settling time is below $T_{s_{\min}}$, the error is calculated as:

$$ $\text{Settling Time Error (\%)}=\frac{T_{s_{\min}}-T_{s}}{T_{s_{\max}}-T_{s_{ \min}}}\times 100$ $$

If the designed phase margin falls below $\phi_{\min}$, the phase margin error is determined as:

$$ $\text{Phase Margin Error (\%)}=\frac{\phi-\phi_{\min}}{\phi_{\min}}\times 100$ $$

Moving on to more complex systems, Figure 11 shows how ControlAgent’s performance evolves when dealing with first-order unstable systems. In this case, both steady-state and phase margin errors start out large but gradually decrease as the agent iterates. Since unstable systems are more difficult to design for, ControlAgent is given up to 20 iterations to find a solution. This extended process highlights the agent’s ability to progressively refine system performance and robustness, improving both settling time and phase margin simultaneously, even in more challenging environments.

Figure: Figure 11: The behavior of ControlAgent across iterations for first-order unstable systems. The left figure shows the change in settling time error, while the right figure tracks the phase margin error, both improving over iterations.
Refer to caption: x11.png

Figure: Figure 12: The behavior of ControlAgent across iterations for second-order stable systems. The left figure shows the change in settling time error, while the right figure tracks the phase margin error, both improving over iterations.
Refer to caption: x12.png

The complexity increases further when ControlAgent tackles second-order stable systems, as shown in Figure 12. In the fast scenario, while the agent reduces settling time error within the first four iterations, this comes at the cost of a temporary increase in phase margin error, reflecting the trade-off between performance and robustness. However, with additional refinement, ControlAgent manages to bring the phase margin back within acceptable limits while still maintaining system performance. A similar trend is seen in the moderate scenario. However, unlike with first-order stable systems, the slow scenario poses the greatest challenge for second-order systems.This is because slower dynamics, while generally making a system more stable, reduce the system’s responsiveness to control inputs. As a result, the system can become less robust over time, making it harder for the controller to maintain the required phase margin.

## Appendix D More Details on ControlEval

In this section, we present more details on the construction of ControlEval. We first discuss the dynamical models considered in ControlEval in Section D.1, then the associated performance criteria is discussed in Section D.2. Finally, we discuss the dataset construction in Section D.3.

### D.1 Dynamical System Models

This section provides a detailed overview of the various types of dynamical system models included in ControlEval, such as stable and unstable first-order systems, stable and unstable second-order systems, first-order systems with time delay, and higher-order systems. As mentioned in the main paper, a general transfer function for a dynamical system can be expressed as:

$$ $G(s)=\frac{Y(s)}{U(s)}=\frac{b_{m}s^{m}+b_{m-1}s^{m-1}+\cdots+b_{1}s+b_{0}}{a_ {n}s^{n}+a_{n-1}s^{n-1}+\cdots+a_{1}s+a_{0}},$ (D.1) $$

where $Y(s)$ and $U(s)$ are output and input, $s$ is the complex frequency variable in Laplace domain. The system is considered stable if all roots of the characteristic equation $U(s)=0$ have negative real parts. Depending on the form of $U(s)$ and $Y(s)$, we classify the dynamical system models as follows:

##### First-order systems.

A first-order system is characterized by a first-order polynomial in $s$ for $U(s)$. The corresponding transfer function is
$G(s)=\frac{K}{\tau s+1}$,
where $K$ is a constant gain, and $\tau$ is the time constant of the first-order system.

##### Second-order systems.

Stable second-order systems can be expressed as:

$$ $G(s)=\frac{a}{s^{2}+2\zeta\omega_{n}s+\omega_{n}^{2}},$ (D.2) $$

where $\omega_{n}$ is the natural frequency and $\zeta$ is the damping ratio.

##### First-order systems with time delay.

First-order systems with time delay incorporate a delay parameter
$\theta$ into the transfer function:

$$ $G(s)=\frac{Ke^{-\theta s}}{\tau s+1},$ $$

where $\theta>0$ is the time delay parameter, $K$ is the system gain, and $\tau$ is the system time constant. The presence of $e^{-\theta s}$
in the numerator introduces phase lag, which can significantly impact the system’s stability and response.

##### Higher-order system.

Higher-order systems refer to systems where the order of $U(s)$ is three or greater. Higher-order systems can exhibit more complex dynamics, such as multiple resonant peaks or oscillatory behavior, making their stability analysis and control design more challenging.

### D.2 Performance Criteria

In linear control system design, key performance criteria include stability, phase margin, and settling time, which are essential for ensuring both the functionality and robustness of the system.

Stability is a fundamental requirement in control systems. Formally, as discussed above, a LTI system is stable if all the poles of its transfer function lie in the left half of the complex s-plane, meaning their real parts are negative. If any pole has a real part greater than or equal to zero, the system is either marginally stable or unstable. Stability ensures that the system’s output will return to its equilibrium state after a disturbance, without unbounded oscillations or divergence.

Phase margin $\phi_{m}$ is a measure of how close a system is to instability. It is defined as the difference between the phase angle of the system’s open-loop transfer function $L(j\omega)=G(j\omega)C(j\omega)$ and $-180^{\circ}$ at the gain crossover frequency $\omega_{gc}$ , which is the frequency where the magnitude of the open-loop transfer function is equal to 1 (or 0 dB). Formally, the phase margin PM is given by:

$$ $\text{PM}=180^{\circ}+\arg(L(j\omega_{gc})).$ (D.3) $$

A positive phase margin indicates a stable system, with typical design criteria recommending phase margins between $45^{\circ}$ and $90^{\circ}$ for adequate robustness. Phase margin provides insight into how much additional phase lag the system can tolerate before becoming unstable.

Settling time $T_{s}$ is a critical metric for evaluating the transient response of a control system. It is defined as the time required for the system’s output to remain within a specified percentage (typically 2% or 5%) of its final steady-state value following a step input. Depending on the specific dynamical system, the required settling time can vary significantly—ranging from fast to slow responses—based on factors such as system type, stability requirements, and the presence of unmodeled dynamics. To account for these variations, we consider three distinct response modes for stable first-order and second-order systems in ControlEval.

### D.3 ControlEval Generation Details

In this section, we explain the details on the construction of ControlEval.

#### D.3.1 Requirements for different type of dynamical models.

First-order Stable Systems For first-order stable systems, we sample $K\sim\mathcal{U}(0.005,200)$, i.e., we uniform sample $K$ from range $[0.005,200]$, and $\tau\sim\mathcal{U}(0.05,10)$. In addition, we require the settling time to be within some range $T_{s}\in[t_{\min},t_{\max}]$ for three different response modes: fast, moderate, and slow relative to the time constant $\tau$:

- •
Fast mode: We have $t_{\min}\sim\mathcal{U}(0,0.001\tau)$ and $t_{\max}\sim\mathcal{U}(0.3\tau,0.5\tau)$.
- •
Moderate mode: We have $t_{\min}\sim\mathcal{U}(0.1\tau,0.5\tau)$ and $t_{\max}\sim\mathcal{U}(\tau,5\tau)$.
- •
Slow mode: We have $t_{\min}\sim\mathcal{U}(5\tau,10\tau)$ and $t_{\max}\sim\mathcal{U}(20\tau,30\tau)$.

The minimum required phase margin is also randomly seleted by $\phi_{m}\in[45,90]$.

Second-Order Stable Systems.
For second-order stable systems, we sample $\zeta\sim\mathcal{U}(0.1,0.99)$ to consider underdamped second-order system, $\omega_{n}\sim\mathcal{U}(0.1,5)$, and $a\sim\mathcal{U}(0.1,20)$. In addition, we require the settling time to be within some range $T_{s}\in[t_{\min},t_{\max}]$ for three different response modes: fast, moderate, and slow relative to the time constant $\tau\approx\frac{4}{\zeta\omega_{n}}$:

- •
Fast mode: We have $t_{\min}\sim\mathcal{U}(0,0.005\tau)$ and $t_{\max}\sim\mathcal{U}(\tau,1.5\tau)$.
- •
Moderate mode: We have $t_{\min}\sim\mathcal{U}(2\tau,2.5\tau)$ and $t_{\max}\sim\mathcal{U}(3\tau,4\tau)$.
- •
Slow mode: We have $t_{\min}\sim\mathcal{U}(4\tau,5\tau)$ and $t_{\max}\sim\mathcal{U}(6\tau,10\tau)$.

The minimum required phase margin is also randomly seleted by $\phi_{m}\in[45,65]$.

Second-Order Unstable Systems.
For the second-order unstable systems, half of the dataset is generated using the following transfer function structure:

$$ $G(s)=\frac{a}{s^{2}-2\zeta\omega_{n}s+\omega_{n}^{2}},$ (D.4) $$

where the damping ratio $\zeta$ is sampled from a uniform distribution $\zeta\sim\mathcal{U}(0.1,0.99)$, ensuring the system has two unstable poles. The natural frequency $\omega_{n}$ is sampled from $\omega_{n}\sim\mathcal{U}(0.1,5)$, and the gain $a$ is drawn from $a\sim\mathcal{U}(0.1,20)$. Additionally, the settling time $T_{s}$ is constrained to lie within the range $T_{s}\in[t_{\min},t_{\max}]$, where $t_{\min}\sim\mathcal{U}(0,0.05\tau)$ and $t_{\max}\sim\mathcal{U}(\tau,1.5\tau)$, with the time constant $\tau\approx\frac{4}{\zeta\omega_{n}}$. The minimum required phase margin $\phi_{m}$ is randomly selected from $\phi_{m}\sim\mathcal{U}(45,65)^{\circ}$.

The second half of the dataset is designed using the following transfer function structure:

$$ $G(s)=\frac{a}{(\tau_{1}s+1)(\tau_{2}s+1)},$ (D.5) $$

where the gain $a$ is sampled from $a\sim\mathcal{U}(-2000,-0.00025)$, and the time constants $\tau_{1}$ and $\tau_{2}$ are drawn from $\tau_{1}\sim\mathcal{U}(0.05,10)$ and $\tau_{2}\sim\mathcal{U}(-10,-0.05)$, respectively. The time constant $\tau$ is approximated as $\tau\approx 3\min\{\tau_{1},|\tau_{2}|\}$. As with the first half of the dataset, the settling time $T_{s}$ is required to be within the range $T_{s}\in[t_{\min},t_{\max}]$, with $t_{\min}\sim\mathcal{U}(0,0.05\tau)$ and $t_{\max}\sim\mathcal{U}(\tau,1.5\tau)$.

The reason for using these two different structures is to ensure that half of the dataset consists of systems with one unstable pole, while the other half contains systems with two unstable poles, providing a balanced variety of unstable system dynamics.

First-Order Systems with Time Delay.
For first-order system with a time delay $\theta$, we choose the delay parameter randomly as $\theta\sim\mathcal{U}(\theta_{\min},\theta_{\max})$, where $\theta_{\min}=0.1\tau$
and $\theta_{\max}=0.2\tau$. For the settling time requirements, we require $T_{s}\in[t_{\min},t_{\max}]$ with $t_{\min}\sim\mathcal{U}(4\tau,5\tau)$ and $t_{\max}\sim\mathcal{U}(40\tau,50\tau)$. The minimum required phase margin is also randomly selected by $\phi_{m}\in[45,65]$.

##### Higher-order Systems.

For higher-order systems, there is no standardized method to automatically generate both the dynamical system and its corresponding performance requirements simultaneously. To address this, we have manually designed 50 higher-order systems along with their performance criteria, ensuring that the specified requirements are indeed achievable. Among these samples, 25 are stable higher-order systems, while the remaining 25 are unstable. Based on feedback from human experts, designing a controller for higher-order systems is challenging, requires multiple rounds of parameter tuning even for human. Nevertheless, these higher-order tasks present unique challenges for ControlAgent, and our results demonstrate promising performance in addressing these complex scenarios.

#### D.3.2 Sample code for generating ControlEval

The following is a sample code snap for generating first-order systems:

The following is a sample code snap for generating second-order unstable systems:

## Appendix E Prompt Design

### E.1 Full Prompts for ControlAgent

In this section, we provide the full prompt for ControlAgent, including the prompt for central agent to distribute the control tasks and a sample prompt for the task-specific agent for designing controllers of first-order stable system.

In the above, we have provide a guideline to design a loop-shaping controller for the first-order stable systems along with the parameter tuning instructions (highlighted in purple) to help LLM agent perform tuning task.

### E.2 Full Prompts for Baselines

In this section, we present the full prompt used to measure baseline approaches. We evaluate the designed controller by requesting specific output format so that we can extract the controller parameters.

Zero-shot prompt is almost identical to the zero-shot CoT without asking the LLM to perform the design process step by step explicitly.

Few-shot prompt is almost identical to the few-shot CoT without detailed reasoning steps and asking the LLM to perform the design process step by step explicitly.

## Appendix F A demo of the design process

In this section, we present a step-by-step demo of the ControlAgent design process for an illustrative control task. The goal is to design a controller for a given dynamical system that satisfies specific performance requirements, including settling time and phase margin.
The design process begins by providing ControlAgent with the initial system models and desired performance criteria. The central agent first performs high-level task analysis and assign the task to a task-specific LLM agent, who then iteratively refines its controller design. At each iteration, ControlAgent evaluates the proposed design against the desired criteria and, if necessary, adjusts the controller parameters based on the observed performance. The iterative refinement continues until a design that meets all requirements is achieved or the maximum iteration number is achieved. Table 9 shows a breakdown of LLM agents in ControlAgent.

**Table 9: Overview of the LLM agents and their roles in ControlAgent.**
| LLM Agents | Role |
| --- | --- |
| Central Agent | High-level task analysis and task distribution |
| Task-Specific Agent 1 | Controller design for first-order stable system |
| Task-Specific Agent 2 | Controller design for first-order unstable system |
| Task-Specific Agent 3 | Controller design for second-order stable system |
| Task-Specific Agent 4 | Controller design for second-order unstable system |
| Task-Specific Agent 5 | Controller design for first-order system with time delay |
| Task-Specific Agent 6 | Controller design for higher-order system |

In the outputs of the central agent, one can see that the central agent is able to perform an accurate high-level task analysis and assign the task to the corresponding task-specific agent accurately.

In the first iteration, Task-specific agent 1 is able to follow the design instruction and come up with a reasonable initial controller.

For iteration 2, the agent is able to identifying the issues in the previous design and come up with a correct tuning direction, i.e., increasing $\omega_{L}$ to reduce the settling time.

The agent further increases $\omega_{L}$ to reduce the settling time. Additionally, upon evaluating the previous design, the agent observes that it adequately satisfies the phase margin. Consequently, it can fine-tune $\beta_{b}$ to maintain an optimal balance between system performance and robustness. After iteration 3, the task-specific agent produces a successful controller design, which is verified by the Python computation agent. The final controller is returned to the user as the output of ControlAgent.

## Peer Reviews

confidence: 4
contribution: 3
initial_rating: 6
presentation: 4
questions: - How does ControlAgent handle model uncertainty? While you discuss robustness through phase margin, could you elaborate on whether the framework considers parametric uncertainties or unmodeled dynamics?
- For higher-order systems, you mention manual design of 50 cases. Could you explain your methodology for ensuring these cases are representative and unbiased? What criteria guided your selection?
- For the history and feedback module, how do you handle the context window limitations of LLMs? Could you provide more details about the memory management strategy?
- Could you provide a more detailed analysis of failure cases, particularly for higher-order systems where performance was lower? Understanding these cases would help assess the framework's limitations.
soundness: 2
strengths: The core strength of this paper lies in how it successfully addresses the fundamental performance-robustness trade-offs inherent in classical control theory. The framework intelligently uses loop-shaping and PID tuning methodologies, employing settling time and phase margin as key tuning parameters - a sophisticated approach that mirrors established control engineering practices. The iterative design process is noteworthy for its theoretical soundness. Rather than treating controller design as a single-shot optimization problem, ControlAgent mimics the systematic approach used by human experts, progressively refining controller parameters while managing the complex interplay between performance metrics. The empirical results validate this approach, showing success across various system types and complexity levels, with particularly impressive results in handling unstable and higher-order systems. The framework's ability to achieve 100% success rates for first-order and stable second-order systems, while maintaining high performance even for complex higher-order and unstable systems, demonstrates its robust theoretical foundation and practical effectiveness.
summary: This paper introduces ControlAgent, a framework that automates control system design by integrating large language model (LLM) agents with domain expertise. The framework uses multiple collaborative agents to emulate human iterative design processes, gradually tuning controller parameters to meet user-specified requirements for stability, performance, and robustness. ControlAgent consists of a central agent that analyzes tasks and distributes them to specialized agents, task-specific agents that handle detailed controller design for different system types, a Python computation agent that performs control calculations and evaluations, and a history and feedback module that enables iterative refinement of designs. The system addresses the inherent complexity of control design by breaking down the process into manageable steps and incorporating domain knowledge into the decision-making process. The authors also develop ControlEval, an evaluation benchmark comprising 500 control tasks across various system types including first-order, second-order, systems with delay, and higher-order systems, with different response modes and specific performance criteria. This benchmark serves as a standardized way to evaluate control design workflows.
weaknesses: - The evaluation methodology raises several concerns. While ControlEval includes 500 control tasks, the paper doesn't clearly justify the distribution of these tasks or demonstrate their representativeness of real-world control problems. The generation process for higher-order systems is particularly problematic - the authors admit to manually designing these cases, which could introduce bias and may not reflect the true complexity of higher-order system control.
- The comparison with baselines is somewhat limited. The paper primarily compares against relatively simple LLM-based approaches (zero-shot, few-shot) and a single traditional tool (PIDtune). Modern control design often employs more complex methods like robust control, model predictive control, or optimization-based approaches, which are notably absent from the comparison. The performance metrics are also relatively basic, focusing mainly on settling time and phase margin while overlooking other important characteristics like disturbance rejection and noise sensitivity.
- The iterative design process lacks theoretical guarantees of convergence or optimality. The paper doesn't provide analysis of when or why the iteration process might fail, nor does it establish bounds on the number of iterations needed for convergence. 
- The framework's heavy reliance on proprietary LLM models raises questions about reproducibility and practical deployment. The authors don't thoroughly explore how the system's performance might vary with different base LLMs or how it might degrade with smaller, more practical models.

---

confidence: 3
contribution: 2
initial_rating: 5
presentation: 2
questions: As mentioned above, I suggest the authors improve their academic writing skills and design specific application scenarios, such as robotics and transportation, to verify their framework.

I recommend several papers, as shown below, in which authors can learn how to improve academic writing skills and organize corresponding ideas from them.

1) Yang, Q., & Parasuraman, R. Bayesian strategy networks based soft actor-critic learning. ACM Transactions on Intelligent Systems and Technology (TIST).

2) H. Hamann and H. Wo ̈rn, “A framework of space–time continuous models for algorithm design in swarm robotics,” Swarm Intelligence, vol. 2, no. 2-4, pp. 209–239, 2008.
soundness: 2
strengths: This paper proposes a new paradigm that automates control system design via novel integration of LLM agents and control-oriented domain expertise to bridge the the complexity and specificity in control system design.
summary: This paper introduces a new paradigm that automates control system design via novel integration of LLM agents and control-oriented domain expertise. However, the writing style is confusing, making it hard to follow their ideas. I suggest the authors improve their academic writing skills by making the abstract more precise and brief, adding the approach section, and reorganizing the corresponding method section. Moreover, I do not know what scenarios the authors implemented or simulated for the experiments. There is no background information or introduction. Generally, this paper needs to improve largely.
weaknesses: The paper's writing style is confusing, making it hard to follow their ideas. I suggest the authors improve their academic writing skills by making the abstract more precise and brief, adding the approach section, and reorganizing the corresponding method section. Moreover, I do not know what scenarios the authors implemented or simulated for the experiments. There is no background information or introduction. Generally, this paper needs to improve largely.

---

confidence: 3
contribution: 1
initial_rating: 3
presentation: 2
questions: How much sampling is done of LLM-generated designs? e.g. is the budget 10 designs?
soundness: 1
strengths: This paper addresses the issue of designing controllers using LLMs, in particular with specific stability, phase margin, and settling times. 

The overall system runs in a loop where a the designed controller is run and the system provides feedback based on a history of designs and how well they performed.
summary: This paper describes a composite LLM-based system for control tasks which attempts to design controllers, represented as Python code, for control problems with specific requirements, namely stability, phase margin, and settling time. 

While this paper is decently presented and seems to achieve decent results, I am uncertain about recommending it for ICLR. Primarily, the paper seems highly domain-specific and engineering-focused, rather than more general cutting-edge academic research. Still, it is a good engineering system. Secondly, I am uncertain about the evaluation. 

The proposed method is essentially a domain-specific application of LLM-modulo, e.g. an interative prompt with a verifier and critiques [1].

[1] Kambhampati, S., Valmeekam, K., Guan, L., Verma, M., Stechly, K., Bhambri, S., ... & Murthy, A. B. Position: LLMs Can’t Plan, But Can Help Planning in LLM-Modulo Frameworks. In Forty-first International Conference on Machine Learning.
weaknesses: It seems guarantees would be desirable when working with control systems, and I assume the problem requirements are meant to be guarantees. However, I feel the paper would be made a lot stronger by discussing guarantees at length. 

The evaluation methods seem like they could be improved, in particular I would like the authors to clarify about "a system is considered successfully designed if at least one of the multiple independent trials results in a successful design". It seems this would greatly skew the statistics, since failures are being filtered out. I also don't see reporting of how many samples are taken to achieve the reported success rates. 

Given the unpredictable and error-prone nature of LLMs, I am skeptical that the overall system can work without a human in the loop or method for filtering correct answers. Also, it seems like intermediate mistakes in generation (e.g. a hallucinated constant) would collapse the entire system, so I would expect it to be rather fragile. To the extent that the proposed method works, I am curious what the authors attribute it to?

While the method is interesting, it seems to be an incomplete solution to a highly domain-specific problem, so I'm unsure about the larger impact of the work, e.g. the paper doesn't give much insight into designing general LLM-based systems.

Meta-review: This paper's core strength is its demonstration that LLMs can be used to design controllers for a wide variety of different systems with specific stability, phase margin, and settling times. The system, ControlAgent, runs in a loop where the LLM designed controller is run and the system provides feedback based on the performance of a set of designs. The paper convincingly demonstrates that LLMs can be used for this purpose, and ControlAgent excels across many different control settings with high success rates even when the dynamics are complex and unstable. Designing controllers with machine learning models is a highly relevant application area to ICLR, and knowing that LLMs can do this effectively is a valuable contribution.

However, the main weakness, although not pointed out by reviewers, is the lack of contextualization of ControlAgent in the exceptionally large literature on using machine learning for control problems. There is no section in the related work that addresses the very well researched area on machine learning control (see https://faculty.washington.edu/sbrunton/mlcbook/CH02_MLC.pdf for an introduction). There is similarly no comparison to a baseline which uses a machine learning model *other* than an LLM for controller design. 

Without grounding in this literature, the relevant sub-community at ICLR will not engage with this paper. There is similarly no discussion of what the benefits of an LLM over an alternative ML model are for controller design, which would be very valuable for making the paper more impactful. As a result, this paper cannot be accepted in its current form. Fixing the contextualization with respect to the ML for control community for a future version of the paper will make the paper significantly stronger.

Decision: Reject