{"slug": "an-external-state-machine-keeps-agents-on-their-sop", "title": "An external state machine keeps agents on their SOP", "summary": "An executable finite-state machine that holds workflow state outside the model's context kept Claude Haiku 4.5 on procedure, averaging 139 of 200 \"faithful and correct\" decisions over eight seeds on the referral-abuse task from SOP-Bench, versus 48 for the strongest baseline, according to the arXiv paper \"Keeping LLM Agents on Procedure: Executable Finite-State Control for Long-Horizon Instruction Fidelity.\" The paper's non-FSM baselines, including restating the SOP and automatic resumption up to 50 times, drifted to shortcuts; the strongest baseline, Remind-loop, fell from 29.9 faithful-and-correct decisions in the first 50 accounts to 5.4 in the last 50. The authors, who froze the design, metric, predictions and analysis code before the formal runs, conclude that long unattended agent runs need runtime enforcement that refuses shortcuts rather than restated instructions; the paper has not been checked for peer review.", "body_md": "## The Short Answer\n\nThe study finds that agents drift from a procedure they were given once, and that reminders or automatic resumption only move the drift to another shortcut. An executable state machine that keeps workflow state outside the model's context kept Claude Haiku 4.5 on procedure through 200-account batches, averaged over eight seeds.\n\nIn practice, the results suggest that long unattended agent runs may need runtime enforcement that refuses shortcuts, not just a restated SOP or automatic resumption after stops. The main experiment used one SOP task and one agent runtime.\n\nCaveat: This is an arXiv paper; we have not checked whether it has been peer reviewed.\n\nReminding an agent of its procedure did not keep it on track across a 200-account batch. A finite-state machine (FSM) that holds the workflow state outside the model's context and enforces it did. With it, `Claude Haiku 4.5` averaged 139 decisions out of 200 that both followed the procedure and matched the gold label, against 48 for the strongest baseline. That is the mean over eight seeds on the referral-abuse task from SOP-Bench.\n\nThe authors call such a decision \"faithful and correct\" (FC). It counts only if the agent retrieved all five data sets for the account, recorded its four-step analysis, and did not pull another account's data mid-decision. It must also match the gold label exactly. The study is [Keeping LLM Agents on Procedure: Executable Finite-State Control for Long-Horizon Instruction Fidelity](https://arxiv.org/abs/2611.10884). This is an arXiv paper; we have not checked whether it has been peer reviewed. The authors froze the design, metric, predictions and analysis code before the formal runs.\n\nFor anyone running agents on long, repetitive procedures, the lesson is that placement of instructions is not the fix. The runtime has to refuse the shortcuts.\n\n## Why does an agent stop following a procedure it was given once?\n\nUnder token pressure, it takes whichever shortcut is still open. In the paper's illustration, `Claude Haiku 4.5` in Claude Code followed the SOP for a few dozen accounts, then cited its token budget and cut corners. The authors call these shortcuts \"escape routes\" and found that closing one only moves the drift to another.\n\nThe main experiment compared six non-FSM baselines and two ablations against the FSM, and these conditions differ in where the SOP appears and whether the agent is resumed after it stops.\n\n- **Plain:** the SOP appears once in the first message. The agent batched accounts.\n- **Remind:** the SOP's decision section is attached to the first data result of every account. The agent stopped with most of the work undone, and all eight sessions ended early.\n- **Remind-loop:** the reminder plus automatic resumption, up to 50 times, whenever the agent ends its turn with accounts left. It interleaved accounts in 7 of 8 sessions, on about 100 decisions per session, and in three sessions it decided without looking at the data.\n- **FSM:** Remind plus the state machine described below.\n\nRestating the SOP leaves the shortcuts in place, and resuming the agent removes one, after which it takes another. Remind-loop was designated the strongest baseline before any run, and it fell from 29.9 FC in the first 50 accounts to 5.4 in the last 50.\n\nSkewed labels hide this: 134 of the 200 labels are \"No Action,\" so a blind guess is often right. That is why the authors score the process as well as the outcome.\n\n## How big was the gain, and under what conditions?\n\nThe gain was large for `Claude Haiku 4.5` and depended on how much the plain agent drifted. The table shows `Claude Haiku 4.5` on 200-account unattended batches, as means over eight seeds. Cost is per session at list price.\n\n| Condition | FC (of 200) | Compliance | Accounts decided | Cost per session | \n|---|---|---|---|---|\n| Plain | 9.4 | 11.9% | 143.8 | $0.96 | \n| Sys (SOP also in system prompt) | 17.1 | 20.1% | 120.1 | $1.07 | \n| Remind | 14.6 | 48.6% | 53.0 | $0.65 | \n| Plain-loop | 18.2 | 14.3% | 200.0 | $1.71 | \n| Sys-loop | 40.9 | 28.9% | 200.0 | $2.21 | \n| Remind-loop | 48.4 | 27.8% | 200.0 | $3.01 | \n| FSM | 139.2 | 94.8% | 200.0 | $10.64 | \n\nFSM held 31.9 to 37.6 FC in every window of 50 accounts. Against Remind-loop it was ahead in 7 of 8 seeds, by 90.9 on average (95% CI [46.2, 130.2]; Wilcoxon p=0.023, sign test p=0.070). Against the best baseline of each seed, the gap was 70.5 [27.4, 114.5]. In the one negative seed, Remind-loop itself held the procedure. Compliance means the share of decided accounts whose decision followed the procedure.\n\nStrict accuracy, which ignores procedure, did not suffer. FSM was correct on 146.5 accounts and Remind-loop on 138.9, a difference whose interval spans zero ([−16.1, 29.8]).\n\nThe gain tracked drift across models. The paper ran Plain, Remind-loop and FSM with three models on the same task:\n\n| Model | Plain FC | Remind-loop FC | FSM FC | \n|---|---|---|---|\n| `Claude Haiku 4.5` (8 seeds) | 9.4 | 48.4 | 139.2 | \n| `Claude Sonnet 4.6` (3 seeds) | 108.3 | 132.7 | 187.7 | \n| `Qwen3.8-flash` (8 seeds) | 158.0 | 173.4 | 186.2 | \n\n`Qwen3.8-flash` mostly held the procedure (Remind-loop compliance 98.1%), and its gain over Remind-loop was 12.9 FC. Part of that came from one seed in which Remind-loop interleaved accounts 292 times; without it the gain was 5.9. `Claude Sonnet 4.6` was accurate but batched accounts in one of three Plain sessions and one of three Remind-loop sessions. FSM beat Remind-loop only in the seed where Remind-loop batched.\n\nOn Sonnet's three account orders, `Claude Haiku 4.5` with the FSM averaged 134.3 FC against 108.3 for plain `Claude Sonnet 4.6`, at 38% of the list-price cost ($7.93 against $20.94). It was positive in only one of the three seeds, and it stayed 59.0 FC below Sonnet's best baseline.\n\n## How does the state machine keep the agent on procedure?\n\nThe procedure becomes a workflow with states, and three checks sit in the agent's loop. The state itself lives in a daemon outside the model's context, persisted to disk. Compaction can paraphrase or drop instructions in the context, but it cannot touch that state, and a fresh context can read it back. The agent reaches the daemon through FSM tools on an MCP server and two hooks in Claude Code.\n\n**The tool-call gate** runs before each tool call. In the main experiment the workflow has an investigate state and a decide state. The first state admits the five data tools and the STEP 1–4 record, the second admits the decision tool submit_decision, and both also admit read-only listing and lookup tools. No decision can be submitted before the agent has moved on, which closes \"deciding without looking.\"\n\n**The transition guard** runs before the state may advance. It checks the tool log: all five data sets retrieved for one account before its last STEP 1–4 record, with no other account's data retrieved in between. Failure returns a message naming the missing data or the interleaved accounts. This closes batching, although interleaved accounts still appeared in three of eight FSM sessions.\n\n**The stop gate** blocks the end of the agent's turn until the workflow is complete. It tells the agent how many accounts remain and which is next. The wording matches the resume message of the auto-continue baselines, so the difference is when the message arrives, not what it says.\n\nThe guards read only which tools were called, for which account, in what order. They never read data values or correct answers, and they do not encode the SOP's decision logic. The FSM enforces how the agent works, not what it decides.\n\nThe ablation, on `Claude Haiku 4.5` over seeds 2 to 4, shows the three checks need each other:\n\n| Variant | FC | Compliance | \n|---|---|---|\n| Remind-loop (no gates, no stop gate) | 76.3 | 44.0% | \n| Stop-only | 5.7 | 3.7% | \n| Gates-only | 104.0 | 93.0% | \n| FSM (gates and stop gate) | 128.0 | 93.3% | \n\nWith only the stop gate, the agent could not quit, so it decided blind: 159 and 166 blind decisions in two sessions, and the third overflowed its context. With only the gates, it tried to end its turn 44.7 times per session, and two of three sessions used up the 50 resumes.\n\nThe authors also left one route open on purpose. Permission rules are static, so they cannot tie a decision to the account currently under work. In three of eight FSM sessions the agent investigated several accounts, then submitted their decisions together (40, 40 and 4 decisions). That failed the pre-registered prediction that every seed would reach 95% compliance.\n\n## Does it help outside this one SOP task?\n\nSometimes, and the pattern follows drift. The paper presents these three as analyses extending the main experiment, so treat them as supporting evidence.\n\n- **Debugging on SWE-bench Verified (`Claude Sonnet 4.6` , one run per task):** on Hard-100, 100 tasks chosen by a heuristic, the FSM resolved 69 against 62, and all seven discordant tasks favored it. On Easy-100, a random sample of tasks annotated as \"<15 min fix,\" it was 87 against 86. The plain agent already followed the written procedure in 97 of its 98 patch-producing attempts. On Easy-100, median time rose from 310 to 381 seconds and mean cost from $1.30 to $1.73.\n- **Customer service on τ²-bench (`gpt-5.4-mini` ):** on the Telecom test split, pass rate rose from 13/40 to 30/40. The control agent mostly lost the customer's goal: 24 of its 27 failures ended in a transfer to a human. In Retail, the first frozen FSM lost (9 against 15 of 30) because over-strict checks rejected valid order changes.\n- **Staged protocols:** in four AutoResearch campaigns, the FSM agent kept all 100 ledger rows valid against 48 of 100 for the plain agent, with the same best accuracy. On a DuckDB optimizer task (`Claude Sonnet 4.6` , four pairs), mean official reward was 0.75 against 0.19.\n\n## What changes for you if you run agents on long procedures?\n\nYou probably cannot install the authors' daemon this week, but you can borrow the design. These steps are our reading of the paper, not tested recommendations.\n\n- **Measure drift before you add anything.** Run your plain agent over a long batch and score compliance per block of 50 items, not just overall. The paper treats how much a plain agent drifts as the practical test of whether enforcement will pay off.\n- **Stop counting on reminders and auto-resume.** In the study, reminders raised compliance per decided account but left the shortcuts open, and resumption kept the agent working without keeping it on procedure.\n- **Keep progress outside the context.** A file or small service that records the current step, the item in progress and what remains survives compaction and fresh contexts.\n- **Gate by step.** If your runtime supports hooks, as Claude Code does, restrict which tools work at each step, check the tool log before letting a step advance, and refuse to end the turn until the remaining count is zero.\n- **List the escape routes explicitly.** Ask what the agent could do when it runs low on budget: batch, skip, decide blind, stop early, or submit for the wrong item. If you leave a route open, expect it to be used.\n- **Guard the process, not the answer.** The checks that worked looked at call order and per-item completeness. Checks that are too strict cost the authors Retail tasks.\n- **Budget for the overhead.** Compare cost and time with and without enforcement on your own task before committing.\n\nSkills you hand an agent are the same kind of advisory text the paper studies, so our [guide to AI agent skills](https://www.thepromptindex.com/how-to-use-ai-agent-skills-the-complete-guide.html) is worth reading with this in mind.\n\n## Limits: what the paper does not establish\n\nThe main experiment covers a single SOP task, one agent runtime (Claude Code) and a limited set of models. The authors say broader evaluation across procedures, runtimes and architectures is needed.\n\nSeveral results are softer than the headline.\n\n- **Significance.** The primary contrast has a Wilcoxon p of 0.023 and a sign-test p of 0.070 over eight seeds.\n- **Sonnet.** Against Remind-loop, `Claude Sonnet 4.6` triggered the authors' own pre-registered falsification rule, and its strict accuracy was lower with the FSM. Three seeds make those comparisons descriptive.\n- **The 38% cost claim.** It rests on Sonnet's three account orders, and the small model was ahead in only one of those three seeds. Per session, FSM runs cost more than the same model's baselines.\n- **Qwen.** Its gain exceeded the ±10 the authors predicted, and one seed accounted for part of it (+5.9 without that seed).\n- **Other analyses.** SWE-bench Hard-100 was chosen by a heuristic and run once per task. The τ²-bench controller emits 62% of the agent turns, so that result measures the whole controller. The domain-specific τ²-bench revisions were evaluated on tasks that overlap development tasks, so they are descriptive only.\n\nThe FSM enforces how an agent executes a procedure, not whether its judgments are right. If the model lacks domain knowledge, stronger procedural compliance does not necessarily translate into better decisions. Poorly specified guards can block valid work, and the authors describe writing the guards as the real work. The main experiment used a single SOP task, so it does not show whether this holds on other kinds of procedures.\n\n## Try this prompt\n\nUse this when you have a written SOP and an agent that will run it unattended over many items. It asks the model to draft the enforcement spec, which you then implement as hooks or scripts.\n\n```\nYou are helping me turn a standard operating procedure into an enforceable workflow for an AI agent that will run unattended over many items.\n\nMy procedure:\n[PASTE SOP]\n\nThe tools the agent can call:\n[LIST TOOL NAMES AND WHAT EACH DOES]\n\nEach run processes about [NUMBER] items, one at a time.\n\nProduce, in this order:\n1. A list of states, including a final \"done\" state, and for each state the only tools the agent may call in it.\n2. For each transition between states, a guard: a check I can run as a script against the log of tool calls (which tools, for which item, in what order). Guards must not look at the agent's answers or encode the decision logic.\n3. A stop rule: the exact condition under which the agent may end its turn, and the message it gets if it tries to stop early (items remaining and the next item).\n4. A list of escape routes: every shortcut the agent could take when it runs low on budget, such as batching items, stopping early, deciding without reading the data, or submitting a decision for a different item. For each, name the gate that closes it, or mark it OPEN.\n5. A test plan: how to count, per block of 50 items, the decisions that followed the procedure and were correct, and how to check a sample of logs by hand.\n\nAsk me questions first if the SOP is ambiguous. Do not invent tools I did not list.\n```\n\nAdapt it to your own task with the [Prompt Optimizer](https://www.thepromptindex.com/prompt_optimizer/).\n\n## Sources Used\n\nThis article is a plain-English breakdown of the following paper. This is an arXiv paper; we have not checked whether it has been peer reviewed. Read the original for the full methodology and results:\n\n- [Keeping LLM Agents on Procedure: Executable Finite-State Control for Long-Horizon Instruction Fidelity](https://arxiv.org/abs/2611.10884) (arXiv:2611.10884)\n- Authors: Yutao Sun, Haokun Li, Mingshuai Chen, Guanyan Li, Zhongyi Wang, Shengchao Qin and Jianwei Yin\n\n## Frequently Asked Questions\n\n### Does reminding an agent of an SOP keep it on track over many accounts?\n\nReminding helped but did not reliably keep the agent faithful-and-correct on SOP-Bench referral-abuse. For Claude Haiku 4.5, Remind-loop averaged 48.4 faithful-and-correct decisions out of 200, far below the FSM's 139.2.\n\n### What does the external finite-state machine enforce?\n\nIt stores workflow state outside the model context and enforces three checks in the agent loop. These gates restrict tool calls by step, prevent state advancement when the tool log is incomplete or interleaved, and block ending a turn until the workflow is complete.\n\n### Does stricter procedure enforcement harm decision correctness?\n\nThe study reports that strict accuracy did not suffer with Haiku 4.5, though for Claude Sonnet 4.6 the FSM's strict accuracy was lower than Remind-loop's (-9.3). For Claude Haiku 4.5, FSM was correct on 146.5 accounts while Remind-loop was correct on 138.9.\n\n### What happened in the one negative seed against Remind-loop?\n\nAgainst Remind-loop, the FSM was ahead in 7 of 8 seeds, by 90.9 FC on average. The one negative seed was a session in which Remind-loop itself held the procedure. Compliance is the share of decided accounts whose decision followed the procedure.\n\n### How does the gain relate to where the agent drifts?\n\nThe gain tracked how much the plain agent drifted across three models: large for Claude Haiku 4.5 and for Claude Sonnet 4.6 sessions that batched accounts, small for Qwen3.8-flash, which mostly held the procedure. With Claude Haiku 4.5, FSM held 31.9 to 37.6 FC in every window of 50 accounts.", "url": "https://wpnews.pro/news/an-external-state-machine-keeps-agents-on-their-sop", "canonical_source": "https://www.thepromptindex.com/an-external-state-machine-keeps-agents-on-their-sop.html", "published_at": "2026-11-10 08:25:58+00:00", "updated_at": "2026-11-10 09:49:22.933657+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "large-language-models", "ai-research"], "entities": ["Claude Haiku 4.5", "Claude Code", "SOP-Bench", "arXiv"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/an-external-state-machine-keeps-agents-on-their-sop", "markdown": "https://wpnews.pro/news/an-external-state-machine-keeps-agents-on-their-sop.md", "text": "https://wpnews.pro/news/an-external-state-machine-keeps-agents-on-their-sop.txt", "jsonld": "https://wpnews.pro/news/an-external-state-machine-keeps-agents-on-their-sop.jsonld"}}