The Task-State Ladder: Explicit Commands and Self-Tracking Beat Passive Status Checklists

Researchers tested four ways to tell an AI agent where a multi-step task currently stands — from a casual mention in the conversation to a hard block on incorrect actions — and found that the more actively the status is communicated, the more reliably the agent behaves. Just "telling" the model a fact is weak. "Commanding" the model what to do right now is strong.

The core pain point: even when models are shown an accurate, always up-to-date checklist of statuses ("step 3: done," "step 5: blocked"), they still mess up — redoing an already-completed step if the user simply mentions it again with a new order number, without an explicit "redo this." Even more surprising: if you ask the model to keep its own status ledger (with zero correctness checking), it performs better than when it's shown an accurate external checklist.

The method is a four-rung "ladder" connecting state to behavior: (1) status exists only in the conversation history, (2) an accurate checklist is shown, (3) a direct command precedes every action — something like "this step is DONE — don't redo it," (4) incorrect actions are blocked at the tool level. The jump from rung 2 to rung 3 — from showing to commanding — produces the biggest leap in reliability, and it's a pure prompting trick, no code required.

Method Blueprint

RUNG 1 (weak): Status lives only in chat history → the model often confuses "mentioned" with "do it again"
RUNG 2: An accurate status checklist is inserted into every message → better, but errors remain
RUNG 3 (usable in chat alone): Before each action, an explicit command based on status:
   "step X: DONE — don't redo it" / "step Y: BLOCKED — don't do it, name what's needed first" / "step Z: AVAILABLE — do it now"
   → error rate drops sharply
RUNG 4 (needs code/tooling): Hard block on incorrect actions at the system level → near-zero errors, but requires an external mechanism
BONUS (pure chat trick): Self-tracking — ask the model to maintain and print its own status ledger every turn, with no verification → outperforms even an accurate external checklist

Example in Action

Task: You're running a product launch on Amazon through an AI assistant acting as your virtual project manager. The stages: order samples from the factory → finalize the contract → shoot product photos → upload the listing → launch ads. The conversation spans several days, out of order: sometimes you ask about a stage that's already done, sometimes you cancel a step, sometimes you ask for a redo.

Prompt:

You are my project assistant for launching a product on Amazon. Track the status of these stages:

1. Order samples from the factory [completion code: O-101]
2. Finalize the contract with the factory [O-102] (requires: 1)
3. Shoot product photos [O-103] (requires: 2)
4. Upload the listing to Amazon [O-104] (requires: 3)
5. Launch ads [O-105] (requires: 4)

Rules:
- Each stage is completed EXACTLY ONCE.
- If I mention an already-completed stage again without the word "redo" — just confirm it's done, don't run it again.
- If a stage is blocked (prerequisites not met) — don't run it, explain what needs to happen first.
- If a stage is canceled — refuse to run it, even if I bring it up again.

Before executing or refusing any of my messages, first state explicitly, on one line:
STATUS: {stage} — {AVAILABLE, executing / ALREADY DONE, not redoing / BLOCKED, waiting on {what} / CANCELED, refusing}

After the status line — execute or refuse, and always print your ledger at the end:
LEDGER:
1: ..., 2: ..., 3: ..., 4: ..., 5: ...

My message: "Hey, take care of the product photos, here's a new order #4521"

Result: The model will first output a STATUS line, explicitly stating whether the stage is available or already done. If the stage was already completed earlier (even under a different order number), it will confirm that and won't redo it — because the instruction explicitly requires stating the status first, rather than jumping straight to action. At the end, it prints an updated ledger for all five stages, which the model maintains itself and will reference in subsequent messages.

Why This Works

LLM weakness: models are bad at connecting information they've seen to the behavior it implies. Seeing "step 3: done" on a checklist and then refusing a new action when the user asks about that same step again — these are two separate cognitive steps, and the model often stumbles between them. It reads the status but doesn't necessarily draw the right conclusion about what to do right now.

LLM strength: models are excellent at following direct commands. When, instead of a status description, they're told "don't redo this" or "do it now" — that's already a finished conclusion, not a task requiring them to draw one. Less room for misinterpretation.

The method strips out the intermediate reasoning step: instead of "here's a fact, draw the right conclusion," it's straight to "here's the conclusion, act on it." Self-tracking works similarly: when the model generates and records its own status, it essentially "commits" to that status — and is more likely to honor it next time than when the status is simply handed to it from outside.

Control lever: you can tailor the command wording to your task — swap "AVAILABLE/DONE/BLOCKED" for your own status categories (e.g., "needs approval," "in progress," "overdue"). Drop the ledger requirement if you don't want to clutter the output — but accuracy will suffer.

Prompt Template

You are my project management assistant for "{project name}". Track the status of these stages:

{list of stages with dependencies and completion codes}

Rules:
- Each stage is completed {how many times} time(s).
- If I mention an already-completed stage again without an explicit "redo" — confirm it's done, don't run it again.
- If a stage is blocked — don't run it, explain what needs to happen first.
- If a stage is canceled — refuse to run it.

Before acting, first state on one line:
STATUS: {stage} — {AVAILABLE / ALREADY DONE / BLOCKED / CANCELED}

Then execute or refuse. At the end, always print your ledger for all stages.

My message: {request}

Placeholders: {project name} — the gist of the task; {list of stages} — your steps and what each depends on; {how many times} — usually "one"; {request} — the user's current message.

🚀 Quick Start — paste into the chat:

Here's a task status-tracking template. Adapt it to my project: {your task}.
Ask me questions to fill in the fields.

[paste the template above]

The model will ask about your stages and their dependencies — because without a clear "what depends on what" list, the directives won't work. It will lift the command structure from the template and slot in your real stages.

Limitations

⚠️ Not for "eyeball it" tasks: if the correct behavior depends on interpreting free-form text (rather than a clear "done/blocked" status), hard commands and blocks can backfire — if the model misread the request, the command just locks in that mistake.

⚠️ Enabling reasoning mode partly fixes weak rungs 1–2: for powerful models that "think" before answering, the gap between a simple checklist and explicit commands narrows — but a fully passive approach (chat history only) is still weaker.

⚠️ Hard blocking (rung 4) needs an external mechanism — code or a tool that physically prevents an incorrect action from executing. In a plain chat with no integrations, this can't be literally reproduced — only approximated by requiring the model to double-check itself.

How the Research Was Done

The team built a test bed of "projects": 5–18 steps with dependencies (procurement, approval, delivery, etc.), generated according to a scenario — the user brings up steps out of order, cancels one, asks for a redo on another. Every episode contained deliberate "traps": re-mentioning a completed step without saying "redo," or asking about a blocked or canceled step.

They tested three models (including the strong Qwen3-235B and the weaker Qwen3.6-35B, plus the closed-source DeepSeek V4 Pro), both with and without reasoning mode enabled. Scoring wasn't based on another model's judgment — it used strict execution-code matching: either the step ran correctly or it didn't.

It turned out that simply showing an accurate status barely moved the needle (from 0.38 to 0.55 for the top model), while explicit command-style directives moved it a lot (up to 0.84–0.87), and hard blocking pushed it almost to the ceiling (0.98). But on an external project-management benchmark, where correctness depends on interpreting free-form text rather than a clear status, the pattern flips: simply showing the record beats both "command" versions, and hard-blocking the model's flawed judgment only makes things worse. The takeaway: how forcefully you should impose status depends on how clearly "correct behavior" is even defined.

Adaptations and Extrapolations

🔧 Technique: replace the passive checklist with a "status first, then action" requirement → effect: the model can't accidentally skip past the status straight to an action, because it's forced to state it explicitly first.

Example: in a prompt for tracking client negotiations, ask the model to write, before every reply, "NEGOTIATION STATUS: {stage} — {what's settled, what's open}" — this carries the technique over from project tasks to any long dialogue with accumulated context (e.g., managing a deal, customer support, or legal document review).

🔧 Technique: self-tracking instead of an external tracker → if you're currently maintaining the project status by hand and pasting it into every prompt, try asking the model to maintain it itself and just remind it to "continue from your last ledger." It saves you time and, according to the research, works even better than an accurate external checklist.

Resources

How Strongly Should Task State Influence an LLM Agent? — Chenyu Zhang (University of Waterloo), Wonbin Kweon (Sungkyunkwan University), Jiawei Han (University of Illinois Urbana-Champaign). Preprint. The τ²-bench (airline) and PMBench (project management) benchmarks are cited as external validation of the findings.