핫한 prime-agent 훝어보기

(GitHub)

핵심을 한 문장으로

일반적인 코딩 에이전트가

LLM → tool call → 결과 → LLM → tool call

방식이라면 Prime Agent는 오히려

LLM → 지속되는 Python 런타임 → 코드로 도구/데이터/서브에이전트 제어 → 결과 축적 → 다음 행동

이라는 구조를 중심으로 설계했습니다. 모델에 기본적으로 노출되는 핵심 실행 환경도 persistent IPython kernel이며, 파일 읽기·수정, shell 실행, skill 호출, subagent 생성까지 Python에서 프로그래밍하듯 조합하게 합니다. (GitHub)

아키텍처를 단순화하면

                  ┌─────────────────────┐
                  │      User / TUI     │
                  └──────────┬──────────┘
                             │
                     Prime Agent Daemon
                             │
              ┌──────────────▼─────────────┐
              │       Root Agent           │
              │                            │
              │ Persistent IPython Kernel  │
              │ variables / functions      │
              │ files / shell / skills     │
              └──────┬─────────┬───────────┘
                     │         │
                rlm(...)       │ skills
                     │         │
             ┌───────▼───┐ ┌──▼──────────┐
             │ Subagent A│ │ Python Skill│
             └───────────┘ └─────────────┘
                     │
               ┌─────▼─────┐
               │Subagent A-1│
               └────────────┘

         ↓ persistent state ↓

 JSONL history
 Python state
 goals
 schedules
 heartbeat
 memories
 skills
 subagent definitions

실제 구현에서도 TUI와 실행 프로세스를 분리하고, daemon supervisor가 세션·worker·routing·복구를 관리하며, 각 worker가 root agent와 scheduler, IPython kernel, RLM children을 보유합니다. 그래서 터미널 UI를 닫아도 worker가 살아 있으면 작업이 계속될 수 있습니다. (GitHub)

1. RLM이 가장 중요한 부분

여기서 RLM은 단순히 “에이전트를 여러 개 띄운다”는 의미가 아닙니다.

Prime Agent에서 rlm(...)은 Python 함수처럼 취급됩니다.

api = await rlm(
    "API 코드를 분석하고 보안 문제를 찾아라",
    name="api-reviewer"
)

tests = await rlm(
    "테스트 커버리지를 분석해라",
    name="test-reviewer"
)

각 호출은 단순 LLM API 호출이 아니라 독립적인 Prime Agent 세션을 하나 생성합니다. child에게도 자체 context, session directory, 모델, 필요 시 IPython kernel이 있으며 결과는 단순 함수 return으로 돌려주는 게 아니라 agent-to-agent messaging을 통해 전달할 수 있습니다. (Prime Intellect)

더 중요한 것은 child가 일회용이 아니라는 점입니다.

children = await rlm.list_subagents()

로 기존 child를 다시 찾은 뒤,

await agent_message.send(
    "방금 수정한 코드까지 다시 검사해",
    receiver_role="child",
    receiver_name="api-reviewer"
)

처럼 이전에 일했던 에이전트에게 추가 작업을 줄 수 있습니다. child registry는 compaction이나 kernel restart, parent restoration 이후에도 복구하도록 설계돼 있습니다. (GitHub)

이 부분은 꽤 중요합니다.

기존 패턴이

manager
 ├─ agent A → 종료
 ├─ agent B → 종료
 └─ agent C → 종료

라면 Prime Agent가 지향하는 것은

manager
 ├─ frontend specialist ──────┐
 ├─ backend specialist ───────┤ 장기간 유지
 ├─ test specialist ──────────┤
 └─ security specialist ──────┘
             ↑
       필요할 때 재호출

에 더 가깝습니다.

---

2. Persistent Python이 상당히 좋은 아이디어

일반 tool-calling에서는 이런 데이터를 매번 모델 context에 다시 넣는 경우가 많습니다.

50개 파일 검색
→ 결과 30KB
→ LLM에게 전달
→ 다시 grep
→ 또 LLM에게 전달

Prime Agent에서는 Python에 그대로 남겨둘 수 있습니다.

files = ...
results = ...
failed_tests = ...
dependency_graph = ...

그리고 다음 turn에서도 해당 변수와 함수들을 사용할 수 있습니다.

문서상 Python state는 tool call과 context compaction을 넘어 유지됩니다. 즉 LLM의 context window를 작업 메모리 전체로 사용하지 않고, 상당 부분을 외부 Python environment에 밀어놓는 것입니다. (GitHub)

이게 RLM의 핵심 철학입니다.

LLM context
=
모든 정보를 집어넣는 창고

가 아니라

LLM context
=
현재 판단에 필요한 정보

Python environment
=
거대한 외부 작업 메모리

로 역할을 분리합니다.

장시간 코딩 작업에서는 상당히 합리적인 설계입니다.

---

3. “Self-improving”의 정확한 의미

여기가 가장 오해하기 쉽습니다.

Prime Agent가 작업하면서 GPT나 Claude의 neural weights를 재학습시키는 것은 아닙니다.

대신 Continual Harness라는 별도의 상태를 변경합니다.

공식 설명에서는 이를

H = (ρ, G, K, M)

ρ = prompts
G = subagents
K = skills
M = memory

형태로 정의하고 있습니다. 이 상태에 대해 create/read/update/delete가 가능합니다. (Prime Intellect)

예를 들어 에이전트가 여러 번 작업해보니

우리 프로젝트에서는 migration 수정 후
반드시 pnpm prisma generate를 실행해야 한다.

라는 패턴을 발견했다고 합시다.

처음에는 그냥 대화 중 발견한 사실입니다.

그러다가 /refine이 trajectory를 분석해 이것을

Memory
또는
Prompt Note
또는
Skill

로 승격시킬 수 있습니다.

그리고 반복 작업이라면:

migration-check/
 ├── SKILL.md
 ├── pyproject.toml
 └── src/
     └── migration_check/
         └── __init__.py

같은 Python-backed skill까지 만들 수 있습니다. Prime Agent는 instruction-only SKILL.md뿐 아니라 실제 Python package를 persistent IPython에 설치하는 형태도 공식 지원합니다. (GitHub)

그래서 정확하게 표현하면

모델이 개선되는 것이 아니라 에이전트의 작업 환경과 operating procedure가 경험을 통해 개선됩니다.

라고 보는 게 맞습니다.

저는 오히려 이 방식이 실용적으로 중요하다고 봅니다. 모델 fine-tuning 없이도 실제 프로젝트에서 반복적으로 발생하는 노하우를 축적할 수 있기 때문입니다.

---

4. Continual Harness가 재미있는 이유

일반적인 AGENTS.md, CLAUDE.md, SKILL.md 방식은 사람이 관리합니다.

사람
↓
실수 발견
↓
AGENTS.md 수정
↓
다음 작업부터 개선

Prime Agent는 이 루프의 일부를 agent에게 넘기려 합니다.

Agent 작업

       ↓

성공 / 실패 trajectory

       ↓

/refine

       ↓

┌──────────────┐
│ Prompt Note  │
│ Memory       │
│ Skill        │
│ Subagent Spec│
└──────────────┘

       ↓

다음 작업

       ↓

더 나은 Harness

/refine은 현재 trajectory를 보고 가능한 한 작은 CRUD 변경을 적용하도록 설계되어 있으며, base system prompt 자체는 수정하지 않습니다. refinement history를 남기고 이전 상태로 rollback하는 구조도 있습니다. (Prime Intellect)

따라서 이것은 사실상 “agent-level continual learning”을 weights 밖에서 구현하려는 접근법이라고 이해하면 좋습니다.

---

5. 장시간 자율 작업은 꽤 제대로 설계되어 있습니다

Prime Agent에는 서로 다른 역할의 기능이 따로 존재합니다.

기능역할

Persistent Goal	끝날 때까지 목표 유지
Autonomous Mode	다음 작업을 계속 실행
Heartbeat	일정 간격으로 agent 깨우기
Schedule	특정 시점/cron 실행
Subagent	병렬 전문 작업
Compaction	오래된 context 압축
JSONL persistence	세션 기록
Daemon	UI와 실행 분리

예를 들어 heartbeat는 사용자용 /heartbeat와 agent가 직접 만드는 rlm_heartbeat가 분리되어 있습니다. prime-agent schedule은 one-time 또는 cron prompt를 별도로 예약할 수 있습니다. (GitHub)

따라서 이런 구조가 가능합니다.

Goal:
"서비스 전체 성능을 개선하고 테스트까지 통과시켜라."

09:00
main agent 시작

09:05
├── backend-agent
├── frontend-agent
├── db-agent
└── benchmark-agent

09:30 heartbeat
"benchmark 결과 확인"

10:00
benchmark-agent → main
"API P95 820ms"

main
→ backend-agent
"DB query 최적화"

11:00
test gate 실행

FAILED

main
→ 수정

12:00
test gate

PASSED

goal.complete()

Autonomous mode에는 max turns, token budget, wall-clock timeout과 quality gate를 설정할 수 있고, gate가 실패하면 그 출력을 agent에게 다시 넘겨 후속 작업을 수행하게 할 수 있습니다. (GitHub)

이 부분이 단순 cron 기반 AI script와 큰 차이입니다.

---

6. Codex / Claude Code와 가장 다른 부분

제가 보기에는 차이를 이렇게 잡는 것이 가장 정확합니다.

Codex / Claude Code 계열Prime Agent

중심 abstraction	Agent + tools	Agent + persistent REPL
tool 사용	개별 tool calling	Python program
subagent	task delegation	persistent agent process
context	모델 context 중심	context + Python state
장기 작업	continuation 중심	daemon + goal + schedule + heartbeat
학습	rules/memory	Continual Harness CRUD
skill	instructions/scripts	Python package 가능
A2A	제한적	native messaging

[Inference] 그래서 Prime Agent의 진짜 경쟁 포인트는 모델 자체의 코딩 능력보다 “에이전트를 운영하는 OS/runtime”에 있습니다. 이 해석은 위 아키텍처와 공식 문서에 나타난 설계 패턴을 기반으로 한 것입니다. (GitHub)

---

7. 의외로 모델 선택도 자유롭습니다

현재 공식 provider 문서에는 OpenAI, Anthropic, Gemini, DeepSeek, Groq, Cerebras, OpenRouter, Fireworks, MiniMax, Kimi, Xiaomi MiMo 등 상당히 많은 provider가 나옵니다.

특히 OAuth 방식으로 ChatGPT Plus/Pro(Codex), Claude Pro/Max, GitHub Copilot도 지원한다고 문서화돼 있습니다. (GitHub)

즉:

Prime Agent
       │
       ├─ GPT
       ├─ Claude
       ├─ Gemini
       ├─ GLM
       ├─ MiniMax
       ├─ Kimi
       └─ OpenRouter models

같은 harness 실험이 가능합니다.

---

8. 주의할 부분도 큽니다

가장 큰 문제는 보안입니다.

Prime Agent 공식 문서도 IPython kernel과 worker가 security sandbox가 아니라고 명시하고 있습니다. 모델이 생성한 Python과 shell command가 기본적으로 사용자 OS 권한으로 실행됩니다. (GitHub)

따라서:

Prime Agent
↓
persistent Python
↓
shell
↓
filesystem
↓
skills
↓
subagents

처럼 agent의 힘이 커질수록 prompt injection이나 악성 repository, 악성 skill의 피해 범위도 커질 수 있습니다.

특히 장시간 autonomous mode를 쓸 거라면 Docker/VM/devcontainer 같은 별도 sandbox 안에서 돌리는 방식이 더 적합하다고 판단합니다. [Inference] 이는 공식 문서가 untrusted repository/instruction에 external sandbox 또는 restricted environment 사용을 권고한다는 점을 바탕으로 한 운영상 권고입니다. (GitHub)

---

9. 벤치마크는 흥미롭지만 아직 조심해서 봐야 합니다

Prime Intellect는 자체 발표에서 Prime Agent를 Opus 5, GPT-5.6 Sol, GLM-5.2 등과 조합해 장문맥 benchmark를 테스트했고, 여러 항목에서 native harness와 경쟁하거나 앞서는 결과를 보고했습니다. ARC-AGI-3에서도 높은 결과를 발표했습니다. (Prime Intellect)

그러나 이것은 Prime Intellect 자체 평가 결과입니다. 독립적인 대규모 재현 결과와 동일하게 취급해서는 안 됩니다. 또한 회사도 현재 모델들이 Prime Agent harness 자체를 대상으로 훈련된 것은 아니라고 밝히고 있습니다. (Prime Intellect)

---

10. 이 프로젝트에서 제가 가장 높게 보는 부분

[Inference] 개인적으로 기술적으로 가장 중요한 순서를 꼽으면 Persistent REPL → persistent subagent → Continual Harness → daemon/scheduler 순입니다. 이는 기능의 기반 의존관계를 기준으로 한 판단입니다.

특히 이 조합:

Persistent Python
       +
Persistent Subagents
       +
Persistent Memory
       +
Executable Skills
       +
Heartbeat
       +
Goal
       +
Scheduler

이 만들어내는 결과는 단순히

“AI가 코드를 잘 짠다.”

가 아니라

“AI 개발팀이 프로젝트 안에 계속 상주한다.”

에 가까워집니다.

예를 들어 하나의 프로젝트에:

main-agent
│
├── architect
├── backend
├── flutter
├── security
├── test
└── devops

를 장기간 유지하면서 각 agent에게 프로젝트별 memory와 skill을 축적시키는 구조입니다.

이게 잘 발전하면 Claude Code/Codex의 경쟁 제품보다는 오히려 AI Agent Runtime / Agent OS / autonomous engineering runtime이라는 분류가 더 적합해질 가능성이 있습니다. [Inference] 이는 현재 daemon, persistent session, RLM child lifecycle, scheduling, Continual Harness 구조를 종합한 판단입니다. (GitHub)

결론

주목할 가치가 상당히 큰 레포입니다. 특히 RLM = recursive call 정도로 보면 핵심을 놓칩니다. 진짜 포인트는 LLM이 Python을 자기 작업용 컴퓨터처럼 사용하고, 그 안에서 다른 LLM 세션까지 함수처럼 조직하며, 수행 과정에서 얻은 노하우를 memory/skill/subagent spec으로 축적하는 것입니다. (GitHub)

그리고 Prime Agent가 말하는 “self-improving”도 모델 자체 self-training이 아니라 harness의 self-improvement라고 이해하는 게 정확합니다.