Two different things called “agents” The word “agent” in AI now carries two distinct meanings that get conflated regularly. Agent-based modeling (ABM) refers to simulation systems where autonomous entities — agents — interact according to local rules, and emergent behaviour at the system level arises from those local interactions. LLM-based agents, by contrast, are systems where a language model makes decisions, calls tools, and operates with some degree of autonomy to complete tasks. The two share a vocabulary, but they are different tools for different problems, and conflating them is how teams end up building a LangChain workflow when what they actually needed was a population simulation. This article is for engineering leads and architects deciding which approach fits a given problem. We will draw the boundary, walk through where each method is appropriate, and look at the hybrid pattern that is becoming common in production work. What is agent-based modeling? Agent-based modeling is a computational method for simulating complex systems by modelling individual actors and their interactions. Each agent has a state (its current properties), a set of behaviours (rules governing how it responds to conditions), an environment it perceives and acts within, and interactions with other agents and that environment. The power of ABM is emergence: system-level behaviour that is not explicitly programmed but arises from agent interactions. Classic examples include traffic flow models, epidemiological spread models, and supply chain disruption simulations. ABM has existed since the 1990s, and tools like NetLogo, Mesa (Python), and AnyLogic are purpose-built for it. This is not a new LLM capability — it is a mature simulation discipline that predates modern deep learning by a decade. LLM-based agent frameworks, by comparison, are recent. They use transformer-based reasoning (often served through PyTorch or ONNX-optimised inference stacks) to interpret instructions, call tools, and chain steps together. The agent here is not one of many — it is typically one or a small handful of reasoning entities orchestrating a task. The unit of analysis is decision quality on a single trajectory, not emergent behaviour across thousands of trajectories. When does agent-based modeling outperform traditional ML or LLM agents? ABM outperforms both traditional ML and LLM-based agents in three scenarios: when system behaviour emerges from interactions between entities, when the entities have heterogeneous strategies that change over time, and when you need to evaluate interventions that have no historical precedent. The table below is the decision surface we use when scoping these projects. Use case ABM appropriate LLM agents appropriate Epidemiological spread modelling Yes — thousands of heterogeneous agents No Supply chain disruption simulation Yes — supplier/manufacturer/retailer interactions No Traffic flow and urban planning Yes — vehicle behaviour at scale No Customer behaviour simulation Yes — market dynamics with many agents Yes — for qualitative scenarios Warehouse robotics optimisation Yes — fleet coordination simulation Yes — for task planning AI task automation workflow No Yes — core use case Traditional ML excels at learning patterns from historical data. But historical data cannot tell you what happens under conditions that have never occurred. ABM can: you define the agents’ decision rules, run the simulation under novel conditions, and observe the emergent system behaviour. This is why ABM is used for pandemic modelling, market regulation analysis, and urban planning — scenarios where policy decisions create conditions that have no historical analogue. In our experience, the “what would happen if” framing is the cleanest filter: predictive questions with stable conditions suit ML; counterfactual questions about interventions suit ABM. ABM is the right choice when the system has many interacting entities (dozens to millions), individual behaviour rules are well-defined, system-level behaviour is what needs to be studied, stochastic variability between runs is informative, and computational reproducibility matters. Why “multi-agent AI” gets confused with ABM LLM-based agents are not running population simulations. They are using language model reasoning to make decisions, use tools, and complete tasks. The terminology overlap creates confusion in projects where teams hear “multi-agent AI” and default to building LangChain or LangGraph workflows when the actual requirement is a population simulation. We see this confusion appear most often in three project shapes: Supply chain optimisation — ABM for simulating the network, LLMs for analysis and exception handling. Customer behaviour modelling — ABM for scale and emergent market dynamics, LLMs for individual-level qualitative scenarios. Logistics planning — ABM for fleet simulation, LLMs for exception handling and re-planning. The structural cue is whether the project’s value sits in studying the system or in executing one trajectory through it. If a stakeholder asks “what does our network look like under stress?”, that is an ABM question. If they ask “how should this one shipment be routed given the disruption?”, that is an LLM-agent question — possibly inside a broader multi-agent orchestration layer where several reasoning agents coordinate to resolve the exception. Combining ABM and LLM agents in production The more interesting pattern, and the one we see succeed in production, is combining both. Use ABM for large-scale simulation (thousands of entities with rule-based behaviour) and LLM-based agents for the reasoning and adaptation layer — particularly for handling edge cases, exceptions, and policy updates that don’t fit rigid rules. A supply chain model might simulate ten thousand suppliers and retailers using ABM rules for normal operations, while an LLM agent handles anomaly detection, escalation decisions, and re-planning when disruptions occur. The ABM runs on a deterministic simulation engine; the LLM agent runs on a separate inference service (often containerised behind Docker or Kubernetes, with the model itself served through TensorRT or vLLM for latency-sensitive paths). The two systems communicate through a narrow contract: the simulation emits state, the LLM agent emits decisions, and a coordination layer reconciles them. The weakness of pure ABM is calibration: the agents’ decision rules and parameters must be specified by domain experts or calibrated against observed data. If the rules are wrong, the simulation’s predictions are wrong. We address this by combining ABM with ML: use ML to learn agent decision rules from observed behavioural data, then use ABM to simulate system-level outcomes under novel conditions. This hybrid leverages ML’s ability to learn from data and ABM’s ability to extrapolate beyond observed conditions — and where appropriate, the LLM layer sits on top of both, handling the cases neither the learned rules nor the simulation engine were designed for. FAQ How do multi-agent systems break in production? The common failure modes are coordination cascades (one agent’s wrong output is consumed as truth by the next), deadlocks (agents wait on each other indefinitely), and behavioural drift (agents adapt to each other’s outputs over time and converge on degenerate strategies). ABM systems fail mostly through calibration errors; LLM-agent systems fail mostly through prompt and tool-contract erosion. This is a feasibility question more than a tooling question: deciding whether multi-agent architecture is justified at all, before designing the orchestration layer, is where most over-engineering enters these projects.
