ITERATION LOOP (until it matches or max iterations):

STEP 1 — Generator: 
Task → Code/instructions (first version or a version fixed per feedback)

STEP 2 — Simulator:
Code/instructions → Static simulation → Semantic description of the outcome

STEP 3 — Evaluator:
Description + Task → Find mismatches → Feedback (if there are errors)

→ If there is feedback: go back to STEP 1 to correct
→ If there are no mismatches: the final result is ready

All three steps need separate LLM calls. Each agent is its own prompt with its own role.

Task: Sanity-check a launch plan for a new product on Amazon before actually going live. Lots of steps (photos, listing copy, price, inventory shipment, ads), and a mistake at any stage means lost money and time.

Prompt for the Generator:

Create a step-by-step launch plan for the product "Self-Heating Travel Mug" on Amazon.
Launch budget: $2,000.
Goal: break into the top 100 of the category within a month.

Prompt for the Simulator:

You are a business-process simulator. Read this Amazon launch plan:

[paste the plan from the Generator]

Describe in words what will happen at each step:
- What resources get spent
- What results we get
- What state we end up in after each action

Format: a step-by-step description of the trajectory from start to finish.

Prompt for the Evaluator:

Compare this plan and its simulation against the goal "break into the top 100 on Amazon within a month on a $2K budget".

Plan: [paste the plan]
Simulation: [paste the description from the Simulator]

Find the mismatches:
- Where will the actions fail to reach the goal?
- Where does the budget not cover the costs?
- What was forgotten or done wrong?

Give specific feedback for the fix.

Result:

The three agents run in a loop (in separate chats or one after another in the same one). The Generator writes the plan → the Simulator describes what will happen ("after $1K on ads the product sits at rank 150, not in the top 100") → the Evaluator spots the mismatch ("the budget is split wrong: too much on photos, too little on promotion"). The Generator fixes it. After 2-3 iterations you have a vetted plan without paying real money for the mistakes.

The LLM's weakness: A model often generates plausible but wrong instructions. Ask for a plan and you get a nicely written text full of logical holes. The LLM doesn't see the consequences of its own advice unless you explicitly ask it to.

The LLM's strength: A model reasons about cause and effect really well once you give it context and a role. "Read this code and describe what will happen" — and the LLM traces the execution logic step by step. A semantic description ("the drone will fly east instead of north") is easier to grasp than numbers ("Y=5 instead of X=5"), which makes errors easier to find.

How the method uses that strength: It splits the roles — the Generator creates without the pressure of checking, the Simulator thinks only about consequences, the Evaluator compares with the goal without generating anything new. Each agent does one job well. Static simulation is faster and cheaper than real execution (no robot, simulator or running code needed), yet it delivers the same level of insight through a text description.

Control knobs:

• Number of iterations — lower it for simple tasks (2-3 is enough), raise it for complex ones (5-7 for multi-step processes)
• Simulation detail — ask the Simulator to "describe every step in detail" or "only the key transitions" (saves tokens)
• Evaluator strictness — say "find any deviation" or "only critical errors"
• Feedback format — "specific edits" vs "general recommendations"

For the Generator:

Create a {instruction type: plan/algorithm/code} for the task: {task description}.

Requirements:
{specific constraints: budget/time/resources}

Goal:
{desired outcome}

Format: step-by-step instructions with explanations.

For the Simulator:

You are a process simulator. Read these instructions:

{paste the instructions from the Generator}

Describe in words what will happen at each step:
- What the state is before the step
- What the step does
- What the state is after the step
- What resources are spent

Format: a semantic description of the trajectory from start to finish. No execution — only analysis of the text and prediction.

For the Evaluator:

Compare the instructions and their simulation with the goal of the task.

Task: {task description}
Goal: {desired outcome}

Instructions: {paste from the Generator}
Simulation: {paste from the Simulator}

Find the mismatches between the simulation and the goal:
- Where will the actions fail to produce the result?
- What was forgotten or done wrong?
- Which steps violate the constraints?

Give specific feedback for the fix. If there are no mismatches, write "Ready to execute".

Placeholders: - {instruction type} — a launch plan, a data-processing algorithm, a script - {task description} — what needs to be done - {specific constraints} — budget, time, resources, technical requirements - {desired outcome} — the success criterion

🚀 Quick start — paste this into the chat:

Here is a template for static simulation with three agents (Generator → Simulator → Evaluator). 
Adapt it to my task: [your task]. 

Ask me questions so you can fill in the agents' roles for my context.

[paste the three templates above]

The LLM will ask about your task, constraints and success criteria — because every agent needs to know the context. It will take the three-agent pattern and build prompts specific to your situation. You end up with three ready-to-go prompts to run the checking loop.

⚠️ Simulation accuracy: The LLM simulator reaches 97.5-100% accuracy, but it isn't perfect. On complex multi-step processes involving arithmetic or scientific knowledge it can get predictions wrong. Double-check the critical steps.

⚠️ Cost of iterations: Three agents x several iterations = lots of tokens. For simple tasks it can be overkill — use it when the cost of a mistake is high (money, time, safety).

⚠️ Multi-call workflow: You have to copy outputs between agents by hand or use separate chats. It's not one message — it's a full process.

⚠️ Not for expert domains: If the task needs deep expertise (medicine, law, engineering), the simulation can miss non-obvious errors — an LLM won't replace a specialist.

Researchers from the University of Massachusetts and California State University tested the idea on drone control — tasks where a mistake is expensive (a crashed drone). They took 20 hard tasks like "fly a 5x5 meter square, turning perpendicular on each side" (6-19 actions per task).

They compared four approaches: 1. Direct — the LLM analyzes the code directly and gives feedback (no simulation) 2. Numerical — a real drone simulator outputs coordinate numbers (X=5, Y=0, Z=2) 3. Semantic (SOTA) — a real simulator + translating the numbers into text ("flew 5 meters north") 4. Their method — an LLM simulator outputs a text description with no real execution

The surprise: the LLM simulator, without actually running the code, showed the same accuracy as a real simulator with semantic translation (Success Rate 85-93%, Completeness 97-98%). The Direct method flopped (33-55% SR) — proof that an LLM can't reliably check code by eyeballing it; it needs the simulation.

The key practical insight: semantics ("flew the wrong way") exposes errors better than numbers ("Y=5 instead of X=5") — even an experienced human finds "flew east instead of north" easier to grasp. With such descriptions the LLM finds 90-93% of errors vs ~70% with direct analysis and no simulation.

Why they reached these conclusions: LLMs are good at reasoning about consequences ("if you turn 90° and fly along Y, you'll end up further east") but bad at directly checking logic ("is this code written correctly?"). Splitting the roles (create → simulate → evaluate) plays to the strengths and sidesteps the weaknesses.

They tested on two different systems (a simple AirSim controller + the more advanced PX4) and two models (o3-mini, o4-mini) — the results held steady, so the principle works across the board.

🔧 Technique: One agent instead of three → a lightweight check

For simple tasks (5-10 steps) you can merge all the agents into one prompt:

Create a plan for: {task}

Then:
1. Simulate the execution (describe what will happen at each step)
2. Compare the simulation with the goal
3. Find the errors and fix the plan

Give me the final version with an explanation of what you fixed.

Effect: Faster (one call instead of a loop), but less reliable — without explicit role separation the LLM can miss non-obvious errors. Good enough when the cost of a mistake is low.

🔧 Technique: Add a "pessimist" simulator → sharper criticism

Run two simulators in parallel — an optimist and a pessimist:

Optimist simulator: Describe what will happen if everything goes according to plan.
Pessimist simulator: Describe what will go wrong — which risks and failures are possible at each step.

The Evaluator gets both versions and gives deeper feedback.

Effect: Uncovers non-obvious risks that a single simulator would miss. Useful for high-stakes tasks (money, safety, reputation).

🔧 Technique: Numeric checkpoints in the simulation → debugging complex processes

Ask the Simulator to add concrete metrics to the semantic description:

At each step, state:
- Semantics: what is happening, in words
- Metrics: budget remaining, time spent, progress toward the goal (%)

Sample output: "Step 3: Launched ads (semantics: impressions started in Amazon search). Spent $600 of $2K, $1.4K left. Progress toward the top 100: we expect 20% within a week."

Effect: You see not only WHAT is happening but also HOW CLOSE you are to the goal. Makes it easier to spot bottlenecks in long processes.

LLM-Driven Corrective Robot Operation Code Generation with Static Text-Based Simulation

Authors: Wenhao Wang, Yi Rong, Yanyan Li, Long Jiao, Jiawei Yuan
Affiliations: University of Massachusetts Dartmouth, California State University San Marcos

Submitted to IEEE (2025)