LedgerAgent: Policy를 준수하는 Tool-Calling 에이전트를 위한 구조화된 State 관리

TL;DR Highlight

고객서비스 AI 에이전트가 정책을 위반하는 tool call을 실행 전에 차단하는 '원장(Ledger)' 기반 상태 관리 방법론

Who Should Read

고객서비스, 예약, 결제 등 비즈니스 정책을 지켜야 하는 tool-calling 에이전트를 개발하는 백엔드/AI 개발자. 특히 멀티턴 대화에서 tool 반환값을 기반으로 정책 준수 여부를 검증해야 하는 상황에 처한 개발자.

Core Mechanics

기존 에이전트는 tool 반환값을 그냥 프롬프트에 쌓아두는데, 대화가 길어지면 모델이 예전 정보를 잘못 참조하거나 빠뜨리는 'state grounding 실패'가 발생한다.
LedgerAgent는 tool 성공 반환값을 schema-anchored typed dictionary(Ledger)에 따로 저장하고, 매 턴마다 이 Ledger를 프롬프트에 추가로 주입해서 모델이 현재 상태를 정확히 참조하게 한다.
환경을 변경하는 tool call(주문 취소, 환불 처리 등)은 실행 전에 'Policy Gate'를 통과해야 하고, Gate는 Ledger 필드를 기반으로 정책 준수 여부를 코드 predicate로 검사한다.
Gate 결과는 3가지: ALLOW(그대로 실행), REVISE(위반 이유를 모델에 돌려줘서 수정 기회 제공), BLOCK(거부 및 종료).
Ledger 업데이트와 Policy Gate는 모두 deterministic 연산이라 추가 LLM 호출이 없다. 토큰 오버헤드만 있고 API 비용은 기존 에이전트와 동일.
GPT-5.2, GPT-4.1, Kimi K2.5, GLM-5, MiniMax M2.5, Qwen3-30B 등 6개 모델에서 모두 성능 향상이 확인돼 특정 모델에 종속되지 않는다.

Evidence

GPT-4.1 백본 기준 pass^1(1번 시도 성공률) +12.2pp, pass^4(4번 모두 성공하는 일관성) +10.1pp 향상 (retail+airline 도메인).
GPT-5.2 백본 기준 pass^1 +15.5pp 향상.
비교 대상인 IRMA(헬퍼 에이전트 3개를 쓰는 방법)보다 pass^1 +3.7pp, pass^4 +7.4pp 높으면서 IRMA는 토큰 53.1% 오버헤드인 반면 LedgerAgent는 토큰 오버헤드 0% (추가 LLM 호출 없음).
MiniMax M2.5 기준 average pass^1 +7.3pp, average pass^4 +8.3pp 향상. 실패 분석에서 남은 오류의 90.7%는 'missed required action'과 'wrong action arguments'로, 정책 위반 자체는 크게 줄었음을 시사.

How to Apply

도메인별로 tool path map(어떤 tool 반환값을 어느 경로에 저장할지)과 policy predicate(어떤 조건을 위반하면 막을지)를 코드로 한 번만 작성하면 된다. 예: 항공권 취소 에이전트라면 `cancel_reservation` tool에 '24시간 이내 예약인가', '여행자 보험이 있는가'를 체크하는 predicate를 붙인다.
에이전트 루프에서 tool 반환값을 받을 때마다 Ledger에 흡수(Absorb)하고, 모델 호출 전에 Render(L)로 Ledger 블록을 프롬프트에 추가하면 된다. 환경 변경 tool call 직전에 GateFilter(a, L, Π)를 실행해서 ALLOW/REVISE/BLOCK을 결정한다.
REVISE 결과를 받으면 위반 이유를 모델에게 피드백으로 넘겨서 스스로 수정하게 한다. 예: 환불 payment method가 원래 결제 수단이 아닌 경우, 어떤 payment method를 써야 하는지 이유와 함께 모델에 돌려주면 모델이 올바른 인자로 재시도한다.

Code Example

snippet

Terminology

tool-calling agentLLM이 외부 API나 함수를 직접 호출해서 작업을 수행하는 에이전트. 챗봇이 항공권 조회 API를 직접 호출하는 것처럼.

pass^k같은 태스크를 k번 독립 시도했을 때 모두 성공하는 비율. k=4면 4번 다 성공해야 카운트되므로 일관성을 엄격하게 평가하는 지표.

state grounding에이전트가 행동할 때 현재 실제 상태(예: 예약 정보, 주문 상태)를 정확히 참조하는 것. 이게 실패하면 오래된 정보나 잘못된 정보를 기반으로 행동함.

Policy Gate환경을 바꾸는 행동(write action)을 실행하기 직전에 비즈니스 정책을 코드로 검사하는 검문소. 통과 못하면 실행 자체를 막음.

predicate특정 조건이 참/거짓인지 검사하는 함수. 여기서는 'ledger에 저장된 상태값이 정책 조건을 만족하는가'를 검사하는 코드 함수.

inference-time method모델 학습(fine-tuning) 없이 추론(실행) 시점에만 적용하는 방법. 모델 가중치를 바꾸지 않고 주변 시스템을 개선하는 방식.

dual-control에이전트뿐 아니라 사용자 시뮬레이터도 공유 데이터베이스를 변경할 수 있는 설정. 상태가 양쪽에서 바뀌므로 state tracking이 더 어려움.

Related Resources

https://github.com/tau-bench/tau2-bench

Original Abstract (Expand)

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.