Why this project exists

Stormwater modelling is rarely one command. A typical SWMM project can involve GIS preprocessing, rainfall formatting, parameter assignment, network assembly, INP construction, model execution, QA checks, plots, calibration, uncertainty analysis, and reporting.

Agentic SWMM provides a middle path: natural-language orchestration with deterministic SWMM execution, explicit provenance, project memory, and verification-first modelling.

The goal is not to replace SWMM or the modeller, but to make SWMM-based modelling easier to reproduce, audit, remember, and trust.

What makes it different

Five things that set the workflow apart

01

Quick onboarding

Start from one-line macOS/Linux or Windows installers, with Docker and the Python (PyPI) package paths documented separately.

02

Agent-guided & SWMM-grounded

Agents can coordinate tasks, while model execution stays deterministic, inspectable, and CLI-runnable.

03

Modular skill layer

GIS, climate, building, running, plotting, calibration, uncertainty, audit, and orchestration are separated into reusable modules with MCP interfaces where available.

04

Verification-first provenance

Build, run, audit, and comparison stages emit traceable artifacts before outputs are treated as evidence.

05

Supervised skill evolution

Audited runs can surface recurring workflow patterns and propose updates to existing skills or new skills, while staying coupled to the current skill-driven framework.

The workflow

Three connected layers

Agentic SWMM modeling memory and controlled skill evolution loop
Execution, modeling memory, and controlled skill evolution — one auditable loop from request to verified result.

The workflow has three connected layers: execution, modeling memory, and controlled skill evolution. Natural-language requests can trigger reproducible SWMM actions; audited artifacts update human-readable and machine-readable memory; repeated patterns can produce skill-refinement proposals that still require human review and benchmark verification.

What a run can produce

  • generated or supplied SWMM input files such as model.inp
  • SWMM report and binary outputs such as .rpt and .out
  • manifests, command traces, QA summaries, and parsed peak-flow metrics
  • rainfall-runoff figures, calibration summaries, and fuzzy uncertainty summaries
  • audit records: experiment_provenance.json, comparison.json, and experiment_note.md
  • Obsidian-ready modelling notes and modelling-memory summaries