demo: multi-step reasoning patterns (CoT / ReAct / ReWOO plan-caching) as NetLogo modeling patterns

Summary

Add a demo (plus reusable YAML templates) showing multi-step reasoning patterns — Chain-of-Thought, ReAct, and especially ReWOO plan-caching — implemented purely as NetLogo modeling patterns on top of existing primitives.

No extension changes required. This is a demo + template + documentation deliverable. Research and planning still to be done.

Motivation

mesa-llm (the LLM layer for Mesa, the Python ABM framework) ships three swappable reasoning strategies as framework classes: CoTReasoning, ReActReasoning, ReWOOReasoning. This reframes reasoning strategy as an experimental variable — hold the model fixed, vary cognition — which is a genuinely useful research affordance we do not currently offer.

Reading their source (local clone at HEAD 57a51ff), these strategies turn out not to be architecture. Each is a prompt template plus a small amount of agent-side state. That means they port to NetLogo as modeling patterns.

ReWOO is the valuable one

ReWOO (Reasoning WithOut Observation) generates a multi-step plan in one LLM call, then replays the cached steps across subsequent ticks with zero LLM calls until the plan expires.

Their implementation is two fields on the agent (mesa_llm/reasoning/reasoning.py:47-55):

@dataclass
class Plan:
    step: int          # step when the plan was generated
    llm_plan: Any      # complete LLM response
    ttl: int = 1       # steps until planning again (ReWOO sets >1)

and the replay path (mesa_llm/reasoning/rewoo.py:146-157):

if self.remaining_tool_calls > 0:
    index_of_tool = len(self.current_plan.tool_calls) - self.remaining_tool_calls
    self.remaining_tool_calls -= 1
    ...
    return Plan(llm_plan=current_plan, ttl=ttl, ...)   # zero LLM calls

Nothing there depends on Python, Pydantic, or LiteLLM. In NetLogo it is a turtle-own plan list plus a countdown:

turtles-own [ plan-steps plan-ttl ]

to go
  ask turtles [
    if plan-ttl <= 0 [ make-plan ]      ;; 1 LLM call
    execute-next-step                    ;; 0 LLM calls
    set plan-ttl plan-ttl - 1
  ]
  tick
end

Why this matters for us specifically

Cost per agent per tick:

Approach	LLM calls / agent / tick
mesa-llm (any strategy)	2–3 (reason, then bind to tool calls, plus memory consolidation)
Ours today (reactive llm:chat / llm:choose)	1
Ours with ReWOO (ttl=5)	0.2

mesa-llm's own issue #200 reports their design is "unsuitable for large-scale agent simulations... exponential degradation beyond ~10 agents" (20 agents ≈ 3 min/step, 50 ≈ 15+ min/step). Plan-caching moves in the opposite direction — it makes more agents feasible, which plays directly to where this extension is already strong.

Proposed scope

1. Demo model — a resource/foraging or trading scenario where planning ahead is visibly better than reacting. Sugarscape-style is a natural fit and is directly comparable to their sugarscrap_g1mt example.
2. Interface switch for reasoning mode: reactive / cot / rewoo, with a monitor showing cumulative LLM calls so the cost difference is visible while the model runs.
3. YAML templates — cot-template.yaml, rewoo-plan-template.yaml in demos/templates/, reusable outside this demo.
4. Docs — a short "reasoning patterns" section covering when planning beats reacting, and the cost tradeoff.

Open questions (for the planning phase)

• Plan parsing. Getting N ordered steps out of a free-text response currently needs substring/position gymnastics in NetLogo, and llm:choose cannot help (exact-match-or-throw on a single option). This works today but is brittle; #22 (structured output) would make it robust. Decide whether to ship the brittle version first or wait.
• Replanning triggers. Their ttl is a fixed countdown. A contingency check ("has the world changed enough to invalidate my plan?") may be more interesting scientifically, and is cheap in NetLogo.
• What to measure. Task performance vs cumulative LLM calls, across reasoning modes, at several agent counts. This is the publishable comparison if it holds up.

Not in scope

Porting their tool-calling architecture. Their @tool decorator relies on Python type-hint and docstring introspection, which has no NetLogo equivalent. The llm:choose + NetLogo dispatch pattern already provides the same guarantee (invariants enforced in model code, not prompts).

Start by reviewing the cited mesa-llm reasoning files and the existing reactive llm:chat / llm:choose patterns. Define the demo model, reasoning-mode switch, cumulative-call monitor, templates in demos/templates/, and documentation scope before implementation. Done means the demo compares reactive, CoT, and ReWOO behavior and cost, with reusable YAML templates and explanatory docs.