Two different things called “agents”
“Agent” has bifurcated: it refers both to autonomous LLM-driven assistants and to the computational entities in simulation frameworks, with little overlap between the two. 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?
Population-level phenomena emerge naturally from ABM when you define local rules for individual actors and let interaction dynamics produce macro patterns. 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?
Three conditions favor ABM over alternatives: emergent system-level behavior that no single entity controls, actor strategies that evolve heterogeneously over time, and counterfactual policy tests with no historical analog. 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
An LLM agent orchestrates tasks or answers queries; it does not simulate thousands of interacting entities over time. 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
Hybrid architectures—ABM for population dynamics, LLMs for natural-language scenario specification—deliver results neither approach achieves alone. 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. Wiring that hybrid correctly — deterministic simulation plus a generative reasoning layer — is exactly the kind of system our Generative & Agentic AI R&D practice designs.
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.
Why Simulation Fidelity Matters More Than You Think
ABM outputs degrade smoothly under most perturbations, then collapse abruptly when parameter drift crosses a critical threshold; catching that transition early is the operational challenge. That answer is workload-specific, and it is worth writing down before you build.
