8 minute read

Meta info.
  • Authors: Zhuochun Li, Youngmin Ko, Ali Keramati, Nicola Ferri, Susana Palmaz Lopez Pelaez, Liang-Chun Tsai, Calvin Wang, Mirco Milletari, Tuhin Kundu, Vadim Smolyakov, Kjartan Ólafsson, Tommy Guy
  • Affiliation: University of Pittsburgh; Northwestern University; University of California Irvine; Microsoft
  • Paper: https://arxiv.org/abs/2608.19741
  • Code: https://github.com/microsoft/thinkingbox
  • Published: August 20, 2026 (arXiv preprint)
Slide 1 Slide 2
Slide 3 Slide 4
Slide 5 Slide 6
Slide 7 Slide 8
Slide 9 Slide 10

Slide 11

TL; DR

격리된 MCP tool session 위에서 agent-simulated user interaction상에서 terminal backend state와 side effect로 scoring하는 프레임워크(sandbox) ThinkingBox와 5개 domain의 507개 task 벤치마크 제안. 20회 반복 시행에서 최고 성능 모델조차 pass@20 91.12% 대비 pass^20 25.25%로 떨어지는 discovery-reliability 간 격차 확인.
  • 왜: 최근 agent 평가는 executable한 산출물(patch test, function call 실행, terminal state)로 수렴하나, 그 방향은 outcome을 명세하기 쉬운 task만 벤치마크화
    • 예약 변경/환불/claim 갱신처럼 multi-turn + stateful + side effect에 책임이 따르는 실제 업무들과 괴리
    • valid한 tool-call 스타일의 현존하는 벤치마크들의 측정과 실제 결과적으로 완료된 업무 사이의 간극이 측정되지 않음.
  • 제안:
    • world instantiation, MCP tool, simulated user, side-effect 추출, executable check를 한 loop에 넣은 프레임워크(sandbox) ThinkingBox
    • 5개 domain의 507개 task로 구성된 Thinkingbox-bench
    • scoring: terminal backend state와 side effect의 product(곱)로
      • 반복 시행 metric은 pass@k와 pass^k를 분리 보고.
  • 발견: 최고 성능 모델(GPT-5.4)도 pass@1 65.36%, domain 간 편차가 큼
    • retail 76 vs. auto insurance 63 등…
    • 다른 모델은 70대에서 10~20대까지 큰 폭으로 성능 붕괴 확인
    • 20회 반복에서 pass@20 91.12% vs. pass^20 25.25%로 성공 trajectory는 발견되지만 재현되지 않는다고 주장
      • 실패의 77.5%가 tool error 뒤 recovery 실패
      • 약한 metric(clean termination + mutating call + no error)로 보면 실패의 67%가 성공으로 보인다고

Review Video

ThinkingBox figure 0 ThinkingBox figure 1 ThinkingBox figure 2 ThinkingBox figure 3 ThinkingBox figure 4 ThinkingBox figure 5 ThinkingBox figure 6

Background

  • 최근 agent 평가는 실행 가능한 산출물에 근거를 두는 방향으로 수렴
  • 실무에는 code도 tool-call trace도 아닌 일들이 존재
    • e.g. 예약 변경, 환불 처리, 보험 claim 갱신, 사내 서비스 요청 라우팅…
    • multi-turn + stateful + 결과에 책임이 따름
    • user interaction과 tool 사용과 policy 제약과 backend side effect를 동시에 조율해야 함
  • Related Work Tab 1
    1. sandbox와 conversational tool use
    2. executable과 professional-work
      • AppWorld (Trivedi et al., 2024): state 기반 테스트로 대안 해법을 허용하면서 collateral change를 잡아냄
      • WorkArena++가 enterprise workflow를, CRMArena 계열이 multi-turn 전문 interaction을 겨냥함 (Boisvert et al., 2024; Huang et al., 2025b)
      • MCP 계열은 MCP-Bench가 live-server tool discovery, MCPMark가 프로그램적 검증이 붙은 CRUD, MCP-Atlas가 실서버 대규모 진단을 다룸 (Wang et al., 2026b; Wu et al., 2026; Bandi et al., 2026)
      • AppWorld가 side-effect까지 갖췄으나 dialogue와 MCP가 없고
      • $\tau$-bench 계열이 dialogue와 stateful backend를 갖췄으나 side-effect가 부분적

Problem States

  • valid한 tool call과 완료된 업무 사이의 간극이 측정
    • 구문적으로 유효하거나 실행 가능한 호출을 만들었는지만 검증하는 게 아니라, 그 호출이 달성하려던 일이 진짜 끝났는지 검증
    • 4 challenges:
      • agent가 맞는 API를 틀린 entity에 call
      • agent가 필수 확인을 받기 전에 record를 update
      • agent가 그럴듯한 안내를 하면서 backend는 바꾸지 않음
      • agent가 policy를 위반하는 여분의 side effect를 발생시킴
  • execution substrate와 벤치마크가 분리되어 재사용되지 않음
  • 단일 시행하는 metric은 발견과 재현을 구분하지 못함
    • 한 번이라도 성공 trajectory를 찾는 능력(=발견)과 매번 같은 결과를 내는 능력(재현)이 pass@1으로는 확인 불가
  • [env] 시도 간 상태가 절대 섞이지 않는 격리가 보장된 tool session과 deterministic reset
  • [scoring] trajectory의 표면적 형태가 아니라 terminal state와 side effect를 보되, wrong/missing/extra effect를 모두 배제
  • [metric] 발견과 재현을 분리해 보고하는 반복 시행 보고
  • [user] 초기 요청에 정보를 다 담지 않아 elicitation을 강제하되, 모든 agent에 대해 고정되어 비교 가능성을 보장하는 simulator

Suggestions

POMDP task formulation

\[x = (b_0, g, \mathcal{T}, \mathcal{U}, \mathcal{C})\]
  • $b_0$: 초기 backend state
  • $g$: user goal
  • $\mathcal{T}$: domain tool 집합
  • $\mathcal{U}$: simulated user policy
  • $\mathcal{C} = \lbrace c_i \rbrace_{i=1}^{m}$: agent에게는 감춰진 executable check 집합
\[\mathcal{M}_x = (\mathcal{S}_x, \mathcal{A}_x, \mathcal{O}_x, P_x, Z_x, R_x, \mu_x, H)\]
  • finite-horizon POMDP 유도
    • latent state $s_t = (b_t, z_t, \ell_t, q_t)$: backend 상태, user의 사적 상태, evaluator용 event log, episode 상태
      • agent는 이 latent state를 직접 관측하지 못함. observable history $h_t = (o_0, a_0, \ldots, o_t)$에 대해서만 policy가 작동
    • action은 user-facing message / tool call / termination 셋 중 하나
    • reward는 sparse & terminal: 중간 step에 부분 점수 없이 episode 종료 시 check 통과 여부로만 한 번 주어짐
    • reset이 deterministic이라 initial state distribution $\mu_x$는 $s_0$ 한 점에 몰린 point mass. 시도 간 결과 차이가 시작 조건이 아니라 agent와 simulated user의 sampling에서만 온다는 전제
  • agent만 상태를 바꾸는 tool 호출
    • simulated user는 정책이 아니라 환경 dynamics의 일부로 처리된다고. agent policy 차이만으로 성능 귀결

ThinkingBox: A Sandbox for Tool-Agent-User Interaction

  • simulated user, LLM agent, 격리된 domain tool, side-effect 추출, executable judge를 하나의 재현 가능한 loop로 통합 Fig 2
    • 동일한 trajectory-level 판정이 benchmark 평가 / failure 분석 / agent 학습에 모두 사용됨
    • 개별 check가 reward vector $r_i(\rho) = c_i(b_T, e, \rho)$로도 쓰여, agent policy만 교체하고 나머지를 그대로 재사용 가능
  • 매 시도마다 $b_0$로 reset, 전체 state 초기화, 격리된 tool session 생성, trajectory 기록
    • 동일 task의 두 시도가 DB row나 캐시된 tool state나 side effect를 공유해서는 안 됨. 공유 시 pass@k와 학습 reward를 신뢰할 수 없음
    • 편의가 아니라 metric 타당성의 전제. 뒤집어 말하면 시도 간 학습이나 지속성이 구조적으로 배제됨

Side-Effect-Centered Scoring

  • side effect $e = \Delta_x(s_0, s_T, \rho)$는 초기 state와 최종 state와 trajectory를 비교해 추출. 어떤 변화를 뽑을지는 task마다 지정
  • 최종 판정(verdict) $V(x,\rho)$는 check들의 곱
\[V(x, \rho) = \prod_{i=1}^{m} c_i(s_T, e, \rho), \qquad c_i \in \lbrace 0, 1 \rbrace\]
  • product(AND)로 scoring: 모든 조건이 성립해야 통과
  • 서로 다른 유효 trajectory에 credit을 주되, 잘못/누락/초과된 지속 효과는 기각
  • 잘못된 user record 수정, 미승인 갱신 같은 collateral effect 탐지 가능
  • 두 가지 scoring 항목
    • DB 조회로 판정(477건): 환불 record 생성 여부, ticket 상태, 무관한 고객 record 변경 여부. 가능
      • DB만 맞으면 최종 응답 내용과 무관하게 통과
        • e.g. 환불을 제대로 처리해 DB는 정답이지만 마지막 응답으로 사용자에게 “환불이 거절되었습니다”라고 해도 통과
    • agent가 마지막에 한 말까지도 판정(30건): 기밀 정보 발설 안했는지, policy 제약 사유의 명시적 전달. 즉 DB 조회 수준으로 판정 불가.
      • LLM judge를 요구하는 sccoring
        • 507건 전부에 부여하면 낮은 pass^20이 agent 불안정성인지 judge 변동성인지 구분 불가하여 소수개만 구축
        • judge 개입이 전체의 5.9%로 제한: GPT-5.4-mini
          • judge가 user simulator와 동일하고 최고 성능의 agent와도 같은 계열이라는 점은 한계로 보임

Simulated User

  • 상태를 바꾸는 tool을 agent만 호출하므로 simulated user는 정책이 아니라 환경의 일부
    • 모든 agent에 대해 고정되므로 leaderboard 두 행의 차이가 agent policy 차이만으로 귀속됨
  • 대화 이력에서 tool call과 tool 결과와 reasoning trace가 제거된 뷰만 받음
    • agent보다 엄격히 덜 관측함. tool error를 못 봐서 실수한 agent를 살려내지 못하고, agent가 말하지 않은 backend 상태를 되풀이하지 못함
  • agent가 완료 마커를 내거나 end-turn tool을 호출해야 종료. 없으면 10턴 후 user-limit으로 기록되고 정상 종료 시행과 구분 저장됨
  • 입력 필드가 sanitize를 거쳐 task 데이터나 agent 출력이 prompt 구조나 가짜 종료 신호를 위조하지 못함

Thinkingbox-bench: 507 executable tasks / 5 domains Tab2

  • 각 task = 초기 state + user goal + domain tool + simulated user policy + executable check
    • domain은 격리된 MCP 호환 server로 노출. 실제 배포 형태에 근접하면서 reset과 isolation과 logging과 scoring은 통제
    • 달성해야 할 것과 피해야 할 것을 함께 명세: policy 제약, 기대 state 변화, 금지된 collateral 변화, dialogue 요구사항
    • user goal은 opening request + 별도 공개 가능 fact set으로 분할
      • fact는 agent가 물어봐야만 공개 → 명확화 질문, 부적격 거부, 비가역 갱신 전 확인이 필요해짐
  • 3단계로 구축
    • workflow design: domain별 template 작성. raw user log 미공개, 전부 synthetic record
    • executable task instantiation: 초기 state, MCP tool, user 명세, 정책 부착 후 check 작성
    • validation and filtering: 실제 실행하여 broken tool, 모순된 초기 state, 모호한 목표, trajectory에 의존하는 check, 종료 실패 사례 제거
      • 모델 실패 자체는 task 결함의 증거가 아니고, trajectory가 task나 evaluator의 결함을 드러낼 때만 수정을 촉발
  • pass@k는 $k$회 중 최소 1회 성공, pass^k는 $k$회 전부 성공. 전자가 발견을, 후자가 재현을 측정
    • $\tau$-bench의 unbiased $k$-fold estimator $\binom{c_i}{k}/\binom{n}{k}$는 성공 횟수가 $k$보다 작으면 반드시 0이라 어려운 task에서 모델 간 분해능이 사라짐
    • 그래서 편향을 감수하고 plug-in estimator를 사용
\[\text{pass@}k = \frac{1}{M}\sum_{i=1}^{M}\left(1 - \frac{\binom{n-c_i}{k}}{\binom{n}{k}}\right), \qquad \text{pass}^k = \frac{1}{M}\sum_{i=1}^{M}\left(\frac{c_i}{n}\right)^{k}\]

Effects

Experimental setup

  • 12개 model (proprietary 6 + open-weight 6), Table 11에 MiniMax-M2.5와 Qwen3-8B 추가
    • proprietary: GPT-5.2, GPT-5.4, o3-pro, Claude Sonnet 4.6, Claude Opus 4.6, Grok-4.3
    • open-weight: DeepSeek-V4-Pro, GLM-5.1, Kimi-K2.6, Mistral-Large-3, Qwen3.6-27B, Qwen3.5-9B
  • task당 $N = 20$ 독립 trial, 모델당 10,140 trial, micro-average
  • simulated user와 response judge: 양쪽 모두 고정된 GPT-5.4-mini 사용
    • agent temperature 1.0에 reasoning medium, user 0.3, judge 0.0
    • simulator sampling이 deterministic하지 않음. 그래서 20회 시행이 agent 행동뿐 아니라 user 표현 분포에 대한 robustness도 포함한다고 주장.
  • evaluation
    • 모든 모델에 같은 system prompt, tool 정의, policy, simulated-user 행동, check를 적용
    • 모든 check를 통과해야 정답이고, 디코딩 실패와 API 에러 같은 시스템 오류는 실패로 계상
    • Azure 호스팅 Chat Completions를 쓰고 Qwen 계열만 vLLM으로 로컬 서빙

Results

Discovery-Reliability Gap Fig 1(B), Tab 11

  • 최고 성능 모델 GPT-5.4: 성공 trajectory는 발견 가능하나 신뢰성 있게 반복되지 않음
    • 최소 1회 성공한 task는 91.12%, 20회 전부 성공은 25.25%
    • 20회 모두 실패한 task 45개 대 20회 모두 성공한 task 128개

Domain-Level Analysis Tab 4

  • Retail 평균 약 52% 대 Auto insurance 약 23% 등 도메인별 차이 발생
    • task 수는 비슷하므로 task 수가 아니라 policy와 interaction 부담이 난이도를 만든다고 판단
  • 강한 모델이 항상 좋은 성능을 내진 못했다고: 한 workflow 계열의 성능이 다른 stateful 세팅으로 transfer되지는 않더라
  • 전 domain 50% 이상은 GPT-5.4와 Sonnet 4.6뿐
  • Sonnet 4.6이 51.14에서 68.93 사이로 가장 균형적

Failure Mode 분포 Tab 5

  • 실패의 대부분이 실행이 아니라 recovery에서 발생
  • Tool Usage 77.5%
    • tool error, 실패한 전제조건, 조회 실패 발생 후 workflow를 recovery하지 못함
    • 단순히 malformed tool call이 아니라, 환경이 만든 feedback으로부터 recovery하지 못하는 실패
    • 일부는 실패한 action이 성공한 것처럼 계속 진행
  • Wrong State Update 12.1%
    • 동작상 성공처럼 보이고 agent가 완료를 자신 있게 확인하는데 terminal DB state는 요구사항 위반
      • trajectory에 흔적이 없어 executable check 없이는 잡히지 않는다고
  • Limitation
    • judge와 simulated user가 모두 GPT-5.4-mini라 최고 성능을 낸 GPT-5.4와 같은 모델 계열이라는 부분 한계로 인정.
    • simulated user가 사실을 잘못 기억하지도, 목표를 바꾸지도, 비협조적으로 굴지도 않음. 보고된 pass rate은 잘 행동하고 정보가 제한된 상대를 상대로 한 숫자라고.
    • 모든 record가 합성이긴 하다는 점..

Personal note. 파일 시스템 접근 권한이 없는 실행환경이라서 현재 시작하려는 연구에서는 주요하게 다룰 것 같은 setup은 아니지만, 이 페이퍼를 좀 꼼꼼히 보면서 어떤 벤치마크를 써야할지는 기준이 생긴 것 같습니다. 가령 앞서 언급한 파일 읽고 쓰는 권한이 있는지나 metric 측면에서 다회 모두 성공하는 경우를 분리해서 보고하는 것, 가능하다면 session 이 있어서 memory 등을 반드시 참조하게끔 하도록 구성된 환경이 있다면 적극적으로 주요 벤치마크로 살펴보게 될 것 같습니다.