EngiAgent: Feasibility-First Engineering Agent System
- EngiAgent is a feasibility-first multi-agent system that structures engineering problem solving into five specialized modules to ensure real-world constraints are met.
- It features a Fully Connected Coordinator that adaptively routes feedback among Analyzer, Modeler, Verifier, Solver, and Evaluator to correct nonlocal failures.
- Benchmark results across 53 diverse engineering tasks demonstrate a significant improvement in feasible solution rates compared to zero-shot prompting and prior baselines.
Searching arXiv for the specified paper and closely related agentic engineering systems. EngiAgent is a multi-agent system for open-ended engineering problem solving whose central objective is feasibility: solutions must satisfy real engineering constraints rather than merely appear mathematically plausible or produce runnable code. The framework decomposes engineering work into five specialized agents—Analyzer, Modeler, Verifier, Solver, and Evaluator—and coordinates them through a Fully Connected Coordinator that can route feedback between any pair of modules. This architecture is designed for settings in which failures may originate in information extraction, constraint interpretation, model formulation, solver execution, or final assessment, and where late-stage errors often require correction at a nonadjacent upstream stage. In the reported benchmark of 53 engineering problems across four domains, EngiAgent substantially improves feasible solution rates over zero-shot prompting and prior agent baselines, and is presented as a feasibility-first approach to LLM-driven engineering reasoning (Zhou et al., 4 May 2026).
1. Feasibility as the organizing principle
EngiAgent is motivated by a distinction between mathematical problem solving and engineering problem solving. In the latter, the task is not to solve a predefined formulation but to derive a formulation that remains valid under data, physical, operational, and procedural constraints. The paper treats this as an open-ended process requiring analysis, modeling, verification, solving, and post hoc evaluation, with iterative revision when any stage produces an infeasible intermediate artifact (Zhou et al., 4 May 2026).
Within this framing, a common misconception is that logically coherent text, executable optimization code, or a numerical answer is already evidence of engineering success. EngiAgent rejects that equivalence. The paper explicitly defines a solution as feasible only if it satisfies all mandatory engineering constraints required for execution in real systems, including data consistency, physical requirements, safety limits, and procedural rules. This criterion is stricter than ordinary answer correctness and is the main reason the framework emphasizes verification and targeted feedback routing rather than one-pass generation (Zhou et al., 4 May 2026).
The paper also identifies characteristic failure modes of prior LLM systems in engineering settings: fancy but vague modeling, altering key data, violating physical laws, and over-constraining the model. These errors are important because they can produce outputs that look sophisticated while remaining unusable. A plausible implication is that engineering-oriented agents need internal structures that are closer to engineering workflows than to generic conversational reasoning.
2. Five-agent decomposition of the engineering workflow
EngiAgent follows a standard engineering workflow but distributes it across five specialized agents under a shared coordinator. The specialization is intended to reduce error propagation and to permit targeted correction when failures occur at different semantic levels of the task (Zhou et al., 4 May 2026).
| Agent | Primary function | Main checks or outputs |
|---|---|---|
| Analyzer | Converts natural-language problems into a structured modeling blueprint | Decision variables, parameters, constraints, objectives, engineering rules, uncertainty, trade-offs |
| Modeler | Converts the structured problem into executable optimization code | Pyomo-oriented formulation, variable/index definitions, constraint encoding |
| Verifier | Performs strict semantic and consistency checking | Semantic consistency, constraint completeness, data consistency |
| Solver | Executes the generated model and manages backend selection | Valid results vs. execution failures, actionable error reports |
| Evaluator | Assesses the complete solution package | Result feasibility, model-problem alignment, engineering validity, overall quality |
The Analyzer is the entry point. It does not merely parse text; it converts the natural-language problem into a hierarchical JSON modeling blueprint and may infer missing but necessary engineering structure. Its output includes decision variables, parameters, objectives, constraints, implicit engineering rules, uncertainty sources, and trade-offs. The Modeler then translates that blueprint into executable optimization code, mainly in Pyomo for the main benchmark. The paper emphasizes domain-specific modeling patterns intended to reduce wrong variable definitions, index mismatches, improper constraint encoding, and mismatches between problem type and solver formulation (Zhou et al., 4 May 2026).
The Verifier is a strict checker for semantic consistency, constraint completeness, and data consistency, but it is also designed not to reject functionally equivalent reformulations merely because they differ in surface representation. The Solver distinguishes valid optimization results from execution failures and returns actionable error information. The Evaluator operates on the full package—problem description, modeling analysis, code, and computed results—and can decide whether the workflow should restart or terminate (Zhou et al., 4 May 2026).
3. Fully connected coordination and adaptive feedback routing
The defining systems contribution of EngiAgent is the Fully Connected Coordinator. Unlike rigid reflection pipelines of the form analyze → model → solve → reflect, this coordinator can route information and error reports between any pair of agents. The paper’s argument is that engineering failures are often diagnosed late but originate earlier, so corrective action must target the responsible stage rather than simply step backward one module at a time (Zhou et al., 4 May 2026).
The coordinator performs four linked functions: it diagnoses the failure type, identifies the most appropriate destination agent, routes the report, and updates shared memory with debugging history. This is paired with state-aware memory, which tracks access count per agent, success rate per agent, debug records, solution history, error type plus agent, successful analysis/model/solution cases, and fix strategy plus result. These records are used to guide future routing decisions and to avoid repeating unproductive repair paths (Zhou et al., 4 May 2026).
A second mechanism is forced agent switching. If repetitive failures persist, the coordinator can force the task away from the same reasoning path and into another agent or stage better suited to the issue. The paper presents this as a guard against infinite debugging loops. It also reports that replacing the fully connected coordinator with a fixed pipeline reduces both numerical output rate and feasible solution rate, with average drops of more than 10% across models, while removing forced switching has only a minor effect on quality but increases unnecessary retries and overhead (Zhou et al., 4 May 2026).
This routing logic is especially relevant for heterogeneous failure cases. A data-extraction mismatch detected by the Verifier may need to return to the Analyzer; malformed optimization code may need Modeler repair; solver failures arising from structural nonlinearity may require reformulation rather than syntax correction. EngiAgent’s coordinator is designed precisely for these nonlocal dependencies.
4. Modeling blueprint, verification rules, and formal constraints
The Analyzer’s output is organized as a hierarchical blueprint with three core components: modeling_context, core_model_elements, and extended_analysis_and_robustness. The core_model_elements include decision variables, parameters, objective function, and constraints. The extended_analysis_and_robustness component contains key assumptions, uncertainty sources, trade-off analysis, and sensitivity factors. The paper also states four internal reasoning dimensions that guide the Analyzer’s prompt: Information Extraction, Domain-specific Reasoning, Multi-objective Decision-making, and Uncertainty Handling (Zhou et al., 4 May 2026).
The framework imposes several “Golden Command and Final Verification” rules. Every numerical value in the original problem must appear in the parameters list; internal references must be traceable; core_model_elements must be independently solvable; assumptions and uncertainty must not be mixed into the core model; and all mathematical expressions must be standard and parseable for code generation. These rules are intended to prevent two common failure patterns in LLM-based engineering workflows: silent data mutation and contamination of executable models with discursive reasoning (Zhou et al., 4 May 2026).
The paper provides a power scheduling example to illustrate how feasibility is encoded as explicit constraints rather than informal engineering intuition. Representative constraints include hourly power balance,
wind availability,
and storage dynamics with bounds,
The example also includes generator block limits, ramping limits, and storage charge/discharge exclusivity with binary variables. The paper uses this case to argue that feasibility requires strict satisfaction of conservation laws and device capability limits, not merely a “reasonable-looking” model (Zhou et al., 4 May 2026).
5. Benchmark, metrics, and empirical performance
EngiAgent is evaluated on a benchmark of 53 high-quality engineering problems across four domains: Market and Multi-Agent Decision-Making, Scheduling and Resource Allocation, Planning and Design, and Control and Autonomous System Modeling. The benchmark rewrites problems from peer-reviewed sources into self-contained open-ended tasks with background context, numerical data, and explicit engineering constraints. Evaluation uses five dimensions: IE, DR, MO, UH, and Feasibility, with feasibility as the principal metric. Feasibility is verified by executable numerical and constraint checks, with final confirmation by human experts rather than LLM scoring (Zhou et al., 4 May 2026).
| LLM backend | Best baseline feasible rate | EngiAgent feasible rate |
|---|---|---|
| GPT-4o | 7.55% | 64.15% |
| Gemini-2.5 Flash | 3.77% | 50.94% |
| DeepSeek-V3-671B | 28.30% | 75.47% |
The numerical solution rate is also reported. For EngiAgent, those rates are 66.04% on GPT-4o, 52.83% on Gemini-2.5 Flash, and 79.25% on DeepSeek-V3-671B. The most notable result is the reduction of the gap between “numerical output” and “feasible output.” On GPT-4o, DS-Agent produces 62.26% numerical solutions but only 5.66% feasible ones, whereas EngiAgent produces 66.04% numerical and 64.15% feasible. The paper describes the overall result as roughly a seven-fold average improvement in feasibility over prior SOTA methods (Zhou et al., 4 May 2026).
The ablation study isolates the contribution of four components: prompt engineering, the Verifier, the fully connected coordinator, and forced switching. Removing prompt engineering weakens information extraction and modeling guidance; removing the Verifier increases data inconsistencies and omitted constraints; removing the fully connected coordinator degrades routing quality, numerical output, and feasibility; and removing forced switching mainly increases overhead. The case studies reinforce the benchmark findings. In a market-based power allocation problem, EngiAgent produces scenario-aware allocation, balance satisfaction, objective optimization, and concrete allocations for supply and demand units. In a rooftop PV layout optimization problem, it derives an executable MILP and returns a feasible design including configuration choice, panel counts, installed capacity, annual energy yield, and total Capex (Zhou et al., 4 May 2026).
6. Position within agentic engineering research, limitations, and future directions
EngiAgent occupies a specific position within a broader landscape of engineering-oriented agent systems. Its focus is open-ended engineering feasibility, not general software engineering, scientific simulation authoring, or workflow benchmarking. Contemporaneous systems illustrate adjacent emphases: EngiAI uses a supervisor architecture with seven specialized agents for topology optimization, document retrieval, HPC orchestration, and 3D printer control, alongside a benchmark stressing workflow execution, RAG, and SLURM-based long-horizon orchestration (Molinari et al., 19 May 2026); MOOSEnger is a domain-specific agent for MOOSE input-file generation and repair that combines retrieval, HIT-aware parsing, semantic validation, and execution-backed correction (Li et al., 5 Mar 2026); and AgentStepper provides an interactive debugger for software development agents by exposing trajectories as structured conversations with breakpoints, stepwise execution, live editing, and repository-level diff visualization (Hutter et al., 6 Feb 2026). This suggests a broader shift toward tool-grounded, domain-structured, and verification-heavy agent designs.
EngiAgent’s scope is narrower than those systems in some respects and broader in others. It is narrower because it is benchmarked primarily on feasibility-centered optimization and modeling tasks, with a Pyomo-centered implementation in many experiments. It is broader because it targets the upstream problem of translating open-ended engineering descriptions into validated mathematical models before execution. A common misunderstanding would be to read it as a general-purpose design assistant; the paper instead positions it as a system for feasibility-oriented engineering problem solving under explicit constraints (Zhou et al., 4 May 2026).
The paper also states clear limitations. The benchmark remains relatively small at 53 tasks across four domains. The emphasis on feasibility is appropriate for engineering but does not fully capture model elegance or theoretical optimality. The framework inherits the reasoning and generalization limits of the underlying LLMs. The implementation is Pyomo-centered for many experiments, and the fully connected coordinator introduces additional computation relative to zero-shot or simpler baselines. Future directions named in the paper include broader engineering domains, PDE-based simulation, stochastic system modeling, hybrid data-physics applications, more tool-agnostic workflows, and stronger safety and human oversight (Zhou et al., 4 May 2026).
Taken together, EngiAgent is best understood as a feasibility-first engineering agent architecture in which analysis, modeling, verification, solving, and evaluation are decoupled, but not linearly chained. Its distinctive claim is that engineering reliability depends less on a stronger single reasoning loop than on the ability to detect failure modes at the right abstraction level and route repairs to the correct specialist before infeasible intermediate assumptions harden into final outputs.