LedgerAgent: Structured State for Policy-Adherent Tool-Calling Agents Md Nayem Uddin♠ Amir Saeidi♠ Eduardo Blanco♢ Chitta Baral♠ ♠ Arizona State University ♢ University of Arizona [email protected]
Abstract
arXiv:2606.20529v1 [cs.AI] 18 Jun 2026
Policy-adherent tool-calling agents in customerservice domains must maintain task states across turns while calling tools and obeying domain policies. Task states consist of relevant facts, identifiers, constraints, and conditions observed through user interaction and tool calls. In standard agents, task states are not represented separately. Observations, tool returns, and policy instructions are placed in the prompt, leaving agents to reconstruct the relevant states from the prompt each time they decide what to do next. This design makes state management implicit, creating two common failure modes. An agent may retrieve the right facts but later ground its decision in stale, missing, or incorrect information; and a syntactically valid tool call may still violate a domain policy that depends on the current task state. We introduce L EDGER AGENT, an inference-time method for tool-calling agents that maintains observed task states in a separate ledger and renders the states into the prompt. The ledger is also used to check state-dependent policy constraints before environment-changing tool calls are executed, blocking policy violations. Across four customer-service domains and a mixed panel of open- and closed-weight models, L EDGER AGENT improves average pass^k over a standard prompt-based tool-calling approach, with the largest gains under stricter multi-trial consistency metrics.
1
Introduction
Language agents are increasingly evaluated in settings that require sustained interaction rather than isolated tool calls (Li et al., 2023; Liu et al., 2025; Zhou et al., 2024a; Lu et al., 2025; Trivedi et al., 2024). They must converse with users, retrieve records from external systems, and follow domainspecific rules across multiple turns. Customerservice domains (Yao et al., 2024; Barres et al., 2025) make this requirement concrete: an agent may inspect a reservation, check an order, change
a service plan, issue a refund, or update an account. Success therefore depends on more than selecting the right tool. The agent must maintain the relevant interaction state and act only when the domain policy permits the action. Most tool-calling agents expose information to the model through prompt text (Yao et al., 2023b; Karpas et al., 2022; Lu et al., 2023). Tool outputs are appended to the prompt. Prior actions remain interleaved with user messages and model generations. The policy document is supplied as natural-language instructions. At each turn, the model must identify which prior facts matter, decide whether more information is needed, choose the next response or tool call, and judge whether the intended action is allowed. This design is simple and model-agnostic. However, it leaves task state implicit in an ever-growing context, so reliable behavior depends on finding and using the relevant evidence when the agent acts in the environment. A second failure appears at the policy boundary. Domain policies specify when actions are allowed. For example, they may define which orders are returnable or which payment method must receive a refund. These rules are usually supplied before the agent has retrieved the records that determine which rules apply (Ruan et al., 2024; Yao et al., 2024). When the agent later proposes an action, there is often no separate check against the current state and governing policy. A tool call can therefore be syntactically valid while still violating the domain policy. We introduce L EDGER AGENT, an inferencetime method that adds an explicit state representation in the agent loop. It has two deterministic components. First, it maintains a schema-anchored ledger which projects successful tool returns into a compact typed dictionary keyed by canonical paths. This requires no additional LLM calls to build. The ledger is re-injected at each turn, so the agent can consult current task state by lookup rather than
Domain Policy The current time is 202405-15 15:00:00 EST.
...
Cancel Flight Policy: A flight can be cancelled if any of these is true: - The booking was made within the last 24 hrs, or - The flight was cancelled by the airline, or - The user has travel insurance and the cancellation reason is covered.
...
Available Tools - book_reservation - cancel_reservation - get_reservation_details - get_user_details - list_all_airports - search_direct_flight - send_certificate ...
Turn 1
Baseline
LedgerAgent
Turn 1
Hi, My name is Julia. I need to cancel my flight to Seattle. My reservation ID is UX789
Hi, My name is Julia. I need to cancel my flight to Seattle. My reservation ID is UX789
Turn 2
Turn 2
get_reservation_details(reservation_id="UX789")
get_reservation_details(reservation_id="UX789")
Turn 3
Turn 3
{"reservation_id": "UX789", "flights": [ { "flight_number": "HAT142", "origin": "ORD", "destination": "SEA", "date": "2024-05-17", "price": 312}], "passengers": [{ "first_name": "Julia", ...}]}
Ledger State
{"reservation_id": "UX789", "flights": [ { "flight_number": "HAT142", "origin": "ORD", "destination": "SEA", "date": "2024-05-17", "price": 312}], "passengers": [{ "first_name": "Julia", ...}]}
Turn 4
Turn 4 cancel_reservation(reservation_id="UX789")
cancel_reservation (reservation_id="UX789")
Turn 5
Blocked Action
{"reservation_id": saved "UX789", information "date": from "2024-05-17", reservation "price": 312} tool output
Policy Gate
... if abs(current_date, reservation_date) > 24: return "block" ...
{"status": "Flight canceled successfully."}
Turn 6
Turn 6
I’m sorry, but reservation UX789 can’t be canceled because it is outside the 24-hour cancellation window and violates our cancellation policy.
The flight was successfully cancelled. Let me know if you need help with anything else.
Figure 1: A standard agent retrieves a reservation record but later issues a policy-violating cancellation because the relevant state remains implicit in the prompt. LedgerAgent stores successful tool returns in a schema-anchored ledger and checks proposed environment-changing calls against this observed state before execution. In this example, the stored reservation state allows the gate to block the cancellation and return policy-grounded feedback.
searching raw transcript history. Second, LedgerAgent applies a policy gate before environmentchanging tool calls are executed. The gate evaluates proposed calls against domain rules expressed as predicates over ledger fields. If a proposed call violates policy, the gate blocks it and returns feedback identifying the violated rule and conflicting state. The agent can then block or revise its plan before the environment is changed. Figure 1 illustrates how explicit ledger state and a pre-action policy gate change the failure boundary from post-hoc correction to prevention. L EDGER AGENT addresses different failure modes from methods that primarily improve the model. Fine-tuning and synthetic data generation teach models to perform tool use more reliably (Schick et al., 2023; Li et al., 2023; Patil et al., 2023; Qin et al., 2023). Reinforcement learning rewards successful trajectories (Zhou et al., 2024b; Jin et al., 2025). Inference-time scaffolds add planning, reflection, or workflow constraints around generation (Yao et al., 2023b,a; Madaan et al., 2023; Shinn et al., 2023). These approaches can improve performance, but they largely preserve the same prompt-only way of representing state. Retrieved records and policies remain embedded in a growing transcript, and task state remains implicit at the moment of action. LedgerAgent instead changes how state is represented. The model
weights are unchanged. The agent is given an explicit typed state object, and policy is enforced when proposed actions are about to affect the environment. We evaluate LedgerAgent across four customerservice domains from τ 2 -bench and τ -Trait (Barres et al., 2025; He et al., 2026), using a mixed panel of open- and closed-weight models. LedgerAgent improves pass^k on majority of the domain–model pair we evaluated. The gains are largest at higher values of k, where the standard prompt-based approach is least consistent across independent trials. Ablations show that the improvement comes from the typed ledger and policy-gated action. In summary, this paper makes three contributions: • We identify state grounding as a key failure mode in policy-adherent tool-calling agents: agents may retrieve the right records but later act on stale, missing, or incorrectly reconstructed state. • We introduce L EDGER AGENT, an inferencetime method that maintains observed state in a schema-anchored typed ledger, renders it for generation, and uses it to check environmentchanging calls before execution. • We show that L EDGER AGENT improves consistency-oriented pass^k across customerservice domains and backbone models,
with the largest gains on tasks requiring environment-changing actions.
2
Related Work
Interactive tool-using agents Recent work on language agents has moved beyond isolated API calls toward interactive tasks in which models must use tools over several turns. Early tool-use benchmarks and datasets study whether models can plan, select APIs, and produce valid calls in tool-augmented settings (Li et al., 2023). More recent customer-service benchmarks make the setting more realistic by combining dialogue, structured records, domain APIs, and operational policies (Yao et al., 2024; Barres et al., 2025). These benchmarks reveal that agent failures are often not simple tool-selection mistakes. A model can retrieve the right information and still make an incorrect decision later because the relevant record is buried in the interaction history. Inference-time scaffolding for tool use Many methods improve tool-using agents by changing the procedure around the model rather than the model itself. Planning and reasoning frameworks encourage the model to decompose tasks before acting, while reflection methods use feedback from previous attempts to improve later behavior (Yao et al., 2023b; Shinn et al., 2023). Recent inputreformulation and multi-agent approaches also provide additional context or specialized assistance before the next tool call. IRMA reformulates the agent input with relevant domain rules and tool suggestions, while FAMA dynamically selects specialized helper agents based on observed failure modes (Mishra et al., 2025; Saeidi et al., 2026). However, these approaches still largely rely on the language model to recover the current task state from the transcript, which can be unreliable when later actions depend on exact records, identifiers, statuses, or valid tool arguments. Policy adherence in tool-using agents A separate challenge is ensuring that tool calls satisfy domain constraints. Prior benchmarks emphasize the importance of policy following in realistic toolagent-user interaction, but most agent implementations still place rules in the prompt or rely on the model to reason about whether an action is allowed (Yao et al., 2024; Barres et al., 2025). This can fail when the applicability of a rule depends on records obtained during the conversation. LedgerAgent targets this gap at the interface between the model and
the environment. It gives the agent an explicit structured state object derived from tool observations and uses that state to check proposed write actions before execution. Compared with methods that primarily rely on training, prompting, or multi-agent orchestration, LedgerAgent frames state tracking and policy adherence as system-level mechanisms that complement the model’s reasoning.
3
Method
L EDGER AGENT is an inference-time method for a standard policy-adherent tool-calling agent. It adds two deterministic components: a ledger that stores observed state from successful tool returns, and a policy gate that checks environment-changing calls before execution. Environment-changing calls modify external state, such as issuing refunds, updating orders, changing reservations, or changing accounts; read-only calls are not gated. On each turn, new read-tool returns are absorbed into the ledger, the ledger is rendered into the prompt, and the model generates a response or tool call. Before any environment-changing call reaches the environment, the policy gate checks it against ledger state. Thus, relevant state is exposed as a stable structured representation rather than scattered across the transcript, and policy constraints are re-checked at the action boundary. 3.1
Ledger State and Updates
Task state is the snapshot of task-relevant facts, conditions, identifiers, and data observed through interaction with the environment. The ledger stores the portion observed through tools in a domain schema. It is not long-term memory, an LLM summary, a per-task checklist, or a claim to recover unobserved world state. Formally, the ledger is a typed dictionary L : P → V, where P is the set of canonical schema paths and V is the set of tool-returned values. Paths are stable addresses for observed records, such as user, orders.*, products.*, reservations.*, or keyed flight-search results. Nested values remain inside stored records, and the model sees a deterministic rendering of the ledger. Each domain supplies a fixed tool path map that routes whole successful returns to canonical ledger locations. The map follows the tool interface and policy-relevant entities; it is not generated by LLMs. The ledger updates only from successful readtool returns. For each return, LedgerAgent links it
to the earlier tool call, recovers the tool name and arguments, parses the returned JSON, and stores the returned record at the path determined by the map. Failed tools and write-tool returns do not update states. After a successful write, the agent must issue a read call to observe the new state. This observe-not-assume rule keeps the ledger grounded in the external system. For example, in a retail exchange, observed order and product records stay addressable under stable paths, so later tool arguments and policy checks can use environmentreturned identifiers rather than searching earlier JSON in the transcript. 3.2
Ledger-Grounded Generation
Before each model call, LedgerAgent adds the full ledger block to the prompt. The block is generated deterministically from L and lists every record that has actually been observed through read tools. Each entry is shown under a canonical path, such as orders.1234 or products.5678, together with the stored returned value. The dialogue history, policy text, and normal tool schemas are still provided; the ledger block is an additional state view, not a replacement for them. The purpose of the block is to make the current observed state easy for the model to find. For example, after the agent reads an order and a product, the block shows that orders.1234 is delivered, belongs to the current user, and contains item sku_a, while products.5678 lists the observed replacement variants. If the user later says “exchange that item,” the model can use these stable paths and identifiers instead of searching through earlier JSON tool returns. 3.3
Policy Gate
The policy gate runs immediately before any environment-changing call is executed. It evaluates the proposed call against executable predicates Π over the current ledger L and returns one of three outcomes: • ALLOW: execute the call unchanged. • REVISE: remove the call and give the model the violated predicate. • BLOCK: block the call and refuse the requested action. For messages with multiple tool calls, the gate checks each environment-changing call independently. Allowed calls remain in the assistant message; rejected calls are removed. A REVISE verdict
adds feedback to the next model turn, while BLOCK ends the attempted environment-changing action. The gate is only a verifier. It does not choose tools, repair arguments, fetch missing records, or plan a new trajectory. The model still handles task progress; the gate only checks whether a proposed action is consistent with the observed ledger state and encoded policy. Predicates are specified once per domain as code over ledger fields; we do not compile arbitrary natural-language policy. In the reported experiments, the policy layer contains 28 deterministic gate predicates in total: 10 for airline, 12 for retail, 6 for telecom, and none for telehealth. They encode recurring checks such as ownership, entitystate preconditions, argument grounding, refund or payment consistency, and loop prevention. Retail predicates check, for example, that an order belongs to the authenticated user, that a return targets a delivered order, that a refund uses an observed payment method, and that an exchange item and replacement variant appear in observed records. Airline predicates check that a selected flight came from a prior search result before it is used in a reservation update. Predicates use only records present in the ledger. If a rule requires explicit evidence and that evidence is missing or inconsistent, the gate returns REVISE . Otherwise, absence is not treated as a violation. Read calls are allowed to repeat because re-reading is how the agent observes updated external state. Appendix C gives a concrete trace of this REVISE behavior. 3.4
Agent Loop
LedgerAgent keeps one base-model generation per turn. Algorithm 1 highlights the cost invariant in the default configuration: ledger updates, ledger rendering, and policy checks wrap the base model call, but they do not introduce an additional LLM call. Ledger updates are deterministic operations over tool returns, rendering is deterministic string formatting, and the policy gate is an executable predicate check over the typed ledger. The model weights, tool schemas, and decoding procedure remain unchanged. To instantiate LedgerAgent in a new domain, a developer specifies two reusable components: tool path maps for storing returned records, and executable predicates for environment-changing tools. Both are domain-level, not task-level: they follow
Algorithm 1 LedgerAgent Loop
4.2
Require: message m, history H, ledger L, tools T , policy P , predicates Π 1: Append m to H 2: if m is a tool-return message then 3: L ← Absorb(L, m) ▷ successful known reads update typed state 4: end if 5: C ← Render(L) 6: a ← Generate(H, P, C, T ) 7: if a proposes environment-changing call(s) then 8: (a′ , g) ← GateFilter(a, L, Π) 9: if g = ALLOW then 10: return a′ ▷ call(s) preserved unchanged 11: else if g = REVISE then 12: return a′ ▷ rejected call(s) removed; feedback added 13: else if g = BLOCK then 14: return refusal for the requested environmentchanging action 15: end if 16: end if 17: return a
For each backbone, we compare the baseline agent with L EDGER AGENT. Both conditions use the same policy, tools, conversation history, decoding settings, and number of model calls. The baseline recovers task state from the transcript. L EDGER AGENT additionally renders the observed ledger before generation and, except in telehealth, checks proposed environment-changing calls with the policy gate. Thus, the comparison isolates the ledger representation and action boundary check rather than extra calls, tools, or training.
Domain Airline Retail Telecom Telehealth
Benchmark 2
τ -bench τ 2 -bench τ 2 -bench τ -Trait
Tasks
Control
50 114 114 20
single single dual single
Table 1: Benchmark domains. In single-control domains, only the agent modifies the task database. In the dual-control setting, the user simulator can also change shared state.
the API records and policy constraints such as ownership, entity state, grounded arguments, and payment consistency. The method therefore applies to structured tool-use domains where compliance can be checked against observed records.
4
Agent and User Models
We evaluate six agent models: GPT-5.2, GPT4.1 (Achiam et al., 2023), Kimi K2.5 (Team et al., 2026), GLM-5 (Zeng et al., 2026), MiniMaxM2.5 (MiniMax et al., 2025), and Qwen330B (Yang et al., 2025). For each model, we compare LedgerAgent against the corresponding standard-agent baseline built from the same underlying model. Unless otherwise stated, all agent runs use temperature 0.0 and all comparisons use the same fixed user simulator; across all experiments in the paper, the user simulator is GPT-5-mini. 4.4
Evaluation Protocol
We run four independent trials per task for each domain–model–agent cell. A task receives pass^k if all k trials pass. We report pass^1 as the main success metric and pass^4 as a consistency measure. Rewards are computed by the benchmark evaluator from the task-specific database, action, communication, and natural-language checks.
Experiments
We compare L EDGER AGENT against a standard prompt-based tool-calling baseline on customerservice tasks from τ 2 -bench (Barres et al., 2025) and τ -Trait (He et al., 2026). Each task provides a user goal, an initial database state, a domain policy, and tools; the agent must complete the task through dialogue and tool use. 4.1
4.3
Agent Conditions
Benchmark Domains
Table 1 lists the four domains. Airline and retail focus on grounding writes in retrieved records. Telecom tests dual-control behavior, where user-side actions can also change state. Telehealth comes from τ -Trait and keeps the same structured tooluse format in a single-control setting.
5
Results
Cross-Model Generalization Table 2 reports results for three non-GPT backbone models. Across these backbones, Ledger improves average performance over the standard Function Calling (FC) baseline. With Kimi-K2.5 as the backbone, Ledger improves over FC by 3.4 points in average pass^1 and 5.6 points in average pass^4. The same trend holds for GLM-5 and MiniMax M2.5: Ledger achieves gains of 4.7 and 7.3 points in average pass^1, respectively, and 7.6 and 8.3 points in average pass^4, respectively. These results show that Ledger is not tied to a particular backbone model; instead, it provides consistent average improvements across model families and task domains.
τ -Airline
Model Avg
τ -Retail
Pass^1 Pass^4
Avg
τ -Telecom
Pass^1 Pass^4
Avg
τ -Telehealth
Pass^1 Pass^4
Avg
Pass^1 Pass^4
Kimi-K2.5 (FC) Kimi-K2.5 (Ledger)
54.4% 69.0% 62.3% 74.0%
44.0% 38.3% 57.5% 52.0% 53.9% 70.6%
24.6% 80.9% 90.8% 41.2% 69.9% 76.5%
71.9% 11.3% 15.0% 64.0% 18.8% 25.0%
10.0% 15.8%
GLM-5 (FC) GLM-5 (Ledger)
51.3% 66.5% 64.6% 76.0%
40.0% 40.9% 61.0% 56.0% 48.5% 67.1%
26.3% 63.7% 80.3% 35.1% 68.7% 75.9%
50.9% 16.9% 20.0% 62.3% 17.6% 27.5%
15.8% 10.0%
MiniMax M2.5 (FC) 46.2% 61.5% MiniMax M2.5 (Ledger) 49.9% 63.0%
36.0% 16.7% 33.6% 40.0% 36.6% 58.1%
7.0% 66.1% 81.8% 21.1% 66.3% 74.8%
53.5% 10.7% 18.8% 58.8% 20.7% 28.8%
5.0% 15.0%
Table 2: Main results comparing standard function calling (FC) with Ledger across the evaluated τ 2 -Bench and τ -Trait domains. For each backbone and domain, Avg reports the average of pass^1 and pass^4; higher values indicate better task success and run-to-run consistency.
Method
Pass^1 ↑ Pass^4 ↑ Token Overhead ↓
IRMA Ledger (ours)
23.4% 27.2%
9.6% 17.1%
53.1% 0.0%
Table 3: Comparison of test-time agentic methods in terms of task success, repeated-run reliability, and token overhead. pass^1 baseline pass^1 ledger (ours)
pass^4 baseline pass^4 ledger (ours)
70 60
performance (%)
50 40
58.1
54.4 42.6
42.2
20
34.9
29.3
30 19.9
18.2
GPT-4.1
GPT-5.2
10 0
Figure 2: Pass^k results for GPT backbones. Higher pass^k indicates that the agent solves the same task more consistently across independent trials.
We further evaluate Ledger using GPT-based backbones. Because these models are more costly, we restrict this comparison to the retail and airline environments. As shown in Figure 2, Ledger outperforms the FC baseline by 12.2 and 15.5 points in average pass^1 when using GPT-4.1 and GPT-5.2, respectively, as the backbone of the tool-calling agent. We observe comparable improvements in pass^4. These results provide additional evidence that Ledger improves both the accuracy and consistency of tool-calling agents on complex tasks in dynamic environments. Comparison with Agentic Context-Engineering Methods Recent agentic methods (Mishra et al., 2025; Saeidi et al., 2026) have shown strong per-
formance gains in tool-calling environments. To assess Ledger against this class of approaches, we compare it with IRMA, a recent contextengineering method. As reported in Table 3, Ledger outperforms IRMA by 3.7 points in pass^1 and 7.4 points in pass^4. Importantly, Ledger achieves these gains without introducing additional token overhead, whereas IRMA incurs more than 50% token overhead due to its use of three helper agents. This result shows that Ledger not only improves over conventional baselines such as FC, but also surpasses a recent agentic contextengineering method while being substantially more token-efficient. Performance on Environment-Changing Tasks A common failure mode in tool-calling agents occurs when an agent modifies environment state and the change cannot be reverted. We refer to such operations as environment-changing tool calls. To study this setting, we conduct a comprehensive analysis of the evaluation tasks and identify tasks that require at least one write action. We find that this category includes 26 out of 50 tasks in Airline, 104 out of 114 tasks in Retail, 94 out of 114 tasks in Telecom, and 19 out of 20 tasks in Telehealth. We then evaluate both the baseline methods and Ledger on this subset of tasks. As shown in Figure 3, Ledger consistently outperforms the baselines on tasks involving environment-changing tool calls. The improvement is especially notable in the Telecom domain, where Ledger substantially increases action-level performance compared with the baseline methods, as shown in Figure 4. These results support our hypothesis that Ledger improves the ability of toolcalling models to solve complex tasks that require reliable state tracking and careful execution of write actions.
pass^k baseline
MiniMax M2.5 Kimi K2.5
performance (%)
airline
retail
75 50 25 2
performance (%)
1
performance (%)
3
2
3
improvement
regression
telecom
75 50 25
75 50 25 0 1
GLM-5
pass^k ledger (ours)
telehealth
75 50 25
4
1
4
75 50 25 0 1
2
3
2
3
75 50 25
4
1
4
75 50 25 0 1
2
3
2
3
4
1
2
3
4
4
75 50 25 0 1
2
3
4
3
4
75
75
75
75
50
50
50
50
25
25
25
25
1
2
3
k
4
1
2
k
3
4
1
2
k
3
4
1
2
k
Figure 3: Performance on tasks that require at least one environment-changing tool call, defined as a tool call that modifies external system state, such as updating an order, issuing a refund, changing a reservation, or modifying an account. L EDGER AGENT improves both pass^1 and pass^4 on this write-action subset, indicating better reliability when task success depends on modifying external state. k=2
telecom
+16.6 +16.3 +16.1 +16.0
15
+16.6 +15.7 +14.9 +14.3
_all (pp)
25 20
k=3
Kimi K2.5
MiniMax M2.5
k=4
+18.5 +18.9 +18.9 +18.4
k=1
_write
10 5 0
GLM-5
Figure 4: Telecom write-action results. The dual-control setting is especially sensitive to state drift because both the agent and user simulator can affect the shared database; Ledger improves action-level reliability by grounding proposed writes in the observed ledger state.
6
Error Analysis
We analyze failed trajectories produced by three backbone models, Kimi K2.5, MiniMax M2.5, and GLM-5, under the Ledger setting across four domains (airline, retail, telecom and telehealth). As shown in Figure 5, missed required actions and wrong action arguments account for 90.7% of all failures, with missed required actions representing 70.3% and wrong action arguments representing 20.4%. This distribution shows that Ledger agents fail much more often by omitting an expected tool
call than by invoking the correct tool with incorrect arguments. In many missed-action cases, the agent completes the initial lookup steps but terminates or transfers to human support when an edge case arises, such as a payment-method limitation, instead of continuing with the remaining policycompliant write actions. The remaining 9.3% of failures consists of extra or unauthorized actions, reasoning errors or tool-call loops, policy violations, communication failures, and authentication or identification failures. We assign these categories using a deterministic rule-based classifier based on evaluator reward signals, per-action match flags, and transcript evidence, including whether the expected tool was invoked and whether the agent transferred to human support. The domain-level analysis shows that Ledger failures have different characteristics across environments. Retail failures are primarily missed actions, accounting for 69.9% of failures, followed by wrong arguments at 20.0%. These failures often occur when the agent agrees to a multi-item modification but transfers to human support after encountering a payment or eligibility constraint, rather than following a valid modify-payment or partial-fulfillment path. Telecom failures are almost entirely dominated by missed actions, which account for 98.7% of failures. These cases typi-
missed required action wrong action arguments
extra or unauthorized action agent confusion or reasoning error
Airline
Retail
# failed trajectories
100 80 60 40 20 0
400 83
332
100 1
6
0
154
100
200 25
Telecom
200 150
300
59
policy violation failed to communicate required info
95
50 18 16 14
0
1
1
authentication or identification failure
Telehealth 140 120 119 100 80 60 45 40 20 0
4
6
Figure 5: Failure categories for Ledger trajectories across domains and backbone models. Missed required actions dominate, with domain-specific wrong-argument and unauthorized-action errors.
cally involve the agent failing to invoke a required permission-grant tool or a required transfer step. Airline has the most diverse failure profile, with missed actions accounting for 47.7% of failures and wrong arguments for 33.9%. It also contributes the largest number of extra or unauthorized actions, often when the agent concedes after user pushback and performs a policy-disallowed flight change or cabin downgrade. Telehealth has the highest wrong-argument rate, at 25.9%, reflecting its more complex tool schemas, including fields such as provider_id, appointment_type, bill_insurance, and payment_notes. Telehealth is also the only domain with authentication or identification failures, where the agent transfers to human support without first attempting the available patient lookup. Overall, these results suggest that Ledger’s remaining errors are domain-specific. Retail and Telecom require better handling of premature transfers, Airline requires stronger safeguards before irreversible writes, and Telehealth requires more robust schema-aware argument extraction.
7
Conclusion
We introduced L EDGER AGENT, an inference-time method for policy-adherent tool-calling agents that makes observed task state explicit when actions are chosen. The core problem is state grounding: agents may retrieve the right records but still act on stale, missing, or incorrectly reconstructed information when state remains buried in the transcript. L EDGER AGENT addresses this with two deterministic components: a schemaanchored ledger that stores successful read-tool returns as typed state, and a policy gate that checks proposed environment-changing calls against that
state before execution. Across customer-service domains and backbone models, L EDGER AGENT improves policy-adherent tool use without changing model weights, with the largest gains on consistency-oriented passk metrics and tasks requiring environment-changing actions. Error analysis shows that remaining failures are mostly missed actions and domain-specific argument errors, suggesting that explicit state and write-time verification reduce one important source of unreliability but do not replace planning or schema-aware argument construction. Overall, L EDGER AGENT supports a simple design principle: state that determines whether an action is valid should be represented and checked explicitly, rather than left only in an expanding prompt history.
8
Limitations
L EDGER AGENT is designed for structured tool-use domains. It assumes that tool returns expose stable fields that can be mapped into a domain schema, which matches the customer-service settings studied here, such as users, orders, reservations, accounts, and other record-like entities. The approach is less direct for tasks where the relevant state is primarily unstructured, visual, latent, or unavailable through read tools. The ledger also contains only observed state. It cannot certify facts that the agent has not retrieved, and after an environmentchanging call the ledger reflects the new external state only after that state is observed again through a read call. In such cases, the policy gate can request additional evidence or abstain, but final success still depends on the agent gathering the necessary observations. The current implementation uses domain-level specifications. A developer defines the read-tool
path map and encodes recurring policy clauses as executable predicates. These specifications are reusable across tasks in a domain and do not require additional model training, but they are not automatic policy induction. Consequently, L EDGER AGENT improves enforcement for covered, observable constraints rather than providing a complete proof of policy compliance for every possible interaction. Missing schema fields, ambiguous policy language, or omitted predicates can still leave some errors to the underlying model and benchmark evaluator. Our empirical evaluation is also scoped to the benchmarks considered in this work. We evaluate four customer-service domains with structured APIs and a fixed user simulator, covering both single-control and dual-control settings but not the full range of live users, adversarial behavior, changing policies, or production traffic. We run four independent trials per task, which supports the pass^4 consistency analysis but does not characterize very long dialogues or rare failure modes. In addition, our comparison with agentic context-engineering methods uses one representative method rather than an exhaustive set of possible multi-agent or memory-based systems. Finally, the default configuration keeps the same number of LLM calls as the standard agent, but it is not cost-free. Rendering the ledger adds prompt content, and maintaining schemas and predicates adds implementation and testing overhead. These costs are most compelling when tool returns are structured and environment-changing actions are governed by clear, recurring policy constraints; they may be less justified for simple tasks where transcript-only state tracking is already reliable.
Ethical Considerations The authors state that this work is in accordance with the ACL Code of Ethics and does not raise ethical issues. AI assistants, specifically Grammarly and ChatGPT, were utilized to correct grammatical errors and restructure sentences.
References Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Florencia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, et al. 2023. Gpt-4 technical report. arXiv preprint arXiv:2303.08774. Victor Barres, Honghua Dong, Soham Ray, Xujie Si,
and Karthik Narasimhan. 2025. τ 2 -bench: Evaluating conversational agents in a dual-control environment. Muyu He, Anand Kumar, Tsach Mackey, Meghana Rajeev, James Zou, and Nazneen Rajani. 2026. Impatient users confuse ai agents: High-fidelity simulations of human traits for testing agents. Bowen Jin, Hansi Zeng, Zhenrui Yue, Jinsung Yoon, Sercan Arik, Dong Wang, Hamed Zamani, and Jiawei Han. 2025. Search-r1: Training llms to reason and leverage search engines with reinforcement learning. Ehud Karpas, Omri Abend, Yonatan Belinkov, Barak Lenz, Opher Lieber, Nir Ratner, Yoav Shoham, Hofit Bata, Yoav Levine, Kevin Leyton-Brown, Dor Muhlgay, Noam Rozen, Erez Schwartz, Gal Shachaf, Shai Shalev-Shwartz, Amnon Shashua, and Moshe Tenenholtz. 2022. Mrkl systems: A modular, neurosymbolic architecture that combines large language models, external knowledge sources and discrete reasoning. Minghao Li, Yingxiu Zhao, Bowen Yu, Feifan Song, Hangyu Li, Haiyang Yu, Zhoujun Li, Fei Huang, and Yongbin Li. 2023. API-bank: A comprehensive benchmark for tool-augmented LLMs. In Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing, pages 3102–3116, Singapore. Association for Computational Linguistics. Xiao Liu, Hao Yu, Hanchen Zhang, Yifan Xu, Xuanyu Lei, Hanyu Lai, Yu Gu, Hangliang Ding, Kaiwen Men, Kejuan Yang, Shudan Zhang, Xiang Deng, Aohan Zeng, Zhengxiao Du, Chenhui Zhang, Sheng Shen, Tianjun Zhang, Yu Su, Huan Sun, Minlie Huang, Yuxiao Dong, and Jie Tang. 2025. Agentbench: Evaluating llms as agents. Jiarui Lu, Thomas Holleis, Yizhe Zhang, Bernhard Aumayer, Feng Nan, Haoping Bai, Shuang Ma, Shen Ma, Mengyu Li, Guoli Yin, Zirui Wang, and Ruoming Pang. 2025. ToolSandbox: A stateful, conversational, interactive evaluation benchmark for LLM tool use capabilities. In Findings of the Association for Computational Linguistics: NAACL 2025, pages 1160–1183, Albuquerque, New Mexico. Association for Computational Linguistics. Pan Lu, Baolin Peng, Hao Cheng, Michel Galley, KaiWei Chang, Ying Nian Wu, Song-Chun Zhu, and Jianfeng Gao. 2023. Chameleon: Plug-and-play compositional reasoning with large language models. Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, Shashank Gupta, Bodhisattwa Prasad Majumder, Katherine Hermann, Sean Welleck, Amir Yazdanbakhsh, and Peter Clark. 2023. Self-refine: Iterative refinement with self-feedback.
MiniMax, Aonian Li, Bangwei Gong, Bo Yang, Boji Shan, Chang Liu, Cheng Zhu, Chunhao Zhang, Congchao Guo, Da Chen, Dong Li, Enwei Jiao, Gen Li, Guojun Zhang, Haohai Sun, H. Dong, Jiadai Zhu, Jiaqi Zhuang, Jiayuan Song, Jin Zhu, Jin-Meng Han, Jingyang Li, Ju Xie, Junhao Xu, Jun Yan, Kai Zhang, Ke Xiao, Kexi Kang, Le Han, Leyang Wang, LianChun Yu, Li Feng, Lin Zheng, Lin Chai, Longqiang Xing, Meizhi Ju, Mingyuan Chi, Mozhi Zhang, PeiYu Huang, Peng-Xia Niu, Pengfei Li, Pengyu Zhao, Qi Yang, Qidi Xu, Qiexiang Wang, Qin Wang, Qiuhui Li, Ruitao Leng, Shengmin Shi, Shu Yu, Si si Li, Song He Zhu, Tao Huang, Tianrun Liang, Weigao Sun, Wei-Bing Sun, Weiyu Cheng, Wenkai Li, Xiangjun Song, Xiaojuan Su, Xiaodong Han, Xinjie Zhang, Xi-Yong Hou, Xu Min, Xun Zou, Xuyang Shen, Yan Gong, Yin-Bo Zhu, Yipeng Zhou, Yiran Zhong, Yong Hu, Yuanxiang Fan, Yue Yu, Yufeng Yang, Yuhao Li, Yunan Huang, Yunji Li, Yunpeng Huang, Yun Xu, Yuxin Mao, Zehan Li, Zekang Li, Zewei Tao, Ze Ying, Zhaoyang Cong, Zhen Qin, Zhe yu Fan, Zhihang Yu, Zhuo Jiang, and Zijia Wu. 2025. Minimax-01: Scaling foundation models with lightning attention. Venkatesh Mishra, Amir Saeidi, Satyam Raj, Mutsumi Nakamura, Gaowen Liu, Ali Payani, Jayanth Srinivasa, and Chitta Baral. 2025. How can input reformulation improve tool usage accuracy in a complex dynamic environment? a study on tau-bench. In Findings of the Association for Computational Linguistics: EMNLP 2025, pages 22949–22972, Suzhou, China. Association for Computational Linguistics. Shishir G. Patil, Tianjun Zhang, Xin Wang, and Joseph E. Gonzalez. 2023. Gorilla: Large language model connected with massive apis. Yujia Qin, Shihao Liang, Yining Ye, Kunlun Zhu, Lan Yan, Yaxi Lu, Yankai Lin, Xin Cong, Xiangru Tang, Bill Qian, Sihan Zhao, Lauren Hong, Runchu Tian, Ruobing Xie, Jie Zhou, Mark Gerstein, Dahai Li, Zhiyuan Liu, and Maosong Sun. 2023. Toolllm: Facilitating large language models to master 16000+ real-world apis. Yangjun Ruan, Honghua Dong, Andrew Wang, Silviu Pitis, Yongchao Zhou, Jimmy Ba, Yann Dubois, Chris J. Maddison, and Tatsunori Hashimoto. 2024. Identifying the risks of lm agents with an lmemulated sandbox. Amir Saeidi, Venkatesh Mishra, Souradeep Mukhopadhyay, Gaowen Liu, Ali Payani, Jayanth Srinivasa, and Chitta Baral. 2026. Fama: Failure-aware metaagentic framework for open-source llms in interactive tool use environments. Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom. 2023. Toolformer: Language models can teach themselves to use tools. Noah Shinn, Federico Cassano, Edward Berman, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao.
2023. Reflexion: Language agents with verbal reinforcement learning. Kimi Team, Tongtong Bai, Yifan Bai, Yiping Bao, SH Cai, Yuan Cao, Y Charles, HS Che, Cheng Chen, Guanduo Chen, et al. 2026. Kimi k2. 5: Visual agentic intelligence. arXiv preprint arXiv:2602.02276. Harsh Trivedi, Tushar Khot, Mareike Hartmann, Ruskin Manku, Vinty Dong, Edward Li, Shashank Gupta, Ashish Sabharwal, and Niranjan Balasubramanian. 2024. AppWorld: A controllable world of apps and people for benchmarking interactive coding agents. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 16022–16076, Bangkok, Thailand. Association for Computational Linguistics. An Yang, Anfeng Li, Baosong Yang, Beichen Zhang, Binyuan Hui, Bo Zheng, Bowen Yu, Chang Gao, Chengen Huang, Chenxu Lv, Chujie Zheng, Dayiheng Liu, Fan Zhou, Fei Huang, Feng Hu, Hao Ge, Haoran Wei, Huan Lin, Jialong Tang, Jian Yang, Jianhong Tu, Jianwei Zhang, Jianxin Yang, Jiaxin Yang, Jingren Zhou, Jingren Zhou, Junyan Lin, Kai Dang, Keqin Bao, Ke-Pei Yang, Le Yu, Li-Chun Deng, Mei Li, Min Xue, Mingze Li, Pei Zhang, Peng Wang, Qin Zhu, Rui Men, Ruize Gao, Shi-Qiang Liu, Shuang Luo, Tianhao Li, Tianyi Tang, Wenbiao Yin, Xingzhang Ren, Xinyu Wang, Xinyu Zhang, Xuancheng Ren, Yang Fan, Yang Su, Yi-Chao Zhang, Yinger Zhang, Yu Wan, Yuqiong Liu, Zekun Wang, Zeyu Cui, Zhenru Zhang, Zhipeng Zhou, and Zihan Qiu. 2025. Qwen3 technical report. Shunyu Yao, Noah Shinn, Pedram Razavi, and Karthik Narasimhan. 2024. τ -bench: A benchmark for toolagent-user interaction in real-world domains. Shunyu Yao, Dian Yu, Jeffrey Zhao, Izhak Shafran, Thomas L. Griffiths, Yuan Cao, and Karthik Narasimhan. 2023a. Tree of thoughts: Deliberate problem solving with large language models. Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. 2023b. React: Synergizing reasoning and acting in language models. Aohan Zeng, Xin Lv, Zhenyu Hou, Zhengxiao Du, Qinkai Zheng, Bin Chen, Da Yin, Chendi Ge, Chenghua Huang, Chengxing Xie, et al. 2026. Glm5: from vibe coding to agentic engineering. arXiv preprint arXiv:2602.15763. Shuyan Zhou, Frank F. Xu, Hao Zhu, Xuhui Zhou, Robert Lo, Abishek Sridhar, Xianyi Cheng, Tianyue Ou, Yonatan Bisk, Daniel Fried, Uri Alon, and Graham Neubig. 2024a. Webarena: A realistic web environment for building autonomous agents. Yifei Zhou, Andrea Zanette, Jiayi Pan, Sergey Levine, and Aviral Kumar. 2024b. Archer: Training language model agents via hierarchical multi-turn rl.
A
Licenses
This work uses models and benchmarks from various sources. Table 4 lists the licenses for the models and benchmarks used in this study. Model/Benchmark
License Type
GPT-5.2 GPT-4.1 Kimi K2.5 GLM-5 MiniMax M2.5 Qwen3-30B-Instruct τ 2 -Bench τ -Trait
Proprietary (OpenAI) Proprietary (OpenAI) Modified MIT MIT Modified MIT Apache 2.0 MIT MIT
Table 4: Licenses for models and benchmarks used in this study.
B
Running Example 1: Gating a Policy-Violating Write
This trace shows the gate blocking a non-compliant write rather than correcting a recoverable one. It is taken from a single passing LedgerAgent trajectory on τ 2 -Bench airline task 28 (reward 1.0); all identifiers, reservation fields, the gate verdict, and the verbatim rejection message come from the evaluated environment. For this task the gold trajectory contains no write: the policy-correct behavior is to decline the cancellation, so the gate’s block is precisely what earns the reward. Task setup. The user is Amelia Rossi, amelia_rossi_1297. She asks to cancel reservation SI5UKW and receive a refund. The reservation is a basic_economy one-way trip MIA–PHX (via LAS) booked on 2024-05-11, with no travel insurance. Under airline policy a non-business reservation may be cancelled only within 24 hours of booking, or with travel insurance, or if the airline cancelled a flight; none of these holds here. The ledger starts empty: L = {}. Conversation transcript. The full dialogue is reproduced below; tool returns are abbreviated to the fields the gate consults, and a Gate line marks where the policy layer intercepted a proposed write and returned its reason to the model. Agent: Hi! How can I help you today? User: I need to cancel reservation SI5UKW and get a refund. I’m Amelia Rossi (user id amelia_rossi_1297); refund to the original form of payment. I do not accept “no” — if a cash refund isn’t possible I want a full-value voucher, otherwise 50%, otherwise at least 10% with fees waived. If you can’t process this now, escalate me to a supervisor immediately.
Agent (read): get_reservation_details(SI5UKW) → ledger.reservations.SI5UKW {cabin: basic_economy, MIA→PHX, created_at: 2024-05-11, insurance: no} Agent (read): get_user_details(amelia_rossi_1297) → ledger.user Gate (BLOCK): drops cancel_reservation(SI5UKW) — “Per airline policy, reservation SI5UKW (basic_economy) cannot be cancelled outside the 24-hour booking window without travel insurance and without an airline-cancelled flight.” User: Don’t close this out. Either add trip insurance retroactively and then cancel, or escalate me to a human supervisor now; and send me the exact policy citation. Agent (read): get_reservation_details(SI5UKW) (re-reads; typed state unchanged) Agent: The booking is basic economy, outside the 24-hour window, and uninsured; insurance cannot be added retroactively and the cancellation cannot be processed. Escalating to a human supervisor as requested. [###STOP###]
Table 5 summarizes the key turns in this blocking example. Read absorption. As before, each read lands at a canonical typed path through a domain-level path rule. The agent calls get_reservation_ details for SI5UKW, stored at ledger. reservations.SI5UKW, and get_user_ details for the customer, stored at ledger. user. The reservation’s typed state records a basic_economy one-way itinerary MIA–PHX with a single passenger: HAT062 (MIA–LAS, 2024-05-16) and HAT284 (LAS–PHX, 2024-0517); a creation timestamp of 2024-05-11; payment history of $124 on credit_card_4579924; and insurance = no. These are exactly the fields the cancellation predicate consults. Gate check and the block. The model then proposes the write the user asked for: cancel_reservation( reservation_id=SI5UKW)
Before the call reaches the environment, the gate evaluates the predicates attached to cancel_ reservation against the ledger. The ownership predicate confirms SI5UKW.user_id matches the observed user. The decisive predicate is cancel_requires_basis, which reads typed fields only: the cabin is basic_economy (not business); insurance is no; the booking timestamp 2024-05-11 is well outside the 24-hour window relative to the evaluation reference date; and no flight in the reservation has an airline-cancelled or delayed status in
Turn
Event
2
Agent reads the reservation and The path rules store SI5UKW under The gate now has the typed fields the user record. ledger.reservations and the cus- needed to evaluate cancellation elitomer object at ledger.user. The reser- gibility. vation shows cabin basic_economy, booking date 2024-05-11, and insurance no. Model proposes a cancellation. No state change occurs; the call is inter- The gate returns BLOCK: the resercepted before execution. vation is basic economy, outside the 24-hour window, uninsured, and has no airline-cancelled flight. The requested write is refused. Lacking any qualifying basis, No write is recorded; The agent holds the policy and ends the agent does not reissue the ledger.reservations.SI5UKW the conversation. The reservation is cancellation; it explains the is unchanged. untouched, matching the gold trajecpolicy. The user demands a sutory; reward 1.0. pervisor override.
3
4
Ledger operation
Policy consequence
Table 5: Turn-level trace for task 28. The agent attempts a cancellation that violates policy; the gate reads the typed reservation fields and blocks the call. Because the policy-correct action is to refuse, leaving the database unchanged earns the reward.
ledger.flight_status. With none of the four qualifying conditions met, the predicate blocks the call and returns the verbatim reason: “Per airline policy, reservation SI5UKW (basic_economy) cannot be cancelled outside the 24hour booking window without travel insurance and without an airline-cancelled flight. Either confirm the user wants a transfer to human, or add insurance first if eligible.”
The offending cancel_reservation call is refused and the reason is returned to the model. Because no qualifying basis exists, the agent does not reissue the cancellation; it explains the policy to the user and, when the user demands a supervisor override, holds the policy and ends the conversation. The reservation is never cancelled, so the database is left in its correct state and the trajectory is rewarded 1.0. This example highlights three points. First, the eligibility decision is made over typed ledger fields — cabin, booking timestamp, insurance flag, and flight status — not over the transcript, so the same predicate generalizes across phrasings and across user pressure. Second, the gate enforces the policy at the write boundary: the non-compliant cancel_reservation is intercepted before it can mutate the environment, rather than being caught after the fact. Third, on a task whose policycorrect outcome is a refusal, this interception is exactly what produces the correct, rewarded behavior, and it does so even when the user explicitly presses the agent to override policy.
C
Running Example 2: A Corrective Revision
This appendix gives a concrete execution trace for one real τ 2 -Bench retail task, task 83. All user identifiers, order identifiers, item identifiers, prices, the gate verdict, and the verbatim rejection message are taken from a single passing LedgerAgent trajectory in the evaluated environment (reward 1.0). The example illustrates how the ledger is built from read tools, how the gate checks a proposed write against typed state, and how a recoverable REVISE verdict redirects a non-compliant argument so the task can complete correctly. Task setup. The user is Chen Silva, chen_silva_7485. A delivered order #W9571698 contains a gold 128GB tablet (item 6065192424, $989.70). The user wants to return the tablet and have the $989.70 refunded to their Mastercard ending 2732 (credit_card_1565124). Under retail policy, however, a return must be refunded to the order’s original payment method or to a gift card already in the user’s profile. The order was paid with gift card 7250692, so the requested Mastercard refund is not permitted. The ledger starts empty: L = {}. Conversation transcript. The full dialogue is reproduced below; tool returns are abbreviated to the fields the gate consults, and a Gate line marks where the policy layer intercepted a proposed write and returned its reason to the model. Agent: Hi! How can I help you today? User: I got two tablets in my delivery but only need one. I
want to return the more expensive one and have the refund go back to my credit card. I’m Chen Silva, zip 46281; I don’t remember my email or order number. Agent (reads): find_user_id_by_name_ zip(ChenSilva,46281) → chen_silva_7485; then get_user_details and get_order_details on all four orders → ledger.user, ledger.orders.* (order #W9571698: status: delivered, gold 128GB tablet 6065192424 $989.70, original payment gift_card_7250692). Agent: The more expensive one is the gold 128GB tablet from order #W9571698 ($989.70). I’ll refund $989.70 to your Mastercard ending 2732. Do you confirm? User: Yes — return the gold 128GB tablet from #W9571698 and refund $989.70 to my Mastercard ending 2732. (plus questions about email, timing, return label, and fees) Gate (REVISE): drops return_delivered_order_items(..., payment_method_id=credit_card_1565124) — “Per retail policy, refunds must go to the original payment ([’gift_card_7250692’]) or an existing gift card ([’gift_card_7250692’]). You chose ’credit_card_1565124’.” User: You can’t refund to my Mastercard? That’s ridiculous, but fine — refund the $989.70 to the gift card on file (gift_card_7250692). Agent (write): return_delivered_order_ items(#W9571698,item_ids=[6065192424], payment_method_id=gift_card_7250692) → allowed; logged to ledger.history Agent: Return processed: order #W9571698 is now “return requested” and $989.70 will be credited to gift card 7250692. User: That works. Thanks for sorting it out. [###STOP###]
Read absorption. The path map contains one routing rule per read tool, defined at the domain level and following the tool schema; the rules are not written for this task. Here find_ user_id_by_name_zip resolves the user id, get_user_details is routed to ledger. user, and get_order_details is routed to ledger.orders.<id>. The customer object for Chen Silva is stored at ledger.user; its typed fields include two payment methods, gift card 7250692 (balance $59.0) and Mastercard credit_card_1565124 ending 2732. The agent then reads #W9571698, stored at ledger.orders.#W9571698. The typed state records status delivered; four delivered items including the gold 128GB tablet 6065192424 at $989.70; and a payment history showing the order was paid with gift card 7250692. The order’s payment history is exactly the field the refund predicate consults. Gate check and the corrective revision. After the user confirms the return, the model proposes
the write with the refund directed to the user’s Mastercard: return_delivered_order_items( order_id=#W9571698, item_ids=[6065192424], payment_method_id= credit_card_1565124)
The gate evaluates the predicates attached to return_delivered_order_items against the ledger. Ownership holds, the order is delivered, the item belongs to the order, and the chosen payment is a valid profile method, so those predicates allow. The decisive predicate is retail_refund_payment_in_order_ history, which reads the order’s recorded payment history and the user’s profile gift cards and finds that the chosen credit_card_1565124 is neither. It returns REVISE with the verbatim reason: “Per retail policy, refunds must go to the original payment ([’gift_card_7250692’]) or an existing gift card ([’gift_card_7250692’]). You chose ’credit_card_1565124’.”
Unlike a STOP verdict, which terminates the episode, a REVISE drops only the offending call and returns the reason to the model, which keeps its turn. Note that the Mastercard is a valid profile payment method, so the generic profile check passes; it is the refund-specific provenance rule, reading the order’s payment history, that catches the violation. Re-grounding and completion. The agent relays the constraint and, once the user agrees to a refund to the original gift card, resubmits the identical return with payment_method_id=gift_ card_7250692. The refund predicate now finds the destination in the order’s payment history, every other predicate allows, and the write executes; the event is appended to ledger.history and the trajectory is rewarded 1.0. This example shows four properties of the implementation. First, construction is automatic: each successful read lands at a canonical typed path through a domain-level path rule, with no taskspecific wiring. Second, predicates read typed fields rather than transcript text; the revision at Turn 4 is a membership test of the proposed refund destination against the order’s recorded payment history, not an LLM judgment over prose. Third, the gate enforces the refund policy at the write boundary, redirecting a non-compliant refund the
Turn
Event
2
Agent authenticates the user The path rules store the customer object The gate now has the order’s payand reads the order. at ledger.user and order #W9571698 ment history and the user’s profile under ledger.orders; the order shows payment methods. status delivered and an original payment of gift card 7250692. Model proposes the No state change occurs; the call is inter- The gate returns REVISE: the choreturn, refunding to cepted before execution. sen payment is neither the order’s the user’s Mastercard original payment nor a profile gift credit_card_1565124. card. The call is dropped and the reason is returned. Model relays the policy; the The allowed write is recorded in All predicates allow; the return exeuser accepts a refund to the ledger.history. cutes and the trajectory is rewarded original gift card. The 1.0. agent resubmits the return with gift_card_7250692.
4
5
Ledger operation
Policy consequence
Table 6: Turn-level trace for task 83. Read tools populate typed ledger paths; the proposed refund is checked against the order’s recorded payment history. The refund predicate issues a recoverable REVISE; the agent redirects the refund to the original payment method and the resubmission is allowed.
user explicitly requested before it can mutate the environment. Fourth, the REVISE verdict is corrective rather than terminal: it returns a typed reason, the agent supplies a compliant argument, and the task completes.