PaperlayerView exact revision on arXiv

Source-linked AI summary

LedgerAgent: Structured State for Policy-Adherent Tool-Calling Agents

Md Nayem Uddin, Amir Saeidi, Eduardo Blanco, Chitta Baral

arXiv:2606.20529v1cs.AIcs.CL

TL;DR

Tool-calling agents must maintain task state and obey policies across turns, but prompt-based designs leave state implicit. LedgerAgent makes observed state explicit in a typed ledger and checks environment-changing calls before execution, improving consistency-oriented pass^k across customer-service domains and models.

  • Problem

    Prompt-based tool-calling agents leave task state implicit in expanding context, limiting reliable grounding of actions in relevant facts and policy conditions.

  • Method

    LedgerAgent stores observed tool returns in a schema-anchored typed ledger, renders the ledger in prompts, and checks environment-changing calls before execution.

  • Results

    Across customer-service domains and backbone models, LedgerAgent improves consistency-oriented pass^k, with the largest gains on environment-changing tasks.

  • Takeaways & Limitations

    LedgerAgent supports explicitly representing and checking state that determines whether an action is valid rather than leaving it only in prompt history.

  • Takeaways & Limitations

    LedgerAgent is designed for structured, observable tool-use domains and is less direct when relevant state is unstructured, visual, latent, or unavailable through read tools.

Abstract

from arXiv · show

Policy-adherent tool-calling agents in customer-service 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 \textsc{LedgerAgent}, 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, \textsc{LedgerAgent} improves average pass\textasciicircum{}k over a standard prompt-based tool-calling approach, with the largest gains under stricter multi-trial consistency metrics.

1 Introduction

Policy-adherent tool-calling agents must maintain task state across turns and ensure environment-changing actions comply with current domain policy. LedgerAgent addresses these failures with an explicit typed ledger and pre-action policy gate, improving consistency-oriented pass^k across customer-service domains and models.

  • Introduction: Customer-service agents must retrieve records, maintain relevant interaction state, and act only when domain policy permits.Success depends on more than selecting the correct tool during sustained, multi-turn interaction.
  • Introduction: Prompt-based agents must reconstruct relevant facts from interleaved history, creating risks of stale, missing, or incorrectly reconstructed state.Tool outputs, prior actions, user messages, model generations, and policy instructions are presented together in prompt text.
  • Introduction: The policy gate blocks violating calls and returns feedback identifying the violated rule and conflicting state before the environment changes.This allows the agent to block or revise its plan after a policy conflict is detected.
  • Introduction: LedgerAgent maintains observed state in a schema-anchored typed ledger, re-injects it each turn, and checks proposed environment-changing calls before execution.The ledger projects successful tool returns into canonical paths, while the policy gate evaluates calls against predicates over ledger fields.
  • Introduction: LedgerAgent improves consistency-oriented pass^k across customer-service domains and backbone models, with the largest gains on environment-changing tasks.The evaluation covers four customer-service domains and a mixed panel of open- and closed-weight models; ablations attribute improvement to the typed ledger and policy-gated action.

2 Related Work

Related work advances interactive tool-using agents, inference-time scaffolding, and policy adherence, while LedgerAgent addresses policy-sensitive state tracking through explicit system-level mechanisms. It derives structured state from tool observations and checks proposed write actions before execution.

  • Interactive tool-using agents: Interactive tool-use research has progressed from isolated API calls to multi-turn tasks requiring planning, API selection, valid calls, dialogue, records, domain APIs, and policies.The passage contrasts early benchmarks with newer customer-service settings.
  • Inference-time scaffolding for tool use: Inference-time scaffolding improves tool use by changing procedures around the model through planning, reflection, input reformulation, or multi-agent assistance.These approaches provide decomposition, feedback, additional context, or specialized assistance before subsequent actions.
  • Policy adherence in tool-using agents: Policy-adherence work highlights domain constraints, yet many implementations still place rules in prompts or rely on model reasoning about whether actions are allowed.The passage identifies this reliance as a source of failure when policy applicability depends on state.
  • Policy adherence in tool-using agents: LedgerAgent derives an explicit structured state object from tool observations and checks proposed write actions before execution.This positions state tracking and policy adherence at the model-environment interface.
  • Policy adherence in tool-using agents: LedgerAgent complements model reasoning with system-level state tracking and policy adherence rather than relying primarily on training, prompting, or multi-agent orchestration.The method frames these mechanisms as interface-level controls.

3 Method

LedgerAgent separates observed task state from the dialogue by maintaining a typed ledger and rendering it before each model call. A policy gate then checks proposed environment-changing calls against that ledger before execution, blocking or revising inconsistent actions.

  • Core architecture: LedgerAgent adds a typed ledger of tool-observed task state and a policy gate for environment-changing calls to a standard policy-adherent tool-calling agent.Read-only calls are not gated; environment-changing calls include refunds, order updates, reservation changes, and account changes.
  • Ledger updates: Successful read-tool returns update the ledger at canonical schema paths, while failed tools and write-tool returns do not.After a successful write, the agent must issue a read call to observe the new external state rather than assume it.
  • State rendering: Before each model call, LedgerAgent deterministically renders the full observed ledger alongside dialogue history, policy text, and tool schemas.Stable paths and identifiers make records easier to locate than earlier JSON returns, without replacing the other prompt contents.
  • Policy enforcement: Immediately before execution, the gate evaluates each environment-changing call against predicates over the current ledger and returns ALLOW, REVISE, or BLOCK.ALLOW preserves calls, REVISE removes rejected calls and supplies feedback, and BLOCK ends the attempted environment-changing action.
  • Design boundaries: The gate only verifies ledger-consistent actions; it does not choose tools, repair arguments, fetch records, or plan a new trajectory.In the default configuration, ledger updates, rendering, and policy checks are deterministic wrappers around one base-model generation per turn.

4 Experiments

The experiments compare LedgerAgent with matched standard-agent baselines on structured customer-service tasks across four domains and six models. Evaluation uses four independent trials per task, reporting pass^1 for success and pass^4 for consistency.

  • Experimental setup: Tasks from τ 2-bench and τ-Trait provide a user goal, initial database state, domain policy, and tools for dialogue-based completion.The four domains include airline, retail, telecom, and telehealth, covering grounding writes, dual-control behavior, and single-control tool use.
  • Experimental setup: LedgerAgent and each standard-agent baseline use identical policies, tools, histories, decoding settings, model calls, and user simulators.LedgerAgent additionally renders the observed ledger and, except in telehealth, checks proposed environment-changing calls with a policy gate.
  • Experimental setup: Six agent models are evaluated: GPT-5.2, GPT-4.1, Kimi K2.5, GLM-5, MiniMax-M2.5, and Qwen3-30B.Each LedgerAgent condition is compared with a standard-agent baseline built from the same underlying model.
  • Evaluation: Four independent trials are run per task and domain–model–agent cell; pass^1 measures main success, while pass^4 measures consistency.Rewards come from benchmark checks of task-specific database, action, communication, and natural-language outcomes.

5 Results

Ledger improves task success and consistency across non-GPT and GPT backbones, outperforming both standard function calling and IRMA. Gains are especially evident on environment-changing tasks, where reliable state tracking supports write actions.

  • Cross-Model Generalization: Ledger improves over standard Function Calling across Kimi-K2.5, GLM-5, and MiniMax M2.5 backbones.Average pass^1 gains are 3.4, 4.7, and 7.3 points, while average pass^4 gains are 5.6, 7.6, and 8.3 points, respectively.
  • Cross-Model Generalization: 12.2 and 15.5 points: Ledger’s average pass^1 gains over FC with GPT-4.1 and GPT-5.2 backbones, respectively.The GPT comparison covers only retail and airline environments because these models are more costly; comparable improvements are observed in pass^4.
  • Comparison with Agentic Context-Engineering Methods: Ledger outperforms IRMA by 3.7 points in pass^1 and 7.4 points in pass^4 without additional token overhead.IRMA incurs more than 50% token overhead from using three helper agents.
  • Performance on Environment-Changing Tasks: Write-action tasks comprise 26 of 50 Airline tasks and 104 of 114 Retail tasks.These tasks require at least one write action that changes environment state and may not be reversible.
  • Performance on Environment-Changing Tasks: Ledger consistently outperforms baselines on tasks involving environment-changing tool calls, with especially notable action-level gains in Telecom.The results support improved state tracking and careful execution of write actions.

6 Error Analysis

LedgerAgent failures are dominated by omitted required actions rather than incorrect arguments, often arising when edge cases prompt premature termination or human transfer. Failure profiles vary by domain, with airline showing greater diversity and telehealth the highest wrong-argument rate.

  • Error Analysis: Missed required actions and wrong action arguments account for 90.7% of failures, representing 70.3% and 20.4%, respectively.Agents therefore omit expected tool calls far more often than they invoke the correct tool with incorrect arguments.
  • Error Analysis: Agents often complete initial lookups but terminate or transfer to human support when edge cases arise instead of continuing policy-compliant write actions.The remaining 9.3% comprises extra or unauthorized actions, reasoning errors or loops, policy violations, communication failures, and authentication or identification failures.
  • Error Analysis: Retail failures are primarily missed actions at 69.9%, followed by wrong arguments at 20.0%, often after payment or eligibility constraints.Agents may transfer rather than follow valid modify-payment or partial-fulfillment paths.
  • Error Analysis: Telecom failures commonly involve failing to invoke a required permission-grant tool or a required transfer step.
  • Error Analysis: Airline has the most diverse failure profile, with missed actions at 47.7% and wrong arguments at 33.9%.It also contributes the largest number of extra or unauthorized actions, often after user pushback leads to policy-disallowed flight changes or cabin downgrades.
  • Error Analysis: Telehealth has the highest wrong-argument rate at 25.9%, reflecting more complex tool schemas with fields such as provider_id and appointment_type.The supplied passage also lists bill_insurance and paym… as schema fields.

7 Conclusion

LedgerAgent makes observed task state explicit through a typed ledger and checks environment-changing tool calls against that state before execution. Across customer-service domains and backbone models, it improves policy-adherent tool use without changing model weights, with largest gains on consistency-oriented pass^k metrics and tasks requiring environment-changing actions.

  • Conclusion: LedgerAgent uses a schema-anchored ledger to store successful read-tool returns as typed state and a policy gate to check proposed environment-changing calls before execution.These components address state-grounding failures involving stale, missing, or incorrectly reconstructed information.
  • Conclusion: LedgerAgent improves policy-adherent tool use across customer-service domains and backbone models without changing model weights.The largest gains occur on consistency-oriented pass^k metrics and tasks requiring environment-changing actions.
  • Conclusion: Remaining failures are mostly missed actions and domain-specific argument errors, so explicit state and write-time verification reduce but do not eliminate unreliability.The error analysis identifies these failure types after applying the ledger and policy gate.

8 Limitations

LedgerAgent is designed for structured, observable tool-use domains and relies on developer-defined schemas, read-tool mappings, and executable policy predicates. Its evaluation and deployment costs are scoped by benchmark coverage, prompt overhead, and implementation effort.

  • State representation limits: LedgerAgent is less direct when relevant state is unstructured, visual, latent, or unavailable through read tools.The ledger contains only observed state and assumes tool returns expose stable fields mappable to a domain schema.
  • Specification requirements: Developer-defined read-tool path maps and executable policy predicates require domain-level specifications rather than automatic policy induction.These specifications are reusable across tasks and require no additional model training.
  • Evaluation scope: The evaluation covers four structured-API customer-service domains with a fixed user simulator, limiting claims about live users, adversarial behavior, changing policies, and production traffic.Four independent trials per task support pass^4 consistency analysis but do not characterize very long dialogues or rare failure modes.
  • Deployment costs: LedgerAgent keeps the standard agent’s number of LLM calls but adds prompt, schema, predicate, implementation, and testing costs.These costs are most compelling for structured tool returns and clear recurring policies, and may be less justified for simple tasks.

A Licenses

The study uses models and benchmarks from various sources, with their licenses listed in Table 4.

  • The work uses models and benchmarks from various sources.
  • Table 4 lists the licenses for the models and benchmarks used in the study.

B Running Example 1: Gating a Policy-Violating Write

In airline task 28, LedgerAgent blocks a cancellation lacking any qualifying policy basis, rather than allowing an environment-changing write. The typed ledger enables a pre-execution eligibility check, leaving the reservation unchanged and earning reward 1.0.

  • Conversation outcome: Because the policy-correct action is to decline cancellation, the database remains unchanged and the passing trajectory receives reward 1.0.The example is a single passing LedgerAgent trajectory on τ 2-Bench airline task 28.
  • Task setup: Task 28 permits cancellation only within 24 hours, with travel insurance, or after an airline-cancelled flight; none applies to reservation SI5UKW.The booking is basic_economy, created on 2024-05-11, uninsured, and outside the 24-hour window.
  • Conversation outcome: The block returns the policy reason to the model, which refuses to reissue the cancellation despite the user’s requests for retroactive insurance or supervisor escalation.The agent explains that insurance cannot be added retroactively, holds the policy, and ends the conversation.
  • Gate check and the block: The gate checks ownership and typed reservation fields before execution, then blocks cancel_reservation when no qualifying condition is met.The decisive predicate is cancel_requires_basis, which reads cabin, insurance, booking timestamp, and flight status from the ledger.
  • Design takeaway: The example illustrates that typed ledger predicates enforce policy at the write boundary and remain independent of transcript phrasing or user pressure.The non-compliant write is intercepted before it can mutate the environment, rather than being detected after the fact.

C Running Example 2: A Corrective Revision

The trace shows LedgerAgent building typed state from read tools, blocking a refund that violates payment provenance, and recovering through a compliant revision. After the user agrees to the original gift-card destination, the corrected write executes and the task receives reward 1.0.

  • Re-grounding and completion: The passing trajectory completes with reward 1.0 after the refund is redirected to the original payment method.The example is drawn from one real τ 2-Bench retail task, task 83.
  • Read absorption: Read tools populate canonical typed ledger paths for the user and order, including payment methods, order status, item details, and payment history.The path map routes user and order reads automatically, without task-specific wiring.
  • Re-grounding and completion: After the user agrees, the agent resubmits the return with gift_card_7250692, the refund predicate allows it, and the write executes.The event is appended to ledger.history.
  • Gate check and the corrective revision: The gate allows ownership, delivery, item-membership, and profile-payment checks but rejects the Mastercard refund because it is absent from the order’s recorded payment history.The refund-specific provenance predicate returns REVISE even though the Mastercard is a valid profile payment method.
  • Gate check and the corrective revision: A REVISE verdict drops only the offending write, returns a typed reason, and preserves the agent’s turn for correction rather than terminating the episode.This differs from STOP, which terminates the episode.
Loading 2606.20529v1…