2.3.3: Decision framework

Given everything this chapter has said about what agent-based modelling can and cannot do, one practical question remains: is ABM the right method for your problem, and if it is, how do you build a version of it that others can trust? This section turns the chapter’s discussion into a working decision framework so you are not left weighing strengths and limitations by intuition alone. It moves in three steps: first weigh the trade-offs side by side (2.3.3.1), then run a go/no-go check on your own project (2.3.3.2), and finally, once ABM is chosen, follow the development habits that make a model credible (2.3.3.3).

Begin with the trade-offs, since every later step rests on seeing them clearly.

2.3.3.1: ABM pros and cons

The table below summarises the trade-offs discussed across this chapter, setting the eight strengths (from natural representation of individuals through to stakeholder engagement) against the four limitations that shadow them, so the gains and their costs can be read side by side.

Strengths and limitations of ABM at a glance

Click any strength or limitation to read what it means. The four limitations are the shadow of the very attention to individuals that gives ABM its strengths.

Strengths

Limitations

Click a strength or a limitation above to see what it means.

The two lists are two sides of the same coin. The close attention to individuals that gives ABM its strengths is exactly what makes a model hard to validate, heavy to run, tricky to explain, and demanding to reproduce. Choosing ABM means accepting these costs alongside the gains, with eyes open.

The strengths and limitations of ABM are not two unrelated lists but two sides of the same coin. The very feature that makes the method powerful, its close attention to individuals, is also what makes a model hard to validate, heavy to run, tricky to explain, and demanding to reproduce. Seeing this trade-off clearly matters because it keeps you honest: choosing ABM means accepting its costs alongside its gains, with eyes open. In the activity below, label each statement a strength or a limitation, and as you go, try to notice which limitation is the shadow of which strength.

Learning Activity: Strength or limitation?

tell an ABM strength apart from a limitation.

A set of nine features of agent-based modelling, some of them genuine strengths of the approach and others its limitations.

For each statement, choose Strength or Limitation, and once every row is labelled press Check answers.

Check answers

With the trade-off in view, the next step is to operationalise it: the checklist below turns this general insight into a concrete go/no-go test for your own project.

2.3.3.2: Checklist: when to use ABM

Use this interactive checklist to determine whether ABM is appropriate for your research question, based on the strengths and limitations we have discussed:

Learning Activity: Should you use ABM?

turn the strengths and limitations of ABM into a go/no-go decision.

A three-part checklist covering agent-based modelling's strengths, its limitations, and the decision criteria that bear on a modelling project.

Tick the strengths and criteria that apply to your project and the limitations that concern you, then press Evaluate ABM suitability.

ABM strengths (check if these apply to your project)

You need natural representation of individual decision-makers You want to study emergent behaviour from simple interactions You need to test policies or interventions safely Individual heterogeneity is important in your system Spatial or network effects are crucial You need to understand micro-to-macro linkages You want flexible, extensible model design Stakeholder engagement is important

ABM limitations (check if these are concerns for your project)

Model validation is very challenging for your domain You have severe computational constraints Communicating results to stakeholders is critical Full transparency and reusability are essential

Decision criteria

Individual differences significantly affect system outcomes Local interactions dominate over global effects You expect emergent behaviours to be important Spatial or network structure influences behaviour You have adequate computational resources Some individual-level data is available Process understanding is more important than precise predictions Traditional models are inadequate for your problem

Evaluate ABM suitability

The verdict points to a next step rather than a final answer. A reading of highly recommended or likely suitable means ABM fits your problem, so the task becomes building it well and, where the checklist flagged limitations, planning early for how you will address them. A reading of consider alternatives or may not be the best choice is a signal to test a simpler approach first, or to reconsider whether individual-level detail is really what your question needs. A mixed result invites you to revisit the trade-offs above before committing.

Once the checklist has settled the choose-the-method question in ABM’s favour, a second and quite different question opens up: not whether to use ABM, but how to build one that others can trust. The rest of this section answers that.

2.3.3.3: Developing a trustworthy ABM: practices and pitfalls

Good ABM development spans four areas. Select each to see the practices it involves:

Model design

• Start simple and add complexity incrementally

• Follow ODD protocol (Overview, Design concepts, Details)

• Use modular architecture separating agents from environment

Implementation

• Write clear, self-documenting code with meaningful variable names

• Document all parameters and their valid ranges

• Use version control and configuration files

Validation

• Test individual components and their interactions

• Check model behaviour at parameter extremes

• Ensure results are reproducible

• Validate against real-world data when possible

Communication

• Document model purpose, scope, and limitations

• Visualise patterns and dynamics clearly

• Quantify uncertainty in all results

• Explain emergence mechanisms to stakeholders

Whether an agent-based model can be trusted depends less on cleverness than on good working habits. Building up complexity gradually, documenting the model, running enough replications, checking how sensitive results are to the parameters, validating against real data, and being honest about uncertainty are the practices that make a model credible; skipping them is what quietly undermines it. These habits matter because a model is only as convincing as the process behind it, and each pitfall is simply the neglect of a sound practice. In the activity below, label each habit a good practice or a pitfall, and notice that many of the pitfalls are just the mirror image of a practice left undone.

Learning Activity: Practice or pitfall?

tell good modelling practice from a common pitfall.

Ten habits that someone might follow when building an agent-based model, half of them sound practice and half common pitfalls.

For each habit, choose Good practice or Pitfall, and once every row is labelled press Check answers.

Check answers

2.3.3.3.1: The pitfalls that mirror the practices

Because each pitfall is a good practice left undone, the failures worth guarding against are easy to name once the practices are clear. The box below collects the most common ones in a single checklist you can scan before publishing a model.

Common pitfalls to avoid

• Making models too complex from the start

• Running insufficient replications

• Ignoring parameter sensitivity

• Presenting results without uncertainty bounds

• Over-claiming model validity

Each pitfall above is a good practice left undone. Match each pitfall to the practice it neglects in the activity below.

Learning Activity: Pitfall, meet practice

pair each common pitfall with the good practice it neglects.

Two columns to be paired: five common pitfalls of agent-based modelling on one side and the good practices they neglect on the other.

Click a pitfall, then click the good practice it neglects, and repeat until all five pairs are matched; press Reset to reshuffle.

Pitfalls

Good practices

Matched 0 / 5

Reset

Each pitfall is simply a good practice left undone. The failures worth guarding against are the mirror image of the habits that make a model credible, so naming the pair is the quickest way to remember both.

Named in pairs, the pitfalls become easy to remember: each is simply the corresponding practice omitted.

2.3.3.4: Putting the framework together

Taken together, the three steps form a single decision framework: weigh ABM’s strengths against the limitations that shadow them, run the go/no-go check to see whether that balance favours ABM for your problem, and, if it does, build the model with the habits that make it credible while steering clear of their mirror-image pitfalls. Deciding to use ABM and deserving to be trusted with it are two halves of the same judgement.

Before moving on, reassemble the framework yourself by placing its four steps in the order they must run.

Learning Activity: Put the framework in order

rebuild the decision framework in the sequence its steps must run.

The four steps of the framework for deciding whether to use agent-based modelling, shuffled out of sequence.

Click the shuffled steps one at a time to drop them into the numbered slots from first to last, then when all four are filled press Check order.

Your order

Steps (click to place)

Check orderReset

The framework runs in one direction. You cannot decide before you have weighed the trade-offs, or build before you have decided ABM fits; and the pitfalls are worth a last look only once the model is built. Deciding to use ABM and deserving to be trusted with it are two halves of the same judgement.

Ordering the steps this way exposes the framework’s logic, since each step depends on the one before it.

This closes Chapter 2’s foundations. With the fundamentals in place, the next chapter turns from deciding on and reasoning about ABMs to actually building one in code.

Key takeaways

Key takeaways

• The choice to use ABM should follow from weighing its advantages against its costs for the specific problem, rather than from habit.

• Once ABM is chosen, a model becomes trustworthy through disciplined practice: stating assumptions, building incrementally, calibrating, validating, and documenting.

• Each good practice has a mirror-image pitfall, so developing a credible ABM is as much about avoiding known failure modes as about following the steps.