Agents’ Last Exam Review

0. Introduction

Paper link

Project page

Code link

Dataset link

한 줄 요약: Agents’ Last Exam, ALE는 AI agent를 지식형 문제풀이가 아니라 실제 전문직 workflow 수행 능력으로 평가하려는 benchmark이며, 13개 industry cluster와 55개 subfield에 걸친 long-horizon computer-use task를 VM, hidden reference, executable evaluator로 검증한다.

이 논문을 지금 볼 가치가 있는 이유는 다음과 같음.

• Agent benchmark의 중심이 단순 QA, web browsing, code issue 해결에서 실제 professional workflow로 이동하고 있다.
• ALE는 task를 synthetic puzzle로 만들지 않고, domain expert가 실제로 수행한 업무를 benchmark instance로 바꾸려 한다.
• 평가 기준이 LLM-as-judge 중심이 아니라, hidden reference, deterministic check, structured rubric, deliverable verification 쪽에 강하게 걸려 있다.
• CLI, GUI, file system, domain software, long-horizon planning이 한 task 안에서 같이 요구되는 Generalist Computer-Use Agent setting을 명확히 정의한다.
• 현재 frontier agent들도 hardest tier에서 거의 포화되지 않았기 때문에, agent system의 다음 병목을 보기 좋은 benchmark다.

이 논문의 핵심 메시지는 “agent가 benchmark를 잘 푼다”와 “agent가 실제 일을 한다” 사이의 간극을 benchmark 설계 문제로 정식화했다는 점이다. 지금까지 많은 agent benchmark는 공개 웹, 공개 API, coding task처럼 환경을 만들기 쉬운 쪽에 치우쳤다. 반면 실제 경제적 가치가 큰 일은 CAD, ERP, finance workbook, domain-specific simulator, desktop software, private file bundle 같은 복잡한 작업 환경을 가진다.

ALE는 바로 이 간극을 정면으로 다룬다. 좋은 agent 평가를 만들려면 더 어려운 질문을 많이 모으는 것만으로는 부족하다. 실제 업무의 input, software, output artifact, reference, evaluator까지 하나의 실행 가능한 평가 단위로 묶어야 한다.

1. Problem Setting

1-1. Problem definition

이 논문이 겨냥하는 문제는 현재 agent benchmark가 실제 professional work의 세 가지 성질을 동시에 잡지 못한다는 점이다.

1. Realism
   • task가 실제 업무에서 온 것인가.
   • domain expert가 쓰는 software와 data format을 유지하는가.
   • 단일 click이나 toy command가 아니라 end-to-end deliverable인가.
2. Breadth
   • 특정 software나 특정 직군에만 묶이지 않는가.
   • professional work의 큰 영역을 taxonomy 수준에서 덮는가.
   • 새로운 workflow와 industry를 지속적으로 추가할 수 있는가.
3. Verifiability
   • 결과물이 맞았는지 자동으로 검증할 수 있는가.
   • human judge나 broad LLM judge에 지나치게 의존하지 않는가.
   • output artifact가 heterogeneous하더라도 점수화 가능한가.

이 세 가지를 동시에 만족시키는 것이 어렵다. 예를 들어 SWE-bench는 software engineering issue 해결에는 강하지만 finance, manufacturing, architecture, design, biomedical workflow를 포괄하지는 않는다. OSWorld나 WebArena는 computer-use 능력을 보지만, 산업별 전문 업무 전체를 대표한다고 보기는 어렵다. Human expert evaluation은 현실성은 높일 수 있지만 비용이 크고, 반복 가능한 leaderboard 운영에는 불리하다.

ALE는 이 문제를 다음 질문으로 바꾼다.

Question	ALE의 답
어떤 일을 평가할 것인가	실제 전문가가 과거에 수행한 software-mediated workflow
어떤 taxonomy를 쓸 것인가	O*NET / SOC 2018 기반의 13개 cluster, 55개 subfield
agent가 무엇을 받는가	task description, visible input, target software, VM environment
무엇을 제출하는가	output directory 안의 file, model, report, scene, workbook, database state 등
어떻게 채점하는가	hidden reference와 evaluate() 기반 deterministic check 또는 structured rubric
왜 오래 유지되는가	public/private split과 rolling evaluation으로 contamination을 줄임

1-2. Why previous approaches are insufficient

기존 benchmark가 충분하지 않은 이유는 단순히 난도가 낮기 때문이 아니다. 더 근본적인 문제는 평가 unit이 실제 업무 unit과 다르다는 점이다.

첫째, knowledge benchmark는 무엇을 아는지를 묻는다. MMLU, GPQA, Humanity’s Last Exam 같은 benchmark는 넓은 지식과 reasoning을 보지만, software를 열고, 파일을 조작하고, 산출물을 만들고, reference와 비교하는 workflow 수행 능력을 직접 보지는 않는다.

둘째, 기존 agent benchmark는 interaction은 보지만 coverage가 좁은 경우가 많다. Web benchmark는 browser 중심이고, desktop benchmark는 GUI 조작 중심이며, coding benchmark는 repository와 CLI 중심이다. 실제 전문직 업무는 이 셋을 섞는다. 예를 들어 CAD task는 GUI 조작, geometry reasoning, file export, rendering-based evaluation이 동시에 필요할 수 있다.

셋째, real-world work benchmark는 human grading 비용을 피하기 어렵다. Agent output이 memo, slide, model, 3D mesh, simulation result처럼 다양하면 자동 채점이 어려워진다. 하지만 human grading에 의존하면 평가 비용이 올라가고, 반복 가능한 model comparison이 느려진다.

넷째, contamination 문제가 크다. task와 reference가 모두 공개되면 agent가 benchmark 자체에 맞춰질 수 있다. 특히 long-horizon workflow task는 한번 공개되면 prompt, input, expected output이 그대로 optimization target이 되기 쉽다.

따라서 ALE의 문제 설정은 “더 어려운 benchmark”가 아니라 “실제 업무를 반복 가능하고 오염을 관리할 수 있는 executable benchmark로 바꾸는 방법”에 가깝다.

2. Core Idea

2-1. Main contribution

ALE의 핵심 기여는 크게 네 가지다.

1. Industry-wide task taxonomy
   • 논문은 ALE를 13개 industry cluster와 55개 subfield로 구성한다.
   • 이 taxonomy는 SOC 2018과 O*NET을 참고해 computer-mediated professional work를 중심으로 구성된다.
   • 기존 benchmark를 같은 55-subdomain coordinate로 map해 coverage gap도 분석한다.
2. Expert-sourced workflow construction
   • task는 lay worker crowdsource가 아니라 domain expert가 제출한 실제 work에서 온다.
   • 제출된 workflow는 first-pass review, engineering implementation, dry run, final QC를 거친다.
   • 논문 결론 기준으로 960 expert-authored task workflows와 1,490 task instances가 보고된다.
3. Executable evaluation pipeline
   • 각 task instance는 executable task specification으로 구성된다.
   • main.py 안의 load(), start(), evaluate()가 task lifecycle을 담당한다.
   • agent는 output artifact를 만들고, evaluator는 hidden reference를 사용해 score를 계산한다.
4. Generalist Computer-Use Agent evaluation
   • ALE는 CLI-only나 GUI-only agent가 아니라 GCUA, Generalist Computer-Use Agent를 평가 대상으로 둔다.
   • GCUA는 reasoning, GUI perception, orchestration, tool invocation, runtime substrate를 모두 가진 agent다.
   • 이를 위해 GUI-as-Tool이나 GUI-as-SubAgent 방식으로 CLI-native harness를 desktop workflow에 연결한다.

이 중 가장 중요한 contribution은 dataset size보다 task contract다. ALE에서 task는 자연어 질문이 아니라 실행 가능한 software work package다. 그래서 agent evaluation은 “답을 맞혔는가”가 아니라 “실제 산출물을 만들었는가”가 된다.

2-2. Design intuition

ALE의 설계 직관은 다음처럼 볼 수 있다.

첫째, real professional workflow는 environment 없이 평가할 수 없다. 단순한 text prompt로는 CAD, ERP, finance workbook, browser, shell, report generation, media editing 같은 업무의 핵심 어려움이 사라진다. 따라서 benchmark는 prompt collection이 아니라 environment collection이어야 한다.

둘째, agent capability는 model 단독 성능이 아니라 harness와 environment interaction에서 나온다. 같은 foundation model도 Codex, Claude Code, Cursor, OpenClaw 같은 harness에 따라 tool loop, context management, sub-agent dispatch, file handling이 다르다. ALE는 model과 harness를 같이 평가하되, task/environment/evaluator interface를 분리해 비교 가능하게 만든다.

셋째, verification은 benchmark의 core feature다. 실제 업무 산출물은 매우 다양하지만, ALE는 가능한 경우 deterministic artifact check를 먼저 쓴다. 불가피하게 LLM judge가 필요한 경우에도 broad holistic grading이 아니라 evidence-anchored yes/no probe로 제한하려 한다.

넷째, benchmark는 살아 있어야 한다. 공개 task만으로 leaderboard를 유지하면 contamination이 생긴다. ALE는 public subset, private pool, rolling evaluation 구조를 통해 benchmark가 계속 새 workflow를 받을 수 있게 설계한다.

ALE는 agent benchmark paper이면서 동시에 benchmark operations paper다. 논문의 중요한 부분은 어떤 model이 몇 점을 받았는가보다, task를 수집하고, 구현하고, 검증하고, 공개/비공개로 나누어 유지하는 운영 구조에 있다.

3. Architecture / Method

3-1. Overview

Item	Description
Goal	AI agent가 실제 professional computer workflow를 수행할 수 있는지 평가
Benchmark unit	expert-authored task workflow와 runnable task instance
Taxonomy	13 industry clusters, 55 subfields
Environment	remote Windows or Linux VM with domain software
Task spec	main.py with load(), start(), evaluate()
Agent interface	task description과 metadata를 받고 VM에서 action loop 수행
Output	output directory의 deliverable artifact
Grading	hidden reference, deterministic checks, structured rubrics, narrow LLM probes
Agent target	Generalist Computer-Use Agent, GCUA
Release strategy	public subset + private pool + rolling evaluation

3-2. Module breakdown

1) Task taxonomy and coverage

ALE는 professional work를 55개 subfield로 나눈다. 이 taxonomy는 단순히 topic label이 아니라 benchmark coverage를 관리하기 위한 coordinate system이다. 논문은 기존 benchmark의 domain을 이 taxonomy에 map해 어떤 industry가 덜 평가되는지도 보여준다.

이 접근이 좋은 이유는 benchmark expansion을 임의의 task 추가가 아니라 coverage gap filling으로 바꾼다는 점이다. 예를 들어 agent가 web browsing에서 강하더라도 manufacturing, civil engineering, finance analytics, translation/localization, media production 쪽 coverage가 비어 있다면 실제 업무 능력을 과대평가할 수 있다.

2) Task construction pipeline

논문이 설명하는 task construction은 다섯 단계로 볼 수 있다.

Stage	Role
Expert sourcing	industry practitioner와 advisory committee를 통해 실제 workflow를 수집
Task submission	description, input files, target software, deliverable, evaluation spec를 제출
First-pass review	authenticity, complexity, executability를 기준으로 screening
Implementation	runnable assets, software container, evaluator logic로 변환
Final QC	reference correctness, scoring bound, sufficient context를 peer review

핵심은 task가 crowdsource puzzle이 아니라는 점이다. 전문가가 실제로 수행했던 project를 가져오고, 그것을 benchmark instance로 변환한다. 이 때문에 task 하나하나의 engineering cost가 크지만, 대신 benchmark가 실제 업무 surface를 더 잘 보존한다.

3) Task specification and VM contract

각 task instance는 main.py 같은 executable task specification으로 표현된다. 이 spec는 세 lifecycle function을 가진다.

1. load()
   • task description, compute requirement, input asset metadata를 선언한다.
2. start()
   • VM을 deterministic starting state로 만든다.
   • 필요한 input과 software를 준비한다.
3. evaluate()
   • agent가 만든 output을 hidden reference와 비교해 score를 계산한다.

VM은 대체로 다음 directory contract를 갖는다.

Directory	Agent visibility	Purpose
input/	read-only visible	task input asset
software/	visible	task-specific software launcher and tools
output/	writable	agent가 deliverable을 저장하는 위치
reference/	hidden during run	grading에만 쓰이는 ground truth

이 directory contract는 agent evaluation에서 매우 중요하다. Agent는 실제 업무처럼 input과 software를 사용하지만, reference는 볼 수 없다. Hidden reference는 agent가 끝난 뒤 staging되어 evaluate()에서만 사용된다.

4) Generalist CUA agent surface

ALE는 agent capability를 다섯 layer로 나눈다.

Layer	Meaning
Brain	LLM reasoning and planning
Eyes	GUI perception via screenshot or visual input
Body	orchestration and control flow
Hands	structured tool invocation
Feet	runtime substrate where actions happen

기존 CLI agent는 Brain, Body, Hands, Feet은 강하지만 Eyes가 부족하다. GUI agent는 Eyes는 있지만 file system, shell, code execution, long-running workflow orchestration이 약할 수 있다. ALE가 요구하는 GCUA는 이 둘을 합친다.

논문은 CLI-native harness를 GCUA로 올리기 위해 GUI capability를 tool로 노출한다. GUI-as-Tool은 screenshot, click, type, scroll 같은 desktop action을 일반 tool call처럼 main loop에 넣는다. GUI-as-SubAgent는 vision-language sub-agent에게 GUI interaction을 맡기는 방식이다.

이 설계는 agent engineer 관점에서 중요하다. 실제 업무 agent는 browser-only나 terminal-only로 끝나지 않는다. 화면을 보고, shell을 쓰고, 파일을 만들고, domain software를 조작하며, 중간 결과를 다시 읽는 loop가 필요하다.

5) Evaluation modes

ALE의 output은 heterogeneous하다. 어떤 task는 exact value를 만들고, 어떤 task는 spreadsheet, CAD model, rendered scene, report, database state를 만든다. 그래서 ALE는 단일 metric을 강제하지 않는다.

평가 방식은 대략 다음 범주로 나뉜다.

Artifact type	Example scoring
Exact or hashed output	exact match, checksum
Numeric or tabular output	schema validation, tolerance-based field comparison
Geometry or 3D output	surface distance, point-cloud comparison, rendered-view check
Behavioral state	fixed trajectory 아래 world state comparison
Visual output	narrow evidence-anchored VLM probe
Text report	structured rubric with constrained criteria

중요한 점은 LLM judge를 피할 수 있으면 피한다는 원칙이다. LLM judge가 필요한 경우에도 “전반적으로 좋아 보이는가” 같은 broad scoring이 아니라, checkable evidence에 묶인 yes/no probe로 score를 구성하려 한다.

4. Training / Data / Recipe

4-1. Data

이 논문은 model training paper가 아니라 benchmark construction and evaluation paper다. 따라서 여기서의 Data는 학습 데이터보다 benchmark data와 task artifact에 가깝다.

논문과 공개 artifact 기준으로 중요한 숫자는 다음과 같다.

Item	Reported value	Note
Industry clusters	13	paper abstract
Subfields	55	paper abstract
Task workflows	960	paper conclusion
Task instances	1,490	paper figure/conclusion
Public tasks	around 150	paper release strategy
Hugging Face rows	153	dataset viewer 기준
Target corpus	5,000 tasks	project page target

여기서 숫자는 source별 표현이 조금 다르다. Paper abstract는 250+ industry experts를 말하고, project page와 GitHub README는 300+ experts라고 설명한다. 또한 paper는 150 public task를 말하는 반면, Hugging Face dataset viewer는 153 rows를 보여준다. 블로그 초안에서는 이 차이를 숫자 검증 포인트로 남기는 것이 안전하다.

4-2. Evaluation recipe

ALE run은 다음 흐름으로 이해하면 된다.

1. Task list를 선택한다.
   • Near-Term
   • Full-Spectrum
   • Last-Exam
   • ALE-CLI 같은 Linux-only subset
2. Agent harness와 foundation model을 정한다.
   • Codex, Claude Code, Cursor, Droid, Gemini CLI, Grok CLI, ALE-Claw 등
   • OpenClaw + GUI-as-Tool로 model sweep도 수행한다.
3. Sandbox를 provision한다.
   • Windows 또는 Linux VM을 준비한다.
   • task input, software, output directory를 stage한다.
4. Agent를 끝까지 실행한다.
   • agent는 task description과 metadata만 보고 action loop를 돈다.
   • screenshots, shell output, mouse/keyboard, file edit, API call 등을 사용할 수 있다.
5. Hidden reference를 stage하고 evaluate()를 실행한다.
   • agent가 끝난 뒤 reference가 들어온다.
   • evaluator가 output artifact를 score한다.
   • trajectory, raw log, artifacts도 audit 가능하게 저장한다.

이 recipe는 benchmark를 단순 leaderboard가 아니라 reproducible experiment framework로 만든다. Agent가 어떤 tool을 언제 썼는지, 어떤 artifact를 남겼는지, 어떤 scoring component에서 실패했는지까지 분석할 수 있다.

4-3. Engineering notes

실무적으로 참고할 만한 engineering point는 다음과 같다.

1. Agent, task, environment를 decouple한다.
   • 같은 task를 다른 agent harness에 붙일 수 있다.
   • 같은 agent를 다른 VM provider나 task set에 붙일 수 있다.
2. Output directory를 명확히 제한한다.
   • agent가 어디에 deliverable을 남겨야 하는지 명확하다.
   • evaluator도 output directory만 기준으로 scoring할 수 있다.
3. Reference는 run 이후에만 stage한다.
   • leakage를 줄이는 데 중요하다.
   • agent가 hidden answer를 accidentally read하는 경로를 줄인다.
4. Full trajectory를 남긴다.
   • 실패 분석, timeout 분석, tool usage 분석이 가능하다.
   • benchmark가 model leaderboard를 넘어 agent system diagnosis 도구가 된다.
5. GUI bridge를 tool system에 통합한다.
   • GUI task를 별도 vision agent로만 보지 않고, CLI-native harness의 tool loop 안에 넣는다.
   • 실제 computer-use agent의 operating surface와 더 가까워진다.

5. Evaluation

5-1. Main results

ALE의 결과는 현재 frontier agent가 이 benchmark를 쉽게 풀지 못한다는 쪽에 가깝다. 특히 Last-Exam tier는 아직 거의 unsolved에 가깝다.

논문 table에서 눈에 띄는 결과를 정리하면 다음과 같다.

Setting	Near-Term pass	Full-Spectrum pass	Last-Exam pass	Overall pass
Codex with GPT-5.5	38.1	22.7	0.0	24.0
ALE-Claw with GPT-5.5	32.8	23.6	2.6	23.0
Claude Code with Fable 5	34.3	20.9	0.0	22.0
Cursor with GPT-5.5	32.1	20.0	2.6	20.7
Gemini CLI with Gemini 3.1 Pro	26.9	12.7	0.0	15.8
Grok CLI with Grok 4.3	9.0	7.3	0.0	6.6

이 표를 읽을 때 중요한 점은 absolute leaderboard보다 difficulty gradient다. Near-Term에서는 frontier agent가 일부 task를 성공하지만, Full-Spectrum에서는 pass rate가 크게 떨어지고, Last-Exam에서는 대부분 0.0%다. 논문 abstract도 hardest tier의 average full pass rate가 below 1%라고 요약한다.

ALE-CLI도 흥미롭다. 논문은 Codex with GPT-5.5가 Terminal-Bench에서 82%를 기록한 configuration이라고 설명하지만, ALE-CLI에서는 overall pass rate가 23.3%이고 Last-Exam tier는 0.0%라고 보고한다. 즉 CLI task라도 ALE의 workflow complexity와 session length가 기존 terminal benchmark보다 훨씬 강한 압력을 준다.

5-2. What really matters in the experiments

1) Full pass rate와 mean score를 같이 봐야 한다

ALE는 full pass rate와 mean fine-grained score를 함께 보고한다. Full pass는 task를 끝까지 완성했는지에 가깝고, mean score는 partial progress를 반영한다. Professional workflow에서는 이 둘이 모두 중요하다.

• Full pass가 낮다: 실제 업무를 맡기기에는 아직 위험하다.
• Mean score가 높다: agent가 일부 subtasks는 수행하지만 final integration에서 실패할 수 있다.

이 차이를 봐야 agent가 어디까지 왔는지 더 정확히 알 수 있다. 예를 들어 Last-Exam tier에서 pass rate가 0.0%여도 score가 10점 내외라면 완전 무작위는 아니지만, deliverable-level success에는 아직 멀다는 뜻이다.

2) Model보다 harness도 중요하지만, model effect가 더 크다

논문 appendix 분석은 foundation model choice가 well-engineered harness 간 spread보다 더 큰 성능 변동을 설명한다고 말한다. HTML rendering에서는 정확한 수식/배율 표기가 깨져 보이므로 PDF 확인이 필요하지만, 해석 방향은 분명하다.

좋은 harness가 중요하지 않다는 뜻은 아니다. 오히려 ALE는 harness를 제대로 비교하기 위해 GUI bridge, output contract, VM abstraction을 만든다. 다만 같은 harness 위에서도 model capability 차이가 크게 나타난다는 점을 보여준다.

3) GUI under-utilization이 중요한 failure signal이다

공개 task 중 상당수는 graphical software를 primary tool로 지정하지만, agent는 종종 GUI를 충분히 쓰지 않고 Bash나 script-based workaround로 우회한다. 이것은 두 가지 가능성을 보여준다.

• agent가 GUI를 안정적으로 조작하지 못한다.
• domain software를 쓰는 대신 일반 scripting으로 대체하려 한다.

이 behavior가 항상 나쁜 것은 아니다. 하지만 CAD, design, domain simulation처럼 GUI software 자체가 전문 workflow의 핵심이면, CLI workaround는 task intent를 놓칠 수 있다.

4) 실패 원인은 execution보다 understanding and approach가 많다

논문은 Claude Code + Opus 4.7 실패 사례를 taxonomy로 분류하고, Understanding과 Approach failure가 대략 3/4를 차지한다고 설명한다. 이 결과는 흥미롭다. Agent가 단순히 mouse click을 못하거나 command를 틀려서 실패하는 것이 아니라, 무엇을 해야 하는지, 어떤 domain workflow를 따라야 하는지를 잘못 잡는 경우가 많다는 뜻이다.

이 지점이 ALE의 가치다. 실제 업무 agent의 병목은 tool API 호출 능력만이 아니다. Domain workflow를 이해하고, 적절한 software path를 선택하고, output contract를 끝까지 만족시키는 능력이 필요하다.

5) 비용, 시간, token이 성능으로 바로 이어지지는 않는다

ALE run은 비싸고 길다. 논문은 single run이 평균 몇 달러에서 10달러 수준이고, tens of minutes to hours가 걸릴 수 있다고 설명한다. 또한 5 hour wall-clock cap과 timeout analysis도 제공한다.

하지만 더 많은 token, 더 긴 runtime, 더 큰 비용이 항상 더 좋은 score로 이어지는 것은 아니다. Agent가 잘못된 approach를 잡으면 오래 실행해도 output quality가 개선되지 않는다. 이 부분은 production agent 운영에서도 중요하다. Long-horizon agent의 성능 개선은 더 긴 budget이 아니라 better planning, better tool selection, better verification loop에서 나올 수 있다.

6. Limitations

1. Benchmark construction cost가 매우 크다
   • 실제 expert workflow를 수집하고 runnable task로 바꾸는 데 많은 engineering이 필요하다.
   • ALE가 broad coverage를 목표로 할수록 task maintenance와 software licensing 문제도 커질 수 있다.
2. Public/private split은 contamination을 줄이지만 reproducibility tradeoff가 있다
   • public subset은 연구자가 재현하기 좋다.
   • private pool은 leaderboard validity를 지키지만, external researcher가 모든 결과를 완전히 독립 검증하기는 어렵다.
3. 평가가 software environment에 강하게 의존한다
   • VM image, licensed software, OS version, tool launcher, domain package가 바뀌면 task behavior도 달라질 수 있다.
   • Long-term benchmark로 유지하려면 environment pinning과 migration strategy가 중요하다.
4. Structured rubric과 narrow LLM probe도 완전한 objectivity는 아니다
   • deterministic check가 가능한 task는 강하지만, visual quality나 free-text report는 여전히 rubric 설계에 영향을 받는다.
   • LLM judge를 좁게 제한해도, judge model change와 prompt sensitivity 문제는 남는다.
5. Human professional work를 모두 computer-use task로 환원할 수는 없다
   • ALE는 non-physical, software-mediated workflow에 집중한다.
   • 현장 작업, interpersonal negotiation, organizational coordination, tacit knowledge가 큰 일은 여전히 benchmark 바깥에 남을 수 있다.
6. Current results에 미래 model 이름이 포함되어 있어 version 확인이 필요하다
   • 논문 v2는 GPT-5.5, Fable 5, Opus 4.8 같은 2026-era frontier system 이름을 포함한다.
   • 블로그 발행 시점에 model version, public availability, API behavior가 달라졌는지 확인할 필요가 있다.
7. Pass rate가 낮을수록 benchmark가 좋은가에 대한 해석은 조심해야 한다
   • Hard benchmark는 headroom을 주지만, 너무 어려우면 iterative engineering signal이 약해질 수 있다.
   • ALE는 Near-Term, Full-Spectrum, Last-Exam tier를 나눠 이 문제를 완화하지만, 어떤 tier를 어떤 연구 목적에 쓸지는 명확히 정해야 한다.

7. My Take

7-1. Why this matters for my work

이 논문은 agent evaluation을 다시 생각하게 만든다. 최근 agent 연구는 tool use, browser, code, memory, planning을 각각 따로 개선해 왔다. 하지만 실제 업무에서는 이 구성요소가 하나의 workflow 안에서 섞인다. 모델이 문서를 읽고, shell을 쓰고, GUI software를 열고, 파일을 만들고, 다시 검증하는 과정을 끝까지 완성해야 한다.

ALE의 중요한 메시지는 “agent를 평가하려면 실제 업무의 artifact contract를 평가해야 한다”는 점이다. 단순 QA 정확도나 partial trajectory quality만으로는 production readiness를 말하기 어렵다. 결국 사용자는 agent가 남긴 deliverable을 받는다.

특히 세 가지가 중요하다.

1. Output contract를 먼저 설계해야 한다
   • agent benchmark를 만들 때 prompt보다 output schema와 evaluator가 먼저다.
   • output directory, required filename, validation script, hidden reference를 명확히 해야 한다.
2. Tool surface coverage가 model capacity만큼 중요하다
   • agent가 문제를 이해해도 GUI를 조작하지 못하면 실패한다.
   • 반대로 GUI 조작이 되어도 domain workflow를 모르거나 output format을 놓치면 실패한다.
3. Failure analysis를 task-level로 남겨야 한다
   • pass/fail만 보면 agent가 무엇을 배워야 하는지 알기 어렵다.
   • trajectory, artifact, evaluator component score가 있어야 개선이 가능하다.

7-2. Reuse potential

ALE에서 바로 재사용해볼 만한 설계는 다음과 같다.

1. Internal agent evaluation suite
   • 회사 내부 workflow를 ALE-style task package로 바꿀 수 있다.
   • input, software, output, reference, evaluator를 묶으면 model 교체나 harness 교체 효과를 비교하기 쉬워진다.
2. Public/private task split
   • public task는 development와 debugging에 쓰고, private task는 final regression test에 쓴다.
   • benchmark overfitting을 줄이는 데 유용하다.
3. GUI-as-Tool bridge
   • CLI-native agent가 실제 desktop workflow를 수행하도록 만들 때 참고할 수 있다.
   • screenshot, click, type, scroll 같은 action을 tool system에 넣는 구조는 production agent에도 재사용 가능하다.
4. Deliverable-based scoring
   • agent 답변 텍스트가 아니라 output artifact를 평가한다.
   • document AI, report generation, spreadsheet automation, slide editing, code migration task에 특히 잘 맞는다.
5. Tiered difficulty design
   • Near-Term은 빠른 iteration용, Full-Spectrum은 broad coverage용, Last-Exam은 frontier milestone용으로 나눌 수 있다.
   • 하나의 평균 점수보다 목적별 tier가 더 실용적이다.

7-3. Follow-up papers

• Humanity’s Last Exam
• GDPval
• OSWorld
• WebArena
• SWE-bench
• Terminal-Bench
• GAIA
• OccuBench
• ResearchClawBench

8. Summary

• ALE는 AI agent를 실제 professional workflow 수행 능력으로 평가하려는 broad-coverage benchmark다.
• 핵심은 13개 industry cluster, 55개 subfield, expert-sourced workflow, VM-based execution, hidden reference grading이다.
• Agent target은 CLI-only나 GUI-only가 아니라 Brain, Eyes, Body, Hands, Feet을 모두 갖춘 Generalist Computer-Use Agent다.
• 현재 frontier agents도 Last-Exam tier에서는 대부분 0.0% pass에 가까워, benchmark는 아직 넓은 headroom을 가진다.
• 이 논문의 실무적 가치는 leaderboard 숫자보다 task contract, evaluator design, public/private split, trajectory audit 구조에 있다.