PDE-Agent: Automated PDE Solving

• PDE-Agent is a multi-agent framework for fully automated PDE solving, leveraging LLM reasoning and tool invocation for end-to-end autonomy.
• It employs a dual-loop Prog-Act architecture that integrates planning, localized error correction, and global replanning to robustly solve complex PDE problems.
• The system uses a dynamically updated graph memory and centralized resource-pool to manage tool dependencies and runtime data for efficient problem resolution.

PDE-Agent is a toolchain-augmented, multi-agent framework for automated partial differential equation (PDE) solving, architected to leverage the reasoning capabilities of LLMs and the controllability of external tools. It operationalizes PDE solving as a series of tool invocations coordinated by collaborating LLM-driven agents, enabling fully automated workflows driven from natural language PDE descriptions. This paradigm is designed to overcome the limitations of existing neural PDE solvers—such as PINNs and DeepXDE—that still demand expert input for configuration, by realizing end-to-end autonomy and robust adaptation to complex, multi-step, cross-tool PDE problem structures (Liu et al., 18 Dec 2025).

1. Architectural Design and Agent Roles

PDE-Agent implements the Prog-Act framework, which tightly couples “progressive reasoning” (planning, validation, and replanning; Prog) with “acting” (tool invocation and execution; Act) in a dual-loop workflow. The framework is instantiated by four specialized, LLM-driven agents:

• Planner (Prog): Consumes the user-supplied natural language PDE specification $\mathcal{Q}$ and decomposes it into an initial multi-step plan $\mathcal{T}_0 = \{\tau_1, \ldots, \tau_K\}$, where each $\tau_k = \langle k, f, g\rangle$ consists of step index $k$, a target tool $f \in \mathcal{F}$, and a reasoning goal $g$.
• Parser/Solver (Act): For each subtask $\tau_k$, verifies the selected tool $f$, extracts or infers the explicit parameters $\theta_{\tau,f}$ (e.g., PDE domain, boundary/initial conditions, network parameters).
• Executor (Act): Runs tool $f$ with parameters $\theta_{\tau,f}$, producing output $o_{\tau,f}$, and archives all artifacts into the shared resource-pool $\mathcal{R}$.
• Orchestrator (Prog & Act): Maintains the global state, validates subtasks at graph-defined checkpoints, triggers global replanning if local correction fails, and continually updates the graph memory $\mathcal{G}$.

This agent decomposition ensures separation of concerns between high-level reasoning and low-level execution, permitting dynamic adaptation and robust error handling.

2. Prog-Act Framework and Dual-Loop Planning

The Prog-Act mechanism introduces a dual-loop planning and error correction structure:

Inner Loop (Localized Fixes)

Subtasks are executed and validated in sequence. After $M$ steps or at checkpoint $c$, the Orchestrator applies: $$\mathrm{Validate}(\mathcal{Q}, \mathcal{A}_c,\mathcal{G}) = \begin{cases} \mathrm{Pass}, & \text{if no Error}(\mathcal{A}_c)\ \mathrm{InLoop}(\mathcal{A}_c,\mathcal{G}), & \text{otherwise} \end{cases}$$ If errors are detected, the Orchestrator traces tainted nodes via graph traversal from sources of error and invokes granular correction routines which may patch parameters $\theta$ or re-execute minimal subgraphs.

Outer Loop (Global Revision)

If repeated localized fixes do not resolve inconsistencies, the Orchestrator challenges the Planner for global replanning: $$\mathcal{T}_{t+1} = \mathrm{Planner}(\mathcal{Q}, \mathcal{T}_t, \mathrm{Feedback}(\mathcal{A},\mathcal{G}))$$ The Planner may repair, reorder, or replace subtasks, yielding a new execution plan.

The design maximizes efficiency by avoiding per-step revalidation, while maintaining robustness to both transient and structural failures.

3. Graph Memory Data Structures

A dedicated, dynamically updated graph memory $\mathcal{G} = (\mathcal{V},\mathcal{E})$ underpins all inter-agent and inter-tool coordination:

• Node Set $\mathcal{V}$: Nodes represent subtasks ($v^{\tau_k}$) and tool invocations ($v^{f_j}$).
• Edge Set $\mathcal{E} \subset \mathcal{V} \times \mathcal{V}$: Directed edges represent dependency and data-flow, e.g., $(v^{\tau_j} \rightarrow v^{f_k})$ signifies $\tau_k$ depends on the output of $\tau_j$.
• Adjacency Matrix $A \in \{0,1\}^{N \times N}$: Element $A_{ij}=1$ if $(v_i \rightarrow v_j) \in \mathcal{E}$, else $0$.
• Node Embeddings $h_i \in \mathbb{R}^d$: Computed by $h_i = \varphi(v_i;\theta_\varphi)$, where $\varphi$ is a shared encoder (e.g., Transformer, MLP).
• Edge Embeddings $e_{ij} \in \mathbb{R}^e$ (optional): Computed as $e_{ij} = \psi(\text{type}_{ij} ; \theta_\psi)$ for typed dependencies.

Graph updates are atomic per agent action, with each new execution or tool invocation updating $\mathcal{V}$ and $\mathcal{E}$ to accurately reflect current states and dependencies. Localized validation and correction are performed by traversing the affected subgraph, typically incurring sublinear cost in the overall graph.

4. Resource-Pool and Tool-Parameter Separation

The Resource-Pool $\mathcal{R}$ centralizes all runtime artifacts—outputs, intermediate results, parameterizations—generated during PDE solution steps. This design, coupled with a tool-parameter separation mechanism, enables:

• Decoupling of explicit tool parameters from implicit runtime artifacts, ensuring that data dependencies across tools are automatically tracked and resolved;
• Central management of intermediate data, augmenting robustness with controlled data lineage, provenance, and inter-tool operability.

The Resource-Pool's integration into the graph memory allows each agent to check availability, provenance, and versioning of necessary inputs before tool invocation, preventing race conditions and inconsistencies endemic to purely sequential pipelines.

5. Workflow Pseudocode and Dynamic Execution

The dynamically adaptive workflow of PDE-Agent is summarized algorithmically as:

def PDE_Solve(Q): T = Planner(Q) G = (V=set(), E=set()) R = set() A = [] t = 0 while t <= T_max: m = 0 while m < len(T): τ = T[m] θ = ParserSolver(τ, R) o = Executor(τ.tool, θ) a = (τ, θ, o) A.append(a) update_graph(G, a) update_resource_pool(R, o) m += 1 if is_checkpoint(m): status = Validate(Q, A_window, G) if status != "Pass": perform_local_fix(status, G, ParserSolver, Executor) if not fixed_after_retries: break # inner loop collapse if status == "Pass" and m == len(T): return assemble_solution(A) # Outer loop: global revision feedback = collect_feedback(A, G) T = Planner(Q, T, feedback) t += 1 raise RuntimeError("Failed to solve PDE after global revisions")

This pseudocode explicitly demonstrates the coordination of planning, execution, validation (both localized and global), and continual state propagation via $\mathcal{G}$ and $\mathcal{R}$.

6. Formal Properties and Computational Complexity

The framework provides an informal correctness guarantee: due to the dual-loop structure, any localized error will ultimately invoke either successful in-loop correction or a global replan. As long as the Planner and tools are not fundamentally unsound, this mechanism ensures progression toward consistency.

Complexity properties:

• Graph maintenance: Each action contributes $\mathcal{O}(1)$ nodes and up to $\mathcal{O}(d)$ edges ($d$: in-degree). Over $K$ subtasks, the update cost is $\mathcal{O}(K + |\mathcal{E}|)$.
• Validation: For an action batch $A_c$ of size $c$, total cost is $\mathcal{O}(c + |E_c|)$ for action and edge scans.
• Localized fixes: Typically scan subgraphs far smaller than the global graph.
• Planner: Dominated by LLM inference, modeled as black-box cost $\mathcal{O}(\text{LLM})$ per planning call; number of outer loop iterations is empirically $\leq 3$.

7. Empirical Evaluation and Implications

Evaluation utilizes PDE-Bench, a curated benchmark comprising diverse PDE types for agent-based, tool-collaborative solving. Multi-level tool coordination metrics are used to assess system performance. Experimental results demonstrate superior applicability and efficiency in solving complex, multi-step, cross-step dependent PDE tasks compared to previous frameworks. The successful demonstration of toolchain-augmented, multi-agent PDE solving suggests a new paradigm for automated scientific computing, with implications for general tool invocation and LLM-centric workflow orchestration in other computational domains (Liu et al., 18 Dec 2025).

---

Editor’s term: “Prog-Act workflow” denotes the tightly coupled progressive reasoning and acting dual-loop at the core of PDE-Agent’s execution model. This approach enables both fine-grained error localization and large-scale replanning, representing a significant departure from rigid sequential pipelines in prior automated PDE approaches.