26주 동안 마을 경제를 운영하는 100명의 LLM 에이전트: 에이전트가 가격을 설정하고 임금을 받을 때 깨지는 점

A team placed 100 memory-equipped LLM agents in a closed economy simulation on real Pokhara Lakeside geography and ran it for 26 simulated weeks. The agents earned wages, ran businesses, and set prices autonomously. Across 91 validated runs (2.44M agent decisions, 21.5B tokens), the money stopped moving in a specific, measurable way.

This is the first published multi-agent economic simulation that runs beyond 1-2 weeks into 26-week territory. It exposes coordination, state management, and failure modes invisible in shorter runs.

The Plumbing Problem

Most agent simulations run for a few days or weeks. This one needed to maintain:

• Monetary conservation: No external capital injection. Every transaction must balance across 100 concurrent agents without a central ledger lock.
• State persistence: Agent business decisions must remain coherent across 26 simulated weeks.
• Observability: Surface emergent inflation, wage spirals, or market collapse before the simulation diverges.
• Deadlock detection: Handle cases where agents set prices that prevent market clearing.

The simulation used real geography (Pokhara Lakeside) with spatial constraints. Agents moved between locations, interacted with businesses, and made economic decisions based on memory and current state.

What Actually Happened

The money stopped moving. A 12x tourist demand shock raised business revenue 4.62x (p<0.001), decomposed exactly into:

• 1.50x extensive margin (more businesses trading)
• 3.07x intensive margin (more revenue per business)

Monetary transmission stopped there:

• Wages moved 1.03x (p=0.42, statistically indistinguishable from zero)
• 0.3% of 3,981 menu items were ever repriced (p=0.47)

A randomized cash transfer (NPR 5,000 to 20 of 100 agents) showed the same pattern from the opposite direction:

• 96.7% of transferred cash still held 311 simulation pulses later
• Marginal propensity to consume 3-4% by two independent measures
• Indistinguishable from zero

The wealth distribution was near-frozen at the 2-week horizon typical of agent-society studies (ρ=0.964). But not frozen. ρ fell to 0.832 at 12 weeks and 0.752 at 26 weeks. This horizon-dependence is invisible in short runs.

Architecture: Memory, State, and Validation

The simulation ran on a multi-agent orchestration layer with these components:

Agent Memory Architecture

Each agent maintained:

• Transaction history (signed, append-only)
• Business state (inventory, prices, revenue)
• Wage history
• Spatial location and movement log

State Persistence

The system used two validation layers:

1. Live validator: Checked monetary conservation at each simulation pulse
2. Offline recomputation: Reconciled each agent’s wealth against its signed transaction history

Every headline number was verified twice. The full run corpus is released for reanalysis.

Orchestration Flow

# Simplified orchestration pulse
def simulation_pulse(agents, environment, pulse_id):
    # 1. Spatial resolution
    locations = resolve_agent_locations(agents, environment)

    # 2. Economic decisions (parallel)
    decisions = []
    for agent in agents:
        context = build_agent_context(agent, locations, pulse_id)
        decision = agent.llm_call(context)  # Tool calls for wage, price, purchase
        decisions.append(decision)

    # 3. Transaction settlement
    transactions = settle_transactions(decisions)

    # 4. Monetary conservation check
    assert sum(t.amount for t in transactions) == 0

    # 5. State update
    for agent in agents:
        agent.update_state(transactions, pulse_id)

    # 6. Observability
    log_metrics(agents, transactions, pulse_id)

    return transactions

Enter fullscreen mode Exit fullscreen mode

Tool Calls

Agents had access to:

• Economic tools (set_price, pay_wage, purchase, transfer)
• Social tools (chat, coordinate, negotiate)

Economic tools succeeded ~96% of the time across two model families. Social tools failed 94-97% of the time, with no measurable shift away from them despite repeated failures.

Failure Modes and Observability

Failure Mode Detection Method Frequency Impact Price rigidity Menu repricing rate 99.7% items never repriced Monetary transmission stops Wage stickiness Wage change distribution 1.03x movement (p=0.42) Revenue shock doesn’t propagate Hoarding Cash velocity, MPC 96.7% cash held Demand shock doesn’t clear Social tool failure Tool call success rate 94-97% failure Agents don’t coordinate Wealth freeze Spearman ρ over time ρ=0.964 at 2 weeks, 0.752 at 26 Short runs miss long-term dynamics

Observability Primitives

The team tracked:

• Transaction volume and velocity per pulse
• Price change frequency and magnitude
• Wage distribution changes
• Wealth concentration (Gini, Spearman ρ)
• Tool call success/failure rates
• Monetary conservation violations

These metrics surfaced the economic deadlock before the simulation diverged.

Model Swap Ablation

Swapping the backing LLM moved every outcome measured (p=0.0039). Deleting agents’ memory moved none of them detectably.

This is counterintuitive. Memory was expected to matter. It didn’t. The model family mattered more.

The team tested two model families:

• Family A: GPT-4 class
• Family B: Claude class

Both showed the same price rigidity and wage stickiness patterns, but at different magnitudes. The economic deadlock was model-invariant.

State Management Trade-offs

Approach Pros Cons Used Here Central ledger lock Strong consistency, no double-spend Serialization bottleneck, single point of failure No Optimistic concurrency High throughput, parallel execution Requires rollback, complex conflict resolution No Event sourcing + validation Auditability, replayability Storage overhead, validation latency Yes Distributed ledger Decentralized, tamper-proof High latency, coordination overhead No

The team chose event sourcing with dual validation (live + offline). This provided auditability and caught monetary conservation violations without serializing all transactions.

Security Boundaries

The simulation enforced:

• Transaction signing: Each agent signed its transactions with a private key
• Monetary conservation: Sum of all transactions must equal zero at each pulse
• Spatial constraints: Agents can only interact with businesses at their current location
• Tool call validation: Economic tools check balance before execution

No agent could:

• Create money out of thin air
• Transact with agents at different locations
• Modify another agent’s state directly
• Bypass the transaction settlement layer

Deployment Shape

The simulation ran on:

• 100 agent processes (one per agent)
• Central orchestration service (pulse coordination)
• State store (PostgreSQL for transaction history)
• Observability stack (Prometheus + Grafana)
• LLM API gateway (rate limiting, retries)

Resource Consumption

• 2.44M agent decisions
• 21.5B tokens processed
• 91 validated runs
• ~26 weeks simulated time per run

Token costs dominated. At $0.01/1K tokens (GPT-4 class pricing), each 26-week run cost ~$2,150 in LLM API calls.

Likely Failure Modes in Production

Token Budget Exhaustion

Long-running simulations hit token budget limits. The team had to:

• Compress agent memory (summarize old transactions)
• Prune irrelevant context
• Use cheaper models for routine decisions

Economic Deadlock

When agents set prices too high and wages too low, the market stops clearing. Detection requires:

• Transaction velocity monitoring
• Price/wage ratio tracking
• Deadlock alerts when velocity drops below threshold

State Divergence

Agent state can diverge from ground truth due to:

• LLM hallucinations (agent invents transactions)
• Concurrency bugs (race conditions in state updates)
• Validation failures (monetary conservation violations)

The dual validation layer caught these, but at the cost of 2x compute overhead.

Model Drift

LLM API updates can change agent behavior mid-simulation. The team:

• Pinned model versions
• Ran ablations when models changed
• Monitored tool call success rates for drift

Technical Verdict

Use this approach when:

• You need to study emergent economic behavior over weeks or months
• Monetary conservation and auditability are critical
• You can afford high token costs (21.5B tokens for 91 runs)
• You want to expose failure modes invisible in short runs

Avoid this approach when:

• You need real-time responsiveness (validation adds latency)
• Token budgets are tight (2.44M decisions per run)
• You need agents to coordinate socially (social tools fail 94-97%)
• Short-term dynamics are sufficient (2-week runs miss long-term patterns)

The key insight: memory didn’t matter, but model choice did. Price rigidity and wage stickiness are model-invariant patterns. If you’re building multi-agent economic simulations, test across model families early. The economic deadlock will surface regardless of memory architecture.

Source Links

• ArXiv Paper
• PDF
• Dataset and analysis code: Available at paper link