The news. On June 18, 2026, researchers released LedgerAgent: Structured State for Policy-Adherent Tool-Calling Agents. In standard agents, observations, tool returns, and policy text all live in the prompt, so the model must reconstruct the relevant state every step — which fails two ways: it grounds a decision in a stale or missing fact, or it fires a syntactically valid tool call that still violates a state-dependent policy. LedgerAgent keeps observed state in a separate ledger, renders it back into the prompt, and uses it to check policy before any environment-changing call executes, blocking violations. Across four customer-service domains and a mix of open- and closed-weight models, it raises average pass@k — most under strict multi-trial consistency. Read the paper →
Picture a busy bank window. The customer's story comes in fast and persuasive, and a teller who works from that story — from memory of the conversation — will eventually wire money out of an account that has a hold on it, or to someone whose ID was never checked. The fix every real teller uses is to act from the ledger, not the chatter: the account's facts written down explicitly, so the decision is grounded in what's true, not in what was just said. That is exactly the gap LedgerAgent names in tool-calling agents — when the only record of task state is an ever-growing prompt, the model re-derives the facts each turn and sometimes grounds its next move in a stale one.
LedgerAgent splits the job in two: a structured ledger that holds the task's facts, identifiers, constraints, and conditions, and a policy check that runs against that ledger before any irreversible tool call. The ledger isn't hidden from the model — it's rendered back into the prompt as the canonical state — but it's maintained as its own object rather than scattered through the transcript. Then comes the part that earns the paper its title: before the agent runs an environment-changing tool call — the wire, the refund, the cancellation — LedgerAgent validates the state-dependent policy constraints against the ledger and blocks the call if they fail. A read-only lookup needs no such gate; the gate is reserved for the calls you can't take back. It's the agent-world version of policy enforcement as a layer, checked at the one moment that matters.
| Approach | Where task state lives | Gates irreversible calls? | Failure it leaves on the table |
|---|---|---|---|
| Standard prompt-based (ReAct-style) | Implicit in the growing prompt | No — runs whatever tool the model picks | Acts on a stale fact; valid call still breaks policy |
| Externalized scratchpad / memory | A separate notes store the model writes | No by itself — recall ≠ enforcement | Better recall, but no check at the moment of action |
| LedgerAgent (ledger + policy gate) | A structured ledger, rendered back into the prompt | Yes — validates state-dependent policy before execution | Reports higher pass@k, most under strict consistency |
Why does gating one rare call matter so much? Run the same refund task k = 8 times and suppose each run is 88% likely to stay policy-clean — it occasionally grounds on a stale fact and double-refunds. Score it by average and 88% looks fine. But the strict bar is all eight runs clean at once, and that compounds: 0.88⁸ ≈ 36% (illustrative — the paper reports aggregate gains, not this exact trace). The same per-run slip that barely dents the average collapses the all-clean rate from a naive 88% to about 36%. Now block that one policy-violating refund before it executes and you lift the per-run number toward 1.0 — and because the bar compounds, a small per-run gain becomes a large consistency gain. That is precisely the shape of LedgerAgent's result: modest on the average, largest under stricter multi-trial consistency.
Goes deeper in: AI Agents → The Agent Loop & State → The State Object and Agent Engineering → Layered Guardrails → Policy Enforcement
Related explainers
- Harness-1 — state-externalizing search harness — keeps working memory outside the transcript; LedgerAgent structures that state and adds a policy gate on top
- AgentDoG 1.5 — small inline guard models for agent actions — a learned guard that vets actions, where LedgerAgent uses explicit state-dependent rules
- HarnessBridge — learned agent harness vs hand-engineered — its action projection rejects doomed moves; LedgerAgent rejects policy-violating ones