Background
aiswmm currently uses the CLI as one of the main entry points to the Agentic SWMM runtime.
The current Web UI can be understood roughly as:
Web GUI → aiswmm CLI → Agentic Runtime → Skills / MCP → EPA SWMM → Results → Web GUI
This works well for the current implementation, but it tightly couples the Web interface to the CLI execution layer.
Proposal
Evolve aiswmm so that the Agentic Runtime becomes the core engine, with multiple interfaces built on top of it.
The target architecture would look like:
Web GUI → aiswmm API ← Unity
↓
Agentic Runtime
↓
Skills / MCP
↓
EPA SWMM
↓
Results
The CLI should remain available for developers, local workflows, scripting, automation, and reproducible execution.
At the same time, aiswmm should expose its main capabilities through an API service, ideally a REST API initially.
The Web GUI would then call the API instead of directly invoking the CLI.
Future interfaces such as Unity, serious games, Python applications, dashboards, or third party systems could use the same API without changing the underlying Agentic Runtime.
Why
This architecture would separate the user interface from the core execution engine.
It would allow us to:
Keep one shared Agentic Runtime for all interfaces
Support both CLI and graphical interfaces
Replace or extend the Web GUI without changing the core system
Connect Unity directly to aiswmm for serious game applications
Support remote and cloud deployment
Make multi user and concurrent execution easier in the future
Provide a stable integration interface for external applications
Keep CLI workflows available for local and scientific reproducibility
Long Term Direction
The long term idea is:
aiswmm Runtime = core engine
CLI = developer and automation interface
API = application integration interface
Web GUI / Unity / other clients = presentation layer
In this architecture, Web and Unity are simply different front ends connected to the same aiswmm backend.
Initial Tasks
Define the boundary between the CLI and the Agentic Runtime
Identify the core Runtime functions that should be exposed through an API
Define a basic API contract for submitting jobs and retrieving results
Refactor the Web GUI to communicate through the API
Keep the existing CLI as a first class interface
Design the API so that future Unity integration is straightforward
Background
aiswmm currently uses the CLI as one of the main entry points to the Agentic SWMM runtime.
The current Web UI can be understood roughly as:
Web GUI → aiswmm CLI → Agentic Runtime → Skills / MCP → EPA SWMM → Results → Web GUI
This works well for the current implementation, but it tightly couples the Web interface to the CLI execution layer.
Proposal
Evolve aiswmm so that the Agentic Runtime becomes the core engine, with multiple interfaces built on top of it.
The target architecture would look like:
Web GUI → aiswmm API ← Unity
↓
Agentic Runtime
↓
Skills / MCP
↓
EPA SWMM
↓
Results
The CLI should remain available for developers, local workflows, scripting, automation, and reproducible execution.
At the same time, aiswmm should expose its main capabilities through an API service, ideally a REST API initially.
The Web GUI would then call the API instead of directly invoking the CLI.
Future interfaces such as Unity, serious games, Python applications, dashboards, or third party systems could use the same API without changing the underlying Agentic Runtime.
Why
This architecture would separate the user interface from the core execution engine.
It would allow us to:
Keep one shared Agentic Runtime for all interfaces
Support both CLI and graphical interfaces
Replace or extend the Web GUI without changing the core system
Connect Unity directly to aiswmm for serious game applications
Support remote and cloud deployment
Make multi user and concurrent execution easier in the future
Provide a stable integration interface for external applications
Keep CLI workflows available for local and scientific reproducibility
Long Term Direction
The long term idea is:
aiswmm Runtime = core engine
CLI = developer and automation interface
API = application integration interface
Web GUI / Unity / other clients = presentation layer
In this architecture, Web and Unity are simply different front ends connected to the same aiswmm backend.
Initial Tasks
Define the boundary between the CLI and the Agentic Runtime
Identify the core Runtime functions that should be exposed through an API
Define a basic API contract for submitting jobs and retrieving results
Refactor the Web GUI to communicate through the API
Keep the existing CLI as a first class interface
Design the API so that future Unity integration is straightforward