Natural-language coordination sits above deterministic EPA SWMM execution. Goals, environments, tools, skills, artifacts, QA, calibration, and audit stay visible at every stage—and a run folder is organised for whoever opens it next.
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.
Sessions across five Canadian cities shaped the latest release. It adds analysis without observed flow, brings past failures into planning, and preserves the context behind follow-up questions.
Release notes →Questions about completed work use its existing artifacts. A failed run stays the reference until the user changes it, and a provider error leaves the shell open. Approvals identify the area and dates; a new area needs its own approval.
fetch_swmm_from_canada now accepts a city name as well as user-supplied coordinates. The retrieved bundle preserves its model, study-area map, source identifiers, and upstream QA.
Typed report sections cover flooding, surcharge, depth, and runoff. Word reports include the evidence boundary and any design-review verdict; peak flows use the units recorded by SWMM.
Re-audits retain earlier records. Parameter sweeps and climate batches keep separate outputs. Failure memory and relevant parameter records feed the next plan, with modelling lessons anchored to their location.
Use the one-line installers, PyPI package, or a pinned Docker image. Installer checks cover macOS, Linux, Windows x64, and Windows on ARM. For agent runtimes, install the portable skills with one command.
Agents plan and route work while EPA SWMM execution remains deterministic, inspectable, artifact-based, and runnable from the CLI.
GIS, climate, building, network, running, plotting, design review, calibration, uncertainty, water quality, reporting, audit, memory, and orchestration stay modular, with 11 MCP servers behind them.
MCP interfaces expose typed modelling actions while planners are constrained by routing rules, input requirements, QA gates, and stop conditions.
Upstream, build, run, QA, plot, audit, review, and report stages emit traceable artifacts before outputs are presented as evidence—and a run is allowed to conclude that its own results are disqualifying.
Failure memory and relevant parameter records reach the planner before new work. Raw audit notes remain the source record, and proposed skill changes require human review and benchmark verification.
v0.9.4 can explore uncertain inputs before observed flow is available. The question determines whether to propagate ranges together, vary parameters individually, or compare simulations with observations.
| Your question | Analysis | What the result means |
|---|---|---|
| How much could the output change within these parameter ranges? | Joint parameter-range propagation | An ensemble and output spread conditional on the stated ranges. Observed flow is not required. |
| Which parameter has the largest effect around this baseline? | One-at-a-time sensitivity ranking | Each parameter varies while the others stay at baseline. The ranking describes local effects and does not measure parameter interactions. |
| Which parameters best reproduce measured flow? | Observation-based calibration and sensitivity tools | Requires a reference series. Fit and validation claims depend on those observations and the evaluation period. |
The first two routes use propagate_parameter_ranges, with joint or one-at-a-time mode. Rainfall scaling uses the climate-scenario route. Each batch retains its inputs and outputs for inspection.
Parameter spread describes the assumptions you supplied. It does not establish calibration or predictive accuracy for an unobserved catchment.
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.
Ten provider routes sit behind one detect-first aiswmm setup wizard: OpenAI, Anthropic, OpenRouter, DeepSeek, Groq, Gemini, local Ollama and LM Studio, OpenAI-compatible gateways, and custom endpoints. The wizard lists every route and detects what is already running on the machine.
Three of those routes need no API key at all, including a local gateway that fronts a ChatGPT plan — aiswmm gateway login installs a pinned build for the running OS and architecture, runs the browser OAuth, and leaves it serving. An optional local fallback chain keeps a session alive through outages and quota windows.
Never paste an API key into the aiswmm conversation. Configure it during setup or in your shell environment instead.
A natural-language goal and a CLI verb pick from the same typed tools and write the same artifacts. Describe the work in a sentence when you want the chain planned for you; call aiswmm run, calibrate, climate, or audit directly when you already know the step. Neither path can reach a result the other could not reproduce.
See Two interfaces, one engine and the LLM provider routes for the full mapping.
00_raw/ plus a rendered study-area map, when the model came from SWMMCanadamodel.inp.rpt and .outsession.yaml, agent snapshots, environment fingerprints, manifests, command traces, QA summaries, and parsed peak-flow metricsexperiment_provenance.json, comparison.json, and experiment_note.mdREADME.md naming the deliverable, plus Obsidian-ready modelling notes and memory summaries