Agent-Based Modeling: Design, Behavior, and Validation Techniques, Lecture notes of Computer Science

This document provides an overview of agent-based modeling (ABM), covering model design, agent behavior, and validation. It explores reflexive, utility-based, goal-based, and adaptive agents and their interactions. The importance of research questions and model refinement based on real-world data is discussed, along with tools like NetLogo's BehaviorSpace. Case studies, such as the El Farol Bar and Schelling's Segregation models, illustrate ABM concepts in urban modeling and economics. The iterative nature of ABM, requiring continuous refinement and validation, is emphasized. The document also touches on ABM's use with machine learning, highlighting its versatility and potential.

Typology: Lecture notes

2017/2018

Uploaded on 08/02/2025

abubakar-tufail
abubakar-tufail 🇵🇰

2 documents

1 / 18

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Section 9.8: Extensions to the Fire Model (Modules 90-92)
The basic Fire model, while illustrative, can be extended to explore more nuanced
mechanisms and produce a wider range of behaviors. These extensions often involve
making parameters more explicit or adding new environmental factors.
Subsection 9.8.1: First Extension - Probabilistic Transitions (Module 90)
In the basic Fire model, the spread of fire to a neighboring tree, if it exists, is
deterministic once a tree is burning. A common first step in extending such models is
to introduce more explicit probabilistic elements to the transition rules. While the
initial tree placement is based on a density probability, the actual spread from a
burning tree to an adjacent green tree can also be made probabilistic.
This involves defining a PROBABILITY-OF-SPREAD parameter. Instead of a
guaranteed spread to a green neighbor, the fire only spreads if a random event (e.g., a
random number generation compared against this probability) is successful. This
PROBABILITY-OF-SPREAD can represent a host of underlying mechanisms not
explicitly modeled, such as variations in fuel moisture, local wind gusts not captured
by a general wind model, or the type of vegetation.1 By making this probability an
adjustable parameter, modelers can explore how the likelihood of transmission at a
local level affects the overall fire propagation and the critical density threshold. This
extension allows for a more fine-grained control over the fire's behavior beyond the
initial tree density.
Subsection 9.8.2: Second Extension - Adding Wind (Module 91)
A significant factor influencing real forest fires is wind. The Fire model can be
extended to incorporate the effects of wind on fire spread.1
Implementation: Wind is typically implemented by adding sliders to the user
interface that control wind speed and direction. For instance, one slider might
control the wind speed from the south (with negative values indicating wind from
the north), and another for wind from the west (negative values for east wind).
These sliders could range from -25 to 25, representing varying strengths.1
Effect on PROBABILITY-OF-SPREAD: The wind's effect is modeled by
modifying the PROBABILITY-OF-SPREAD based on the wind's direction relative to
the potential spread direction. The wind speed values (e.g., -25 to 25) can be
interpreted as percentage changes to the base PROBABILITY-OF-SPREAD. The
logic would increase the probability of spread in the direction the wind is blowing
and decrease it in the opposite direction, with minimal effect on spread
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12

Partial preview of the text

Download Agent-Based Modeling: Design, Behavior, and Validation Techniques and more Lecture notes Computer Science in PDF only on Docsity!

Section 9.8: Extensions to the Fire Model (Modules 90-92)

The basic Fire model, while illustrative, can be extended to explore more nuanced mechanisms and produce a wider range of behaviors. These extensions often involve making parameters more explicit or adding new environmental factors.

Subsection 9.8.1: First Extension - Probabilistic Transitions (Module 90)

In the basic Fire model, the spread of fire to a neighboring tree, if it exists, is deterministic once a tree is burning. A common first step in extending such models is to introduce more explicit probabilistic elements to the transition rules. While the initial tree placement is based on a density probability, the actual spread from a burning tree to an adjacent green tree can also be made probabilistic.

This involves defining a PROBABILITY-OF-SPREAD parameter. Instead of a guaranteed spread to a green neighbor, the fire only spreads if a random event (e.g., a random number generation compared against this probability) is successful. This PROBABILITY-OF-SPREAD can represent a host of underlying mechanisms not explicitly modeled, such as variations in fuel moisture, local wind gusts not captured by a general wind model, or the type of vegetation.^1 By making this probability an adjustable parameter, modelers can explore how the likelihood of transmission at a local level affects the overall fire propagation and the critical density threshold. This extension allows for a more fine-grained control over the fire's behavior beyond the initial tree density.

Subsection 9.8.2: Second Extension - Adding Wind (Module 91)

A significant factor influencing real forest fires is wind. The Fire model can be extended to incorporate the effects of wind on fire spread.^1

Implementation: Wind is typically implemented by adding sliders to the user interface that control wind speed and direction. For instance, one slider might control the wind speed from the south (with negative values indicating wind from the north), and another for wind from the west (negative values for east wind). These sliders could range from -25 to 25, representing varying strengths.^1 ● Effect on PROBABILITY-OF-SPREAD: The wind's effect is modeled by modifying the PROBABILITY-OF-SPREAD based on the wind's direction relative to the potential spread direction. The wind speed values (e.g., -25 to 25) can be interpreted as percentage changes to the base PROBABILITY-OF-SPREAD. The logic would increase the probability of spread in the direction the wind is blowing and decrease it in the opposite direction, with minimal effect on spread

perpendicular to the wind.^1 ● NetLogo Code Logic: The NetLogo code would involve creating a local variable for probability, initially set to the global PROBABILITY-OF-SPREAD. This local probability is then adjusted based on the wind direction and speed before determining if the fire spreads to a neighboring tree.^1 ● Resulting Patterns: Adding wind can lead to more complex and realistic fire spread patterns. For example, with a high tree density (e.g., 100%), a strong wind from the south and west, and a relatively low base PROBABILITY-OF-SPREAD (e.g., 38%), the fire might exhibit a triangular spread pattern, predominantly moving towards the northeast.^1

Subsection 9.8.3: Third Extension - Allowing Long-Distance Transmission (Module 92)

Wind can also cause fires to jump over considerable distances, often due to flying embers or sparks, starting new fires in areas not immediately adjacent to the main fire front. This phenomenon, known as "spotting" or long-distance transmission, can be added as a further extension.^1

Implementation: A Boolean switch, perhaps labeled BIG-JUMPS?, can be added to the interface to allow the user to turn this behavior on or off. This ensures that the model can still replicate previous results when the feature is disabled.^1 ● Modeling Fire Jumping: When BIG-JUMPS? is true, the model simulates fire jumping by attempting to ignite a new fire at a certain distance away from a burning cell, in the direction of the wind. If an unburned (green) tree exists at this target location, it is set on fire.^1 This is a simplification, as a more detailed model might include explicit "spark" agents that travel according to wind conditions, but this extension models the effects of such sparks.^1 ● NetLogo Code Modification: The GO procedure is modified. After a patch turns red (burns), if BIG-JUMPS? is true, the code looks for a target patch at a distance in the wind's direction and ignites any unburned tree there.^1 ● Effect on Spread Patterns and Evaluation: This extension can have visually dramatic effects, creating lines of fire spread in the direction of the wind as it jumps across gaps. While it might increase the overall probability of the fire reaching the far edge of the forest, the resulting pattern is different, often leaving large unburned areas. This change in emergent patterns may necessitate a re-evaluation of the model's driving questions and the metrics used to measure its performance (e.g., "percent burned" might become more relevant than just whether the fire percolates).^1 It's also noted that these big jumps could themselves be made probabilistic.^1

(Note: WIGGLE-ANGLE would be a global variable, likely set by a slider).^1 ● Emergent Fractal-like Patterns: If the DLA model is run for a sufficient duration, the aggregation of particles around the initial seed(s) forms intricate, branching, fractal-like patterns.^1 This demonstrates how complex structures can arise from the simple, local rules governing individual particle movement and their interaction with the growing aggregate. The complexity of the resulting pattern often bears little direct relationship to the complexity of the underlying rules; indeed, simpler rules can sometimes create more complex patterns.^1

Section 9.10: Extensions to the DLA Model (Modules 94-96)

The basic DLA model can be extended to explore variations in the aggregation process and the resulting structures.

Subsection 9.10.1: First Extension - Probabilistic Sticking (Module 94)

The basic DLA model often produces thin, wispy structures because particles stick with 100% probability upon encountering the aggregate, making them more likely to attach to the outermost tips.^1

Motivation: To create thicker, denser structures, the sticking rule can be made probabilistic. This allows particles a chance to penetrate deeper into the aggregate before sticking.^1 ● Implementation: A slider, PROBABILITY-OF-STICKING (ranging from 0.0 to 1.0), is added to the interface. The sticking rule is modified: a particle sticks only if a random number is less than this probability and if it is not already on a green (stuck) patch.^1 ● Effect: With a lower probability of sticking (e.g., 0.5), the branches of the aggregate become thicker as particles can wander further into the structure before stopping. Setting the probability to 1.0 allows replication of the original model's results.^1

Subsection 9.10.2: Second Extension - Neighbor Influence (Module 95)

This extension explores how the probability of sticking can be related to the number of stationary neighbors a particle encounters.^1

Concept: A particle might be more likely to stick if it is surrounded by more parts of the existing aggregate. ● Implementation: A Boolean switch, NEIGHBOR-INFLUENCE?, is added. If true, the probability of sticking (LOCAL-PROB) is modified. For example, it can be calculated by multiplying the base PROBABILITY-OF-STICKING by the fraction of

the particle's eight neighbors that are already green (part of the aggregate). This means the sticking probability increases with more green neighbors.^1 ● NetLogo Code Logic: The GO procedure is modified to calculate LOCAL-PROB based on the NEIGHBOR-INFLUENCE? switch and the count of green neighbors before applying the sticking rule.^1 ● Effect: This modification typically results in much longer formation times (due to lower overall sticking probabilities, especially with few neighbors) and produces very thick, almost blob-like structures with fewer thin branches.^1

Subsection 9.10.3: Third Extension - Different Aggregates (Module 96)

Instead of a single central seed, this extension allows for multiple starting points for aggregation.^1

Implementation: A slider, NUM-SEEDS (e.g., ranging from 1 to 10), is added to control the number of initial green seed patches. In the SETUP procedure, N-OF NUM-SEEDS patches are randomly selected and turned green.^1 ● Difference from Fire Model: This N-OF method creates an exact number of seeds, unlike the Fire model's probabilistic tree generation which creates an approximate density. The N-OF method gives more precise control.^1 ● Effect: With multiple seeds, the resulting patterns can look different, sometimes resembling frost forming on a window, as aggregation occurs simultaneously from several points.^1 Even with NUM-SEEDS set to 1, the seed will now be randomly placed, deviating slightly from the original model's centered seed, but this is often acceptable for exploration.^1

Chapter 10: Social Science Applications of ABM (Modules 97-108)

Agent-Based Modeling has found significant application in the social sciences, where understanding the behavior of heterogeneous individuals and their interactions is often key to explaining macro-level social phenomena.

Section 10.1: The Segregation Model (Modules 97-100)

The Segregation model, famously pioneered by Thomas Schelling, is a classic ABM that explores how residential segregation patterns can emerge even when individuals have only mild preferences for living near others of their own type.^1

Modeling Approaches: The chapter distinguishes between: ○ Phenomena-based modeling: Starting with a known aggregate pattern (reference pattern) and trying to generate it with agent rules. ○ Exploratory modeling: Starting with simple rules and observing what

Implementation: A global list variable colors (e.g., ["red" "green" "blue" "yellow" "orange"]) is defined. A NUMBER-OF-ETHNICITIES slider (e.g., 2 to 5) is added. The SETUP code is modified so turtles randomly pick a color from the colors list, up to the number specified by the slider.^1 ● Observed Effects: Increasing the number of ethnicities generally leads to longer settling times for the system (for all turtles to become happy). However, the final PERCENT SIMILAR value, once settled, tends to remain relatively consistent regardless of the number of ethnicities.^1

Subsection 10.2.2: Second Extension - Allowing Diverse Thresholds (Module 102)

This extension acknowledges that real individuals likely have different tolerance levels, rather than a single, uniform threshold.^1

Implementation: Each turtle is given its own MY-%-SIMILAR-WANTED property. In the SETUP procedure, this property is initialized for each turtle with a random value between 0 and the global %-SIMILAR-WANTED slider value (making the global slider a maximum tolerance). The update-turtles procedure is changed to use MY-%-SIMILAR-WANTED instead of the global slider for each turtle's happiness calculation.^1 ● Observed Effects: The PERCENT SIMILAR monitor typically ends up with a lower value at the end of a run compared to the first extension. This is because some individuals are now more tolerant, allowing them to be happy in more diverse neighborhoods. The average of the individual MY-%-SIMILAR-WANTED values will be roughly half of the global slider's setting.^1

Subsection 10.2.3: Third Extension - Adding Diversity-Seeking Individuals (Module 103)

This extension introduces agents who not only avoid being in a minority but actively seek diversity.^1

Implementation: A %-DIFFERENT-WANTED slider is added. The happiness calculation in update-turtles is modified: an agent is now happy only if the percentage of similar neighbors is above its %-SIMILAR-WANTED and the percentage of different neighbors is above its %-DIFFERENT-WANTED threshold. Agents now seek a balance, avoiding being too much in a minority or too much in a majority.^1 ● Observed Effects: It becomes easier for the overall PERCENT SIMILAR to decrease because agents actively seek diversity. The system may take much

longer to settle, or it may never reach equilibrium if the demands are impossible to satisfy (e.g., if both %-SIMILAR-WANTED and %-DIFFERENT-WANTED are set above 50%).^1

Section 10.3: Advanced Urban Modeling Applications (Module 104)

ABM is frequently used for modeling urban landscapes and policy.^1

Residential Preference Models: The Segregation model is an example of this broader category, which is a major component of urban modeling systems.^1 ● CITIES Project: Carried out at Northwestern University, this project aimed to procedurally develop realistic cities for use as educational and exploratory tools by combining residential preference models with commercial, industrial, and governmental policy models.^1 ● SLUCE Project: Based at the University of Michigan, this project developed models of residential and tract development to explore land-use policies and their environmental effects in southeastern Michigan.^1 ● Land-Use Modeling: Both CITIES and SLUCE fall under the larger category of land-use modeling, a field with extensive ABM applications.^1

Section 10.4: The El Farol Bar Model (Module 105)

The El Farol Bar problem, posed by W. Brian Arthur, is an ABM that explores bounded rationality and inductive reasoning in an economic scenario.^1

Context: Traditional economics often assumes perfect rationality and information. Arthur's model explores a system where agents do not perfectly optimize, yet a classical economic equilibrium emerges.^1 ● Scenario: 100 people decide weekly whether to go to the El Farol bar for Irish music night. They prefer to go if it's not too crowded (e.g., fewer than 60 people). They have access to past attendance but limited memory.^1 ● Agents' Prediction Strategies: Each agent has a "bag" of diverse strategies (rules of thumb like "twice last week's attendance") to predict the current week's attendance. They use the strategy that would have performed best in recent past weeks to make their decision.^1 ● Emergent Equilibrium: Despite agents using different strategies and having imperfect information, Arthur found that the average attendance at the bar consistently hovered around the overcrowding threshold (e.g., 60). This demonstrates how a system can self-organize to optimally utilize a resource without centralized control or perfect rationality.^1 ● NetLogo Model Controls: The NetLogo version includes sliders for MEMORYSIZE

(Module 109)

The El Farol model and its extensions open doors to more advanced modeling applications.^1

Machine Learning: The El Farol model combines ABM with machine learning concepts, as agents can change their strategies over time based on performance, effectively learning.^1 ● Minority Game: The El Farol model has been idealized into the Minority Game, studied by physicists and economists for insights into complex systems, including crude approximations of financial markets (where being in the minority is often advantageous).^1 ● Other Economic Models: Other ABM economic models include the Artificial Stock Market (simulating investor behavior and market phenomena like booms/busts) and, in NetLogo, the Oil Cartel and Root Beer Supply Chain models.^1 ● HubNet for Participatory Simulations: Models like the Oil Cartel and Root Beer Supply Chain often use NetLogo's HubNet facility, which allows human users to control agents within a simulation, enabling exploration of how human decisions interact with and are constrained by complex systems.^1 ● General Lessons for Extending Models: Extending models often involves replacing deterministic rules with probabilistic ones, or vice-versa, replacing probabilistic rules with more explicit agent-based mechanisms. With each change, it's crucial to consider if new metrics are needed to measure model performance.^1

Chapter 11: Designing, Building, and Examining Agent-Based Models (Modules 110-120)

This chapter focuses on the practical process of developing an ABM, from initial question formulation to analyzing results, using the "Wolf Sheep Simple" model as a running example.

Section 11.1: The Modeling Process Overview (Module 110)

The process of creating an ABM is iterative, involving steps that often fold back on each other. The main stages are 1 :

  1. Designing your model: Determining the elements to include.
  2. Building your model: Translating the conceptual model into a computational object.
  1. Examining your model: Running the model, generating results, and analyzing them to answer the motivating question. The "Wolf Sheep Simple" model will be used to illustrate these stages, addressing the question: "How do the population levels of two habitat-sharing animal species change over time?".^1

Section 11.2: Designing Your Model (Module 111)

Model design depends on factors like the phenomenon, domain knowledge, coding comfort, and modeling style.^1

Phenomena-Based Modeling: Starts with a known target phenomenon and its "reference pattern" (e.g., housing segregation, spiral galaxies, oscillating populations). The goal is to create agents and rules that generate this pattern, offering an explanatory mechanism.^1 ● Exploratory Modeling: Starts with simple agents and rules, and explores the emergent patterns. The model is then refined based on similarities to real-world phenomena.^1 ● Top-Down Design: The conceptual model (agents, environment, interaction rules) is fully worked out before coding begins.^1 ● Bottom-Up Design: Conceptual design and coding co-evolve. One might start coding relevant to a domain and accumulate mechanisms, properties, and entities, perhaps formulating formal questions along the way.^1 ● ABM Design Principle: "Start simple and build toward the question you want to answer." ○ Component 1 (Simplicity): Begin with the simplest set of agents and rules needed to explore the system. Make elements "as simple and as few as possible without having to surrender the adequate representation of a single datum of experience" (Einstein).^1 ○ Component 2 (Question-Focus): Always keep the research question in mind; don't add elements that don't help answer it. "All models are wrong, but some models are useful" (Box) – useful if designed for particular questions without simplifications interfering with the answer.^1 ● Usefulness of the Principle: ○ Ensures every component is necessary, avoiding extraneous elements that have no effect. ○ Reduces ambiguities, redundancies, and inconsistencies. ○ Leads to more understandable and verifiable models (verification: ensuring computational model faithfully implements the conceptual model).^1

Section 11.3: Choosing Your Questions (Module 112)

properties, states, and behaviors bear on the question. ● Agent Overload: Avoid designing too many agent types, which can make the model unmanageable. ● Agent Granularity:Level of Complexity: Choose agents representing the fundamental level of interaction for the phenomenon (e.g., cells for tumor spread, humans for disease transmission between people).^1 ○ Temporal/Physical Scale Consistency: Ensure agent granularity is roughly consistent in time and physical scale (e.g., don't model sheep actions in days and grass in minutes if they are tightly coupled).^1 ● Proto-agents: For entities that might become full agents later, design them as proto-agents (inheriting characteristics from a global type, without full individual properties/behaviors). Example: a hunter in the Wolf Sheep model initially just removing a percentage of the population.^1 ● Wolf Sheep Simple Agents: Wolves (predators), Sheep (prey), and Grass (resource) are chosen, adhering to the principle of starting simple.^1

Section 11.6: Choosing Agent Properties (Module 115)

Properties distinguish agents and describe their state.^1

Wolf Sheep Simple Properties:Energy level: Tracks vitality (for sheep and wolves). ○ Location: Agent's position. ○ Heading: Direction of movement (for sheep and wolves). ○ (Grass-amount for grass)^1 These are abstractions of complex biological details, chosen for simplicity relevant to the research question.^1

Section 11.7: Choosing Agent Behavior and Parameters (Modules 116-117)

Behaviors describe how agents interact with each other and the environment. Parameters allow control over the model to examine different conditions.^1

Wolf Sheep Simple Behaviors: ○ Shared by Sheep & Wolves: Turn randomly, move forward, reproduce, die. ○ Sheep-specific: Consume grass. ○ Wolf-specific: Consume sheep. ○ Grass-specific: Regrow. These are reasonable choices for a simple model addressing the research question.^1 ● Wolf Sheep Simple Parameters (Module 117): ○ Initial number of sheep and wolves.

○ Move cost (energy expended). ○ Energy gain from grass (for sheep). ○ Energy gain from sheep (for wolves). ○ Grass regrowth rate.^1 ● Homogenous vs. Heterogeneous Parameters: Initially, these parameters are homogenous (same for all agents of a type). They could be made heterogeneous (e.g., energy gain drawn from a normal distribution for each sheep).^1

Section 11.8: Summary of the Wolf Sheep Simple Model Design (Module 118)

A summary document is useful for recalling design decisions and explaining the model to others.^1

Driving Question: Under what conditions do two species sustain oscillating positive population levels in a limited geographic area when one species is a predator of the other and the second species consumes limited but regenerating resources from the environment? ● Agent Types: Sheep, Wolves, Grass. ● Agent Properties: Energy, Location, Heading (wolf and sheep), Grass-amount (grass). ● Agent Behaviors: Move, Die, Reproduce (wolf and sheep), Eat-sheep (wolf only), Eat-grass (sheep only), Regrow (grass). ● Parameters: Number of Sheep, Number of Wolves, Move Cost, Energy Gain From Grass, Energy Gain From Sheep, Grass Regrowth Rate. ● Time Step Sequence:

  1. Sheep and Wolves Move
  2. Sheep and Wolves Die
  3. Sheep and Wolves Eat
  4. Sheep and Wolves Reproduce
  5. Grass Regrows ● Measures: Sheep Population versus Time, Wolf Population versus Time. Dated notes and answers to guiding questions (e.g., principal agent types, environment, properties, actions, interactions, time step events, expected observations) are recommended, especially for top-down design.^1

Section 11.9: Examining a Model (Module 119) and Multiple Runs (Module 120)

Once a model is built and a set of parameters is found that exhibits the reference pattern, further examination is needed.^1

Limitations of Single Runs: Due to stochastic components in ABMs, a single run

predicting extinctions, which occur more frequently than equations suggest.^1

Section 12.2: Advanced Modeling Applications in Ecology (Module 122)

ABM continues to be a vital tool in ecological research.^1

Modeling Food Webs: Combines ABM with network analysis to understand the structure of ecological interactions and the processes of animal interactions, offering deeper insights into overall ecological systems.^1 ● Prescriptive Design of Engineered Systems: ABM is used to design interventions to ameliorate human impact on the environment. Example: modeling fish populations and the effect of fish ladders near dams on salmon populations (Weber et al.).^1 ● Modeling Evolution: Ecological models underpin models of evolution. ABM is frequently used to model organism evolution, as natural selection and other mechanisms can be viewed as computational algorithms. This helps in understanding adaptation and speciation.^1

Section 12.3: The Core Components of Agent-Based Modeling (Module 123)

The main components of any ABM are agents, environment, and interactions. Two additional components are the observer/user interface and the schedule.^1

Agents: Basic ontological units of the model. ● Environment: The world in which agents live and act. The distinction can be fluid, as the environment can sometimes be modeled as agents. ● Interactions: Occur between agents or between agents and the environment. Agent actions can also be internal (affecting only the agent's state, e.g., deciding if unhappy in Segregation model). The environment can also act autonomously (e.g., grass regrowing). ● Observer/User Interface: The Observer is an agent with access to all other agents and the environment, asking them to perform tasks. The User Interface allows users to interact with the model by telling the observer what to do (e.g., NetLogo's SETUP and GO buttons). ● Schedule: What the observer uses to tell agents when to act, often involving user interaction. The Traffic Basic model (cars as agents, road as environment, interactions leading to jams) illustrates these components.^1

Section 12.4: Agents Revisited (Module 124)

This module delves deeper into the design and characteristics of agents.^1

Properties and Actions (Behaviors): The two main aspects defining agents. Properties are their internal/external state (data/description). Actions are what they can do.^1 ○ NetLogo Default Properties: Turtles, patches, and links have standard built-in properties (e.g., WHO, COLOR, XCOR for turtles; PXCOR, PCOLOR for patches).^1 ○ Author-Defined Properties: Modelers add custom properties relevant to their model (e.g., SPEED, SPEED-LIMIT in Traffic Basic).^1 ● Agent "Grain-size": Choosing the right level of complexity for agents is crucial. It should represent the fundamental level of interaction pertaining to the research question. Example: Tumor model uses cells as agents (cell-level interaction is key), while an AIDS model might use humans as agents (human-level interaction for disease spread).^1 ● Agent Cognition: The decision-making process of agents. ○ Reflexive Agents: Simple if-then rules (e.g., Traffic Basic cars slowing down if a car is ahead).^1 ○ Utility-Based Agents: Maximize a utility function (e.g., cars adjusting speed for fuel efficiency).^1 ○ Goal-Based Agents: Act to achieve specific goals (e.g., cars in Traffic Grid navigating from home to work).^1 ○ Adaptive Agents: Can change their strategies based on prior experience (learn).^1 ● Other Kinds of Agents:Meta-agents: Agents composed of other sub-agents (e.g., a human composed of body systems or psychological aspects). Useful for modeling systems at multiple levels of granularity.^1 ○ Proto-agents: Placeholder agents for future development, allowing interaction specification with focal agents even if the proto-agent isn't fully defined (e.g., service centers in a residential model initially just representing job locations).^1

Section 12.5: Agent Properties and Behaviors (Module 125)

This module provides a consolidated look at agent properties and behaviors, which are fundamental to defining agents in ABM.

Properties: As detailed in Module 124, properties define an agent's state. These include both built-in properties provided by the modeling environment (like NetLogo's XCOR, YCOR, COLOR for turtles) and custom properties defined by the modeler to capture specific characteristics relevant to the simulation (e.g., energy