Agent-Based Modeling Theory

The Concept

Agent-Based Modeling simulates individual agents that interact with their environment. Instead of aggregate statistics, you model each person’s decision.

Source: Wilensky, U. & Rand, W. — An Introduction to Agent-Based Modeling (MIT Press, 2015)

Data Requirements

Dataset	What We Use	Link
Current Weather (HKO)	Foot traffic modifier (rain/heat reduces outdoor movement)	View →
Rainfall Nowcast	Real-time rain events triggering agent shelter-seeking behaviour	View →
MTR Ridership	Calibrate agent arrival/departure waves at transit nodes	View →
Census Population	Base agent population per zone	View →
Traffic Detectors	Vehicle flow validation for agent movement	View →
A&E Wait Times	Population density proxy for validation	View →
Consumer Price Index	Agent spending parameters calibrated to current prices	View →

Classical ABM

Traditional agents follow rule-based logic:

IF distance < 400m AND price < budget AND cuisine_matches:
    visit_probability = base_rate * distance_decay * preference_weight
    IF random() < visit_probability: VISIT

Strengths: Fast, reproducible, can simulate millions of agents. Weakness: Rules are brittle. Real humans weigh tradeoffs, mood, weather, social context.

Three Design Principles (Wilensky & Rand, Ch. 3)

1. Heterogeneity — Agents differ in meaningful ways: income, location, preferences, habits.

2. Autonomy — Each agent decides based on its own perception. An office worker sees “many competitors nearby” as options; a shop owner sees saturation.

3. Interaction — Agents influence each other. Mrs. Cheung only visits if neighbors recommend. Jenny only visits if friends post on Instagram.

What Emerges

ABM reveals emergent patterns that no single formula predicts:

Network effects from word-of-mouth
Tipping points where a restaurant goes from unknown to popular
Conflicting requirements that make serving all segments impossible

Implementation Notes

Current Implementation (2026-03-25)

Persona mix (5 personas, weights sum to 1.0):

Persona	Weight	Sample Size
Office Worker	30%	30 agents
Local Resident	30%	30 agents
Tourist	15%	15 agents
Foodie/Expat	15%	15 agents
Family	10%	10 agents

Simulation runs: 100 runs per analysis call. overallVisitRate = sum(visitRate × sampleSize) / 100.

Visit rate formula (per persona): huffBase × cuisineMatch × targetMatch × priceFit × distanceFit × noise

Multiplier values:

huffBase: Huff model capture probability (from calcHuff); serves as the base visit rate anchor
cuisineMatch: 1.0 if persona preferences overlap with restaurant cuisine, 0.3 if not
targetMatch: 1.2 if persona type is in targetCustomers, 0.8 if not targeted
priceFit: 1.0 if persona’s income supports the price band, 0.4 if priced out
distanceFit: decays from 1.0 (at 0m) toward 0.2 as distance increases
noise: random multiplier in [0.8, 1.2] range providing run-to-run variance

Emergent insights: After simulation, the model generates contextual insight strings based on results:

Best-performing and worst-performing persona (with visit rate %)
If competitors.total > 30: “High competition triggers price-war behaviour”
If overallVisitRate > 0.3: “Strong overall attraction suggests potential queue/wait times”
If overallVisitRate < 0.1: “Low visit rate suggests concept-market mismatch”
If cuisineTypes.length > 2: “Multi-cuisine concept appeals to broader agent pool but may dilute brand identity”

Changelog

Date	Change	Why
2026-03-25	Visit rate formula changed from flat 2% to `huffBase × cuisineMatch × targetMatch × priceFit × distanceFit × noise`	All locations returned ~2% regardless of inputs; needed Huff capture rate as base anchor
2026-03-25	Emergent insights generation added	Results were returning raw numbers with no interpretation; contextual strings improve UX
2026-03-25	100 simulation runs formalized	Single-pass output was unstable; 100 runs and weighted averaging provides stable estimates
2026-03-24	Initial implementation	Visit rates undifferentiated (~2% everywhere); architecture established, calibration needed