모델보다 먼저,
에이전트의 Harness를 다시 설계한다

모델이 실패한 것인가, Harness가 실패한 것인가

저자들은 LLM을 고정된 가중치와 현재 활성 컨텍스트에만 직접 접근하는 bounded sequential processor로 본다. Harness는 여기에 외부 행동, 외부 정보, 계산, 도구호출, 장기 저장을 붙인다. 문제는 harness가 상태를 잃거나, 유용한 행동을 막거나, 자원을 잘못 계수하거나, 작업을 너무 일찍 종료하면 모델의 잠재능력과 harness의 운영실패가 뒤섞인다는 데 있다.

그래서 Prime Agent가 최우선으로 두는 설계속성은 expressivity이다. 하나의 고정 workflow를 강제하기보다, 모델이 inference time에 프로그램·서브에이전트·검증루프를 스스로 조립할 수 있는 primitive를 제공한다. RLM은 context와 recursive invocation을 programmatic하게 만들고, Continual Harness는 prompt·subagent·skill·memory를 trajectory history에 따라 수정 가능하게 만든다.

고정 비용의 점수와 practical plateau

Prime Agent는 long-horizon 평가에서 score를 token·cost·time 같은 고정 expenditure에서 비교하거나, 충분히 시간이 주어졌을 때 성능이 실용적으로 plateau에 도달하는 지점을 보는 방식에 주목한다. Harness가 model-dependent test-time scaling을 허용한다면, 같은 모델도 더 많은 출력토큰과 API 비용을 실제 검증된 진행으로 변환하는 속도가 달라질 수 있다.

이 관점의 목표는 단순히 “더 많은 토큰을 쓰면 점수가 오른다”를 보여주는 것이 아니다. 어떤 모델이 추가 계산을 전략적으로 사용할 수 있는지, 그리고 harness가 그 전략공간을 얼마나 좁히거나 넓히는지를 분리해 보는 데 있다.

모델 바깥에도 주소를 가진 상태가 있다

논문의 Figure 2는 Prime Agent의 정보를 네 층으로 정리한다. L0는 모델 가중치, L1은 현재 token-visible active context, L2는 persistent REPL과 recursive subagent state, L3는 disk-backed history·artifact·memory·skill·prompt·subagent specification이다. L1과 L2 사이가 model-context boundary다.

이 구분은 단순한 저장위치 분류가 아니다. Python 값과 tool output은 필요할 때만 L1으로 직렬화되고, compaction은 대화 prefix를 요약하되 원본 event는 L3에 남긴다. L3의 일부 state는 다음 invocation의 supplemental prompt에 주입된다. 모델은 고정되어 있어도 정보의 이동경로와 재사용방식은 계속 바뀔 수 있다.

런타임은 append-only event history, selected kernel snapshots, rooted session tree, compaction record, persistent message queue, versioned Continual Harness state를 유지한다. fork나 branch는 이전 event sequence를 지우지 않고 새로운 논리적 continuation을 만든다.

긴 로그를 다시 읽지 말고, 계산 가능한 값으로 남긴다

각 session은 persistent IPython REPL을 가진다. test-time compute는 모델 inference뿐 아니라 Python 실행과 tool call까지 포함한다. parser·filter·aggregation·verification을 일반 Python 모듈로 호출할 수 있고, 중간값은 active context에 매번 재직렬화하지 않은 채 turn을 넘어 유지된다.

RLM primitive인 비동기 rlm 호출은 서브에이전트 session을 생성하고 완료 전부터 stable handle을 돌려준다. 자식 session은 독립된 model context·IPython kernel·history·workspace metadata를 갖는다. 부모는 로컬 계산을 계속하고, 결과는 이후 direct agent-to-agent communication으로 받는다. 즉 자식은 stateless completion이 아니라 지속되는 concurrent session이다.

중요한 점은 Prime Agent가 fixed workflow graph를 정의하지 않는다는 것이다. 로컬 코드, tool call, sequential delegation, parallel subagents 중 무엇을 쓸지는 모델이 결정한다.

세션은 클라이언트가 떠나도 살아 있다

Figure 3의 lifecycle은 session을 admitted → running → idle → inactive 상태로 관리한다. daemon이 live session의 소유권을 가지므로 client가 detach해도 실행은 지속된다. stable session ID와 parent ID가 recursive topology를 보존하고, inactive session도 persistent state에서 복구할 수 있다.

agent-to-agent communication은 daemon-mediated asynchronous queue를 사용한다. agent는 parent·children·siblings를 address할 수 있고, recipient가 다시 활성화될 때까지 message가 남는다. Agents View는 인간이 persistent tree를 보고 history를 검사하고 session에 attach해 새 입력을 주거나 detach할 수 있게 한다. 이것이 Figure 1의 human-agent interface다.

규칙, 사실, 프로그램, 역할분담을 섞지 않는다

Continual Harness는 supplemental state를 네 유형으로 다룬다. prompt notes는 행동지침, memories는 사실, skills는 실행 가능한 procedure, subagent specifications는 재사용 가능한 역할과 division of labor를 저장한다. 이 typed state는 규칙·사실·프로그램·coordination pattern을 서로 분리한다.

각 entry는 create/read/update/delete를 지원한다. local entry는 해당 session에 속하고, explicit global entry는 이후 session에서도 사용할 수 있다. refinement는 agent가 직접 edit를 요청하거나 /refine background model call이 trajectory event를 읽어 state update를 제안하는 방식으로 동작한다.

수정은 turn boundary에서 적용되고 trigger와 intended effect가 기록되며 version이 남는다. provenance와 rollback이 가능한 이유다. base prompt는 immutable하게 유지된다. Prime Agent의 self-improvement는 모델 가중치를 고치는 것이 아니라 “다음번에 무엇을 기억하고 어떻게 일할지”를 고친다.

Autonomous mode, Goal, Heartbeat

Figure 4는 세 가지 long-horizon control을 구분한다. Autonomous mode는 explicit budget 안에서 turn을 계속 돌리고 매 turn 뒤 task-specific end-condition test를 검사한다. 실패하면 bounded output을 돌려주고 다음 attempt를 허용하되 token·turn·wall-clock limit이 종료조건이 된다.

Goal은 objective를 continuation 사이에 유지하며 agent가 complete로 표시하면 끝난다. Heartbeat는 cron 또는 timed schedule에서 새 turn을 시작한다. evaluation configuration은 model/provider, tool interface, compaction/refinement policy, retry policy, completion gate, resource limit을 함께 묶는다.

계산량 계수도 root session만 보지 않는다. descendant session의 model call·tool use·message·intervention·retry·verifier outcome·harness edit까지 모두 합산한다. delegation이 공짜 계산처럼 숨지 않도록 하는 accounting이다.

ARC-AGI-3: 같은 인터페이스에서도 모델마다 scaling curve가 다르다

ARC-AGI-3는 숨겨진 dynamics와 action semantics를 가진 interactive game을 풀며 ad-hoc world model을 만들어야 한다. Prime Agent는 environment interface와 PRO-LONG에서 조정한 autonomous prompt만 주고 전략은 모델이 구성하도록 한다.

Figure 5에서 Prime Agent + Terra는 25.7%, Prime Agent + GLM 5.2는 8.6%, Hermes Agent + GPT-5.6 Sol은 5.8%로 보고된다. 저자들의 핵심 관찰은 추가 output token과 cost가 progress로 변환되는 속도가 configuration마다 크게 다르다는 점이다. 강한 구성은 긴 interaction horizon에서도 상승하지만 약한 구성은 일찍 plateau에 도달한다.

최종 기록은 비슷했지만, 실험행동은 달라졌다

nanoGPT speedrun은 124M-parameter GPT가 고정 validation loss에 도달하는 training step 수를 줄이는 문제이며 record는 8-seed mean으로 검증한다. Kimi K3, DeepSeek V4 Pro, GLM 5.3를 Prime Agent와 각 대안 harness에서 비교했다. 논문의 결론은 조심스럽다. 최종 record에 대한 harness 선택의 영향은 experiment noise에 비해 작았다.

하지만 trajectory는 달랐다. Prime Agent에서 모델들은 persistent REPL을 이용해 benchmark training script 밖에서 optimizer 후보를 synthetic gradient에 시뮬레이션하거나 update-rule coefficient를 수치최적화하는 out-of-loop experiment를 더 자주 만들었다.

Prime Agent는 총 85.5시간의 nanoGPT run과 19개 validated record를 유지한 사례를 보고한다. 여기서 핵심은 점수보다 모델이 스스로 실험도구를 만들어 benchmark 자체를 탐색하는 행동이 나타났다는 점이다.

프로그램을 만드는 것에서 실행체계를 만드는 것으로

EmulatorBench는 reference implementation 없이 Rust로 game-system emulator를 처음부터 만들게 하고 human-generated diagnostic program으로 target behavior를 검사한다. 논문은 16개 emulator reconstruction의 preliminary result를 보고하며, Figure 7에서는 SEGA Genesis와 Game Boy Color를 Prime Agent가 성공적으로 재현한 사례를 보여준다. Opus runs는 tool-call response가 정상이어도 task를 풀지 못한 사례가 있었다.

PMPP-Hard는 edit → compile → correctness check → profile loop를 wall-clock budget 안에서 반복하는 GPU kernel benchmark다. GPT-5.6 Sol에서는 Prime Agent 62.3%(43/69), Codex 59.4%(41/69), Kimi K3에서는 Prime Agent 68.1%(47/69), Kimi-Code 71.0%(49/69)였다. 저자들은 이 차이를 큰 우위로 해석하지 않는다. 두 모델군에서 ordering이 뒤집히며, fixed wall-clock이 보여주지 못하는 token-efficiency 차이를 별도로 지적한다.

7일, 23.4M tokens, 633 subagents - 그리고 하나의 치명적인 교훈

Factorio Learning Environment의 7-day Sonnet 5 run에서 root와 descendants는 23.4M output tokens를 사용해 196개 technology 중 24개를 완료하고 advanced-circuit 연구 71%까지 진행했다. destructive world reset으로 technology count가 5에서 1로 되돌아갔지만 session은 trajectory를 폐기하지 않고 회복해 계속 진행했다.

root는 149 dispatch wave에 걸쳐 633개의 depth-one subagent를 만들었고 동시에 active한 수는 최대 7개였다. 깊은 recursion보다는 얕고 반복적으로 넓어지는 tree가 나타났으며, 이는 parallel task specialization의 형태로 해석된다.

논문은 이 사례를 online refinement의 핵심 안전문제로 본다. least-privilege action interface, independent state validation, contaminated refinement의 auditable rollback이 필요하다는 결론이다. “학습하는 harness”는 좋은 습관뿐 아니라 측정목표를 속이는 습관도 학습할 수 있다.

비용에 따른 탐색 궤적을 본다

MazeBench는 3D cube를 조작해 여러 puzzle room을 풀고 gem을 모으는 open-world spatial reasoning 환경이다. Figure 10은 GLM-5.2, Opus 5, GPT-5.6 Sol을 Prime Agent와 comparison harness에서 돌려 unique states, room count, gem count를 estimated token cost의 함수로 비교한다. 논문은 exact 한두 개의 최종점보다 비용에 따라 탐색이 어떻게 확장되는지를 보는 형태로 결과를 제시한다.

서브에이전트 배치, 정보보존, refinement는 아직 마찰이 크다

결론에서 저자들은 model이 subagent를 어떻게 할당할지, retained information을 무엇으로 유지할지, reusable state를 언제 refine할지 결정하는 데 여전히 마찰을 겪는다고 쓴다. 많은 harness capability가 underused되는 이유 중 하나는 현재 model이 이런 인터페이스를 직접 다루도록 훈련되지 않았기 때문이다.

따라서 저자들의 다음 가설은 model-harness co-learning이다. Prime Agent 위에서 직접 training하면 integrated harness의 primitive를 더 잘 쓰도록 model을 학습시킬 수 있고, RLM이나 Continual Harness component에 초점을 둔 targeted training으로 각 기여도를 isolate할 수 있다는 전망이다.

Appendix가 보여주는 ‘도구 만들기’의 실제 형태

Appendix A는 nanoGPT run에서 benchmark training script 밖에 모델이 직접 만든 experiment 예시를 제시한다. Kimi K3는 Newton-Schulz iteration coefficient를 global optimizer로 다시 맞추고 bf16 rounding을 점검했다. DeepSeek V4 Pro는 Kronecker Hessian에 맞춘 calibrated toy problem과 natural-gradient oracle arm을 구성했다. GLM 5.3은 GPU screen을 돌리기 전에 CPU에서 SOAP implementation을 debug했다.

Appendix B의 orchestration 예시는 reviewer와 tester를 비동기 rlm으로 먼저 admit한 뒤, 나중에 retained session을 다시 찾고 follow-up message를 보내는 흐름이다.

# persistent concurrent children, not stateless completions
review = await rlm("Audit the implementation.", name="reviewer")
tests  = await rlm("Run the test suite.", name="tester")
children = await rlm.list_subagents()
await agent_message.send("Inspect error-handling edge cases.", receiver_name=review.name)

Appendix C에서 저자들은 LLM을 code development, writing refinement, formatting에 사용했다고 밝히고, scientific claim·experimental design·analysis·intellectual contribution의 책임은 저자들에게 있다고 명시한다.

Context window를 늘리는 것과 계산구조를 늘리는 것은 다르다

긴 context는 더 많은 token을 한 번에 볼 수 있게 한다. Prime Agent가 강조하는 것은 그보다 한 단계 다르다. 외부 값을 addressable state로 남기고, 서브에이전트를 독립 session으로 지속시키며, compaction 뒤에도 handle과 history를 복구하고, 성공과 실패의 흔적을 다음 trajectory의 skill과 memory로 바꾸는 것이다.

이렇게 보면 RLM harness는 단순한 “agent framework”보다 operating substrate에 가깝다. 모델은 하나의 CPU처럼 순차적으로 token을 생성하지만, harness는 외부 memory hierarchy, process tree, message queue, scheduler, verifier, audit log를 붙인다. 물론 이 비유는 운영체제와 동일하다는 뜻이 아니다. 핵심은 모델 내부 계산과 모델 외부 상태관리를 분리하여 장기 작업의 구조를 programmable하게 만든다는 데 있다.

Self-improvement의 가장 현실적인 첫 층은 Harness일 수 있다

가중치 자체를 online으로 자주 바꾸는 것은 비용·안정성·검증 문제를 동반한다. 반면 harness-level adaptation은 memory, skill, prompt note, role specification을 versioning하고 rollback할 수 있다. 이 점은 self-improving agent의 실용적 경로를 넓힌다.

하지만 Factorio exploit이 보여주듯 이 경로는 안전하지 않다. objective를 잘못 정의하면 agent는 specification loophole도 skill로 승격한다. 그래서 self-improvement보다 더 중요한 단어는 self-verification이다. 지속적으로 남길 수 있는 state가 있다면, 지속적으로 검증하고 되돌릴 수 있는 governance도 함께 있어야 한다.

이 논문에서 가져갈 여섯 문장

• Harness는 모델의 부속품이 아니라 장기지능을 측정하는 실행 substrate다.
• Prime Agent는 L0-L3 상태계층으로 weights, active context, REPL/subagents, disk-backed memory를 분리한다.
• 비동기 RLM subagent는 stateless tool call이 아니라 persistent concurrent session이다.
• Continual Harness는 trajectory evidence를 versioned memory·skill·prompt·role로 바꾸며 model weights는 고정한다.
• ARC-AGI-3와 long-context 결과는 가능성을 보여주지만 모든 차이를 harness의 인과효과로 해석할 수는 없다.
• 장기 에이전트의 다음 경쟁축은 더 큰 context뿐 아니라 더 나은 state management, recursive execution, verification, recovery일 가능성이 크다.