Software and Tools for Agent-Based Modelling
The framework question matters less than it feels like it does. Almost every model that failed did so because of its design, not its runtime. Still, some choices save months.
Broadly there are three families: teaching-oriented environments that optimise for getting a working model quickly, general-purpose libraries in a language you already use, and high-performance frameworks that matter only when the model is large enough for performance to be the binding constraint.
Teaching and prototyping environments
Purpose-built modelling environments with their own domain language remain the fastest route from idea to running model, particularly for spatial models on a grid. Visualisation is built in, the model library is extensive, and a first working version is realistically an afternoon's work. The constraints are real: the languages are idiosyncratic, integration with a wider analysis pipeline is awkward, and performance ceilings arrive earlier than expected. For exploring whether a mechanism does what you think, this is usually still the right starting point.
General-purpose libraries
Modelling libraries inside a mainstream language - most commonly Python - are the pragmatic default for research work. The model, the parameter sweep, the statistical analysis and the figures all live in the same ecosystem, which removes an entire class of pipeline friction and makes the work far easier to reproduce. Raw execution speed is the weak point, though this is less binding than it used to be: vectorised array operations handle a surprising amount of agent logic, and just-in-time compilation covers most of the rest.
Where the model is fundamentally a network process, building directly on a graph library rather than an agent framework is often simpler. The agents are nodes, the interaction is edge traversal, and the framework adds abstraction you do not need. See network structure and measures.
High-performance frameworks
Frameworks built for distributed execution across cores or clusters become relevant when the model has millions of agents or when a parameter sweep needs thousands of runs. They demand a stricter programming discipline and considerably more setup. The test is straightforward: if a single run takes minutes and the sweep fits on one machine overnight, this tier is not your problem.
What actually matters
- Reproducibility. Explicit random seed control, versioned dependencies, and the complete parameter set stored with the output. Without these, results cannot be rerun, and results that cannot be rerun do not count.
- Sweep support. Running a model across a parameter grid should be configuration, not a script you rewrite for every project.
- Output that goes straight into analysis. Anything that produces bespoke text logs requiring custom parsers will consume more time than the model.
- An escape route. At some point you will need something the framework does not support. Frameworks that let you drop into ordinary code at that point are worth more than feature-complete ones that do not.
When to write it yourself
More often than framework documentation suggests. If the model has a few hundred agents, simple rules and no spatial component, a few hundred lines of ordinary code will be clearer, faster and easier to debug than the same model expressed through a framework's abstractions. Reach for a framework when you need its scheduler, its spatial infrastructure or its visualisation - not by default. The design principles in building your first model apply either way.