Interaction with the AI Assistant is designed to be conversational, but like any conversation it is helpful to have some shared vocabulary. Much of that is just the language of building and using models (stocks, flows, converters, sensitivity...) but the AI Agent also has some tools it is told about. These tools make the interactions between the LLM and your model possible. While the agent (though it's workflow) tries to make sure the appropriate tools are called some direction from your inputs can be helpful in making sure the right tools are used.
While the tools are an evolving list, some of the basic one are described below. Knowing about them can help you phrase queries so that the LLM is more likely to use a tool than to work from scratch.
Without going into detail, using words that hint at these tools is likely to give better results. For example using the word "layout" when you want to make adjustments to a model diagram will make the association to the auto_layout_model tool clear.
You will need to experiment a bit to see what vocabulary works best for getting your work done, but using words that are common in the modeling process or that reference the tools is likely to give the best results.
The foundation of the collection consists of tools that wrap the existing engines introduced in earlier work. These tools expose the capabilities of those engines within the agent’s iterative workflow.
generate_quantitative_model invokes the quantitative engine to produce a simulation-ready stock-and-flow model. As described in prior work, this process leverages structured outputs and carefully designed prompts to ensure that generated models include equations, units, and documentation (Schoenberg, 2026). Within the agentic system, this tool can be called repeatedly, allowing the agent to refine models incrementally based on intermediate analysis.
generate_qualitative_model invokes the qualitative engine to construct causal loop diagrams (CLDs) from textual descriptions. The qualitative engine’s ability to iteratively build causal structure from user input lowers the barrier to entry for conceptual modeling, while maintaining consistency through structured JSON outputs (Schoenberg et al., 2026).
By exposing both quantitative and qualitative model generation as tools, the architecture enables the agent to move flexibly between conceptual and formal representations, depending on the needs of the task.
A second group of tools supports reasoning about models by connecting the agent to the Seldon engine and to feedback-based analysis methods.
discuss_model_with_seldon provides structured explanations of model behavior grounded in the model’s structure and simulation output. Seldon transforms dense model and behavioral data into interpretable prose, with particular emphasis on feedback mechanisms and loop dominance (Schoenberg, 2026). Within the agent loop, this tool allows the agent to interpret intermediate results and guide subsequent actions.
discuss_model_across_runs extends this capability to comparative analysis, enabling the agent to explain differences between multiple simulation scenarios in terms of underlying feedback structures.
generate_ltm_narrative produces structured explanations based on the Loops that Matter method, which quantifies the contribution of individual feedback loops to system behavior over time (Schoenberg et al., 2020; Schoenberg et al., 2023). This ensures that behavioral explanations are not only qualitative but also grounded in measurable structural influence.
discuss_with_mentor provides a complementary, Seldon based, Socratic mode of interaction in which the tool proposes guiding questions rather than providing direct explanations. This supports pedagogical use cases, reinforcing the human-centered philosophy emphasized in prior work.
Together, these tools operationalize a central principle of System Dynamics: that understanding arises from linking behavior to feedback structure.
The agent interacts with the modeling environment exclusively through a set of tools that mediate communication with the client.
get_current_model retrieves the current model state, including any syntax errors or unit warnings detected by the client. This ensures that the agent always operates on the latest model and can respond to structural issues identified externally.
update_model pushes modifications from the agent to the client, allowing the user to inspect and interact with the evolving model.
run_model triggers a simulation by the client software, producing a unique run identifier that can be used for subsequent data retrieval.
get_run_info enumerates available simulation runs, including externally loaded data for calibration.
get_variable_data retrieves time-series data for specified variables and runs. Notably, these data are passed via files stored in the agent’s temporary workspace, rather than directly in the LLM context. This design minimizes token usage while preserving access to behavioral information when needed.
These tools collectively enable the agent to carry out the core modeling loop: build, simulate, observe, and revise.
Visualization plays a key role in making model behavior interpretable. The tool collection includes capabilities for generating both standard and custom visualizations.
create_visualization generates graphical representations of simulation results, including time-series plots, phase portraits, feedback dominance charts, multi-run comparisons. By returning results as SVG, the tool ensures compatibility with client interfaces. There is additional option where instead of using a pre-defined python template for plotting, the agent writes its own plotting code completely from scratch to produce custom visualizations.
get_feedback_information requests information on the feedback structure of models. In Stella this is the feedback-loop dominance data computed using Loops that Matter analysis. This information is a prerequisite for any explanation or visualization that depends on feedback structure.
These tools reinforce the interpretability of agent outputs by making both behavior and structure visible in graphical form, aligning with the BEAMS Initiative’s emphasis on verifiable, model-based reasoning (BEAMS, 2026).
As models grow in size, regenerating them entirely, as the qualitative and quantitative engine do, becomes inefficient and prone to error. To address this, the sd-ai platform provides targeted direct editing tools that allow the agent to work with large models incrementally.
These include:
• read_model_section, which retrieves specific portions of the model (specs, variables, relationships, modules)
• edit_variables, for modifying variables and equations
• edit_relationships, for updating causal connections
• edit_specs, for adjusting simulation parameters including time, array dimensions and integration method
• edit_modules, for managing hierarchies of modules
By enabling localized edits, these tools allow the agent to scale to complex models while maintaining precision and minimizing context usage and therefore cost.