LedgerAgent: 정책 준수 도구-호출 에이전트를 위한 구조화된 상태 관리

도메인 정책이 환경 변경 행위를 제어하는 상황에서, 전통적 프롬프트 기반 에이전트는 대화 기록에 의존해 상태를 재구성한다. 이로써 관련 사실이 누락되거나 오래된 정보로 근거가 흔들릴 수 있다. LedgerAgent는 관찰된 상태를 schema-anchored ledger에 보존하고 실행 전 정책 게이트로 차단/수정하여 상태-grounding 문제를 해결하고 다중 시도 간 일관성(pass^k)을 향상시킨다.

단계별 개요: (1) 문제 정의: 도메인 정책에 따라 도구 호출이 허용되려면 현재 태스크 상태를 정확히 알아야 한다. 기존 방식은 상태를 대화 기록에 암묵적으로 의존하므로 시점 간 상태 차이가 생길 수 있다. (2) 해결 원리: LedgerAgent는 read-tool 결과를 일정한 schema의 ledger에 기록하고, 실행 직전에 이 ledger를 prompt에 포함시켜 상태를 고정시킨다. 또한 policy gate는 환경 변경 호출 직전에 ledger를 기준으로 predicate를 평가해 허용 여부를 결정한다. (3) 달라지는 점: 모델 가중치를 바꾸지 않고도 상태를 명시적으로 다루고 정책 제약을 확인하므로 다중 턴 환경에서의 일관성 및 신뢰성이 증가한다.

실험 설정에서 LedgerAgent는 두 가지 결정적 구성요소를 가진다: (1) ledger: 성공적인 read-tool 반환을 타입-사전(dictionary) 형태의 ledger에 기록하고, 도메인에 맞는 경로 맵을 통해 ledger 경로에 매핑한다 → 입력으로 주어지는 툴 반환을 기반으로 ledger 업데이트가 발생한다. [입력값으로] 성공적 reads만 ledger에 반영되고, 실패한 도구 호출은 ledger를 업데이트하지 않는다. (2) policy gate: environment-changing call 이전에 ledger를 바탕으로 predicate를 평가하여 allow/revise/block 중 하나를 반환한다. 제시된 도메인에는 총 28개의 게이트 predicate가 존재하며(항공 10, 소매 12, 통신 6), 환불/소유권/지급 수단 등 반복적으로 나타나는 규칙을 encode한다. 알고리즘 흐름은 다음과 같다: 입력 m이 대화에 도착하면 히스토리에 추가하고, read-tool 반환이면 ledger를 업데이트한다. ledger를 렌더링해 C를 생성하고, Generate(H, P, C, T)를 통해 다음 응답을 생성한다. 만약 응답이 환경 변경 호출을 제안하면 GateFilter(a, L, Π)를 적용해 허용/수정/차단 verdict를 얻고, 허용 시 호출을 진행, 수정 시 대안 제안 피드백을 추가하고 재시도, 차단 시 거절 메시지를 반환한다. 이 절차는 base 모델의 호출 수를 증가시키지 않는다(ledger 업데이트, 렌더링, 정책 검사 모두 결정적이므로 추가 LLM 호출이 필요없다).

메인 벤치마크에서는 백본 모델 각 도메인에서 Ledger가 baseline 대비 평균적으로 높은 pass^1 및 pass^4를 달성했다. 예를 들어 Kimi-K2.5에서 Avg pass^1은 54.4→62.3(+7.9pp), Avg pass^4는 69.0→74.0(+5.0pp)로 개선되었다. GLM-5의 경우 Avg pass^1은 51.3→64.6(+13.3pp), Avg pass^4는 66.5→76.0(+9.5pp)로 증가했다. MiniMax M2.5에서 Avg pass^1은 46.2→49.9(+3.7pp), Avg pass^4는 61.5→63.0(+1.5pp) 증가했다. GPT-4.1 백본에서 pass^1은 42.2에서 54.4로, pass^4은 19.9에서 29.3으로 상승했고, GPT-5.2 백본에서 pass^1은 42.6에서 58.1로, pass^4은 18.2에서 34.9로 크게 향상되었다. IRMA와의 비교에서도 Ledger는 토큰 오버헤드를 증가시키지 않는 점에서 우위가 있다. Telecommunication 및 Airline 도메인에서 특히 write-action이 필요한 작업에서 개선폭이 크다. 실험은 τ2^2-bench(항공/소매)와 τ Trait(텔레헬스 제외)에서 수행되었으며, 모델 가중치를 변경하지 않는 점이 강조된다. 결론적으로 LedgerAgent는 상태-grounding과 action-boundary 체크를 통해 정책 준수 도메인에서 도구 사용의 신뢰성과 일관성을 향상시키며, 특히 environment-changing 작업에서 효과를 보인다.

단계 1: Ledger 구조 정의; 도메인별 도구 경로 맵(tool path map)과 환경 변경 도구에 대한 실행 정책(predicate)을 도메인 수준에서 정의한다. 단계 2: Ledger 업데이트; 읽기(read) 도구의 성공적 반환은 ledger의 Typed Path에 매핑된 위치에 저장된다. 입력 형식은 canonical paths로 고정되며, 도메인마다 정해진 구조를 따른다. 단계 3: Ledger-Grounded Generation; 각 턴에서 ledger의 전체 블록을 프롬프트에 추가해 모델이 최신 상태를 쉽게 참조하도록 한다. 단계 4: Policy Gate; 환경 변경 호출 전 gate가 수행되며, allow/revise/block 중 하나의 verdict를 반환하고, revise인 경우에는 거절 이유를 피드백으로 제공한다. 단계 5: Encoder-Decoder 파이프라인 내부: 기본 모델 호출 수는 변경하지 않고, ledger 렌더링과 게이트 실행만 추가되며, 이는 cost invariant를 보존한다. 단계 6: 학습 없이 도메인별 재사용 가능; read-tool 경로 맵과 predicates는 도메인 수준에서 재사용 가능하도록 구성된다.

구현은 구조화된 툴 사용 도메인에 한정되며, 비정형 데이터나 비구조적 입력에는 직접 적용이 어려울 수 있다. Ledger는 관찰된 상태만 담고 있어 관찰되지 않은 사실에 대해서는 증명하지 못한다. 도메인 수준의 정책 규칙은 재사용 가능하지만 자동 유추(induction) 기능은 없다. 벤치마크는 제한된 사용자 시뮬레이터 및 도구 세트에 한정되며, 실서비스 환경의 극단적 상황이나 긴 대화에 대한 일반화는 추가 연구가 필요하다.