더 많은 에이전트가 아니라 더 나은 조직이 지능을 만든다

에이전트는 모델이 아니라 지속적으로 움직이는 실행체다

논문은 Individual Agent를 foundation model과 harness, 그리고 시간에 따라 유지되는 local runtime state가 loop로 조직된 계산적 실체로 정의한다.

여기서 \(F_i\)는 언어 이해·추론·계획·생성 능력을 제공하는 Foundation Model, \(H_i\)는 memory·knowledge·tools·skills·permissions·execution environment를 연결하는 Agent Harness, \(s_i^t\)는 시점 \(t\)의 local runtime state다. 이 정의를 더 직관적으로 줄이면 논문의 도입부가 제시하는 식이 된다.

시스템 지능의 단위는 한 에이전트의 context가 아니다

Agent System은 여러 agent가 shared resources와 environment를 사용하면서 coordination mechanism을 통해 함께 움직이고, system-level runtime state를 공유하는 구조다.

Figure 1~4가 보여주는 것은 기술 목록보다 엔지니어링 대상의 확대다

Foundation Model의 pre-training과 post-training은 parameter-level capability를 만든다. Prompt Engineering은 무엇을 할지와 어떻게 접근할지를 지정하고, Context Engineering은 어떤 evidence와 intermediate state를 모델에게 보여줄지 관리한다. Harness Engineering은 model call 밖의 persistent capabilities를 붙이고, Loop Engineering은 이를 feedback-driven execution process로 묶는다.

이 단계까지가 논문이 부르는 Individual Intelligence다. 한 에이전트가 외부 자원을 사용하고 환경과 상호작용하며 목표를 지속적으로 추구할 수 있다. 그러나 과업이 충분히 복잡해지면 한 loop의 organizational capacity가 한계에 닿는다.

개인 지능의 세 가지 구조적 병목

논문의 소프트웨어 장애 진단 예는 직관적이다. log 분석, failure reproduction, code inspection은 병렬로 진행할 수 있지만 repair와 testing은 그 결과에 의존한다. 한 agent가 모든 것을 한 context에서 순차적으로 처리하면 병렬성뿐 아니라 책임 경계와 failure localization도 잃기 쉽다.

Graph Engineering은 graph를 시스템의 조직 기질로 사용한다

논문이 제안하는 핵심 정의는 structure-centered engineering이다. tasks, components, runtime states 사이의 관계를 externalize해 system-level organization, coordination, monitoring, recovery, optimization을 가능하게 한다. GraphRAG처럼 graph를 retrieval source로 사용하는 것과 다르다. 여기서는 graph의 구조가 바뀌면 시스템의 실행방식이 달라진다.

목표를 subgoal graph로 만들면 기다려야 할 일과 동시에 할 일이 보인다

Goal Decomposition Graph에서 node는 subtask 또는 intermediate goal, edge는 precedence·data·logical relation을 나타낸다. 이 명시적 구조는 parallel branch와 dependent branch를 구분하고, intermediate result가 들어왔을 때 남은 task graph만 수정할 수 있게 한다.

논문은 HuggingGPT와 ReWOO에서 시작해 LLMCompiler의 dataflow DAG, Plan-over-Graph의 parallelizable schedule, TDAG·Flow·DynTaskMAS의 dynamic task graph로 계보를 정리한다. 중요한 진화는 decomposition이 prompt 안의 숨은 reasoning에서 inspectable and schedulable structure로 외부화됐다는 점이다.

subgoal은 곧바로 실행되지 않는다. operator graph로 컴파일되어야 한다

실행 단계에서는 LLM call, specialist agent, retrieval module, tool, memory operation, aggregator, verifier 같은 concrete operator가 필요하다. Workflow Optimization은 semantic subgoal을 이 operator들로 컴파일하고, edge에 scheduling·coordination·verification dependency를 부여한다.

이때 workflow는 더 이상 배포 전에 한 번 설계하는 고정 파이프라인이 아니다. EvoFlow는 여러 workflow graph를 competing executable hypotheses처럼 유지하고, QualityFlow는 accept/debug/clarify/rollback/continue를 quality signal에 따라 고른다.

agent를 이름이 아니라 capability, access, reliability 관계로 본다

Capability Graph의 node는 agent, skill, tool, model, resource가 될 수 있고 typed edge는 capability ownership, resource access, permission, reliability를 나타낸다. task가 요구하는 capability subgraph와 실제 agent-resource subgraph를 맞추면 capability-aware assignment와 replacement가 가능해진다.

예컨대 scientific discovery에서 literature analysis, experiment design, implementation, independent verification을 다른 specialist에게 맡긴다. 특정 agent가 compute resource 접근권한을 잃으면 graph query로 compatible replacement를 찾아 재배정할 수 있다.

DyLAN, Agent-Oriented Planning, MasRouter는 행동과 score를 통해 suitability를 추론하고, AutoAgents·EvoAgent·AOrchestra·Captain Agent는 task-specific specialists를 구성한다. SkillGraph와 MaAS는 더 명시적인 graph organization으로 나아간다. 논문은 여기서 한 걸음 더 나가 persistent and updateable capability graph의 필요성을 제기한다.

역할을 만든다고 팀이 되는 것은 아니다

Team Organization Graph는 assignment, delegation, supervision, verification, reporting relation을 표현한다. capability가 “무엇을 할 수 있는가”라면 team graph는 “누가 무엇을 책임지고 결과를 누구에게 넘기는가”를 정의한다.

parallelism과 diversity는 공짜가 아니다. branching이 늘면 communication, computation, aggregation cost가 늘어난다. 따라서 team graph는 “가능한 많은 agent를 붙이는 법”이 아니라 필요한 책임 관계만 남기는 법이어야 한다.

팀의 구조와 실제 정보 흐름은 다르다

상대적으로 안정적인 team organization과 달리 communication graph는 runtime마다 달라질 수 있다. node는 agents와 human participants, active edge는 누가 누구에게 어떤 정보를 보내고 그 feedback이 다음 행동에 어떤 영향을 주는지를 나타낸다.

MAgICoRe는 generation-evaluation-revision feedback loop를 만들고, G-Designer는 performance·communication cost·structural robustness를 함께 고려해 topology를 생성한다. AgentPrune과 AgentDropout은 low-value edges 또는 agents를 제거하고, DyTopo는 매 round마다 information need와 information supply를 맞춰 sparse edges를 재구성한다. CARD는 model capability, tool availability, compute resource의 환경 변화까지 communication structure에 반영한다.

Collaborative Gym은 human을 graph 밖의 평가자가 아니라 active participant로 넣는다. assistance request, feedback, approval, escalation edge를 통해 고위험 작업에서 사람이 execution loop에 직접 들어올 수 있다.

계획은 “무엇이 일어나야 하는가”를 말하고, state graph는 “무엇이 실제로 일어났는가”를 기록한다

여러 agent와 tool이 동시에 움직이면 progress, role bindings, commitments, shared facts, resource changes, external effects가 서로 다른 곳에서 발생한다. 이 업데이트를 traceable form으로 남기지 않으면 시스템은 자기 상태를 신뢰할 수 없다.

State Recording은 각 transition의 evidence, provenance, version을 보존한다. Magentic-One의 Task/Progress Ledger, Graph of States의 structured belief state, PatchBoard의 schema/permission/invariant validation, MemTX의 tentative write와 transactional belief commit 분리, Collaborative Memory의 scoped projection, event-sourced log가 이 방향의 서로 다른 예다.

dependency는 원인 후보를 좁히지만 causality를 증명하지 않는다

long-horizon system에서는 원인이 된 작은 deviation과 눈에 보이는 failure가 멀리 떨어질 수 있다. Fault Localization은 abnormal outcome을 감지하고, decisive error가 처음 등장한 지점을 찾고, dependency를 따라 영향을 추적하며, 가능한 원인 가설을 evidence로 검증한다.

MAGE는 execution path를 hierarchical state tree로 다루고, Who & When은 책임 agent와 decisive step을 함께 attribution한다. MAST는 system-design, inter-agent coordination, task-verification failure를 구분하고, TraceElephant는 final answer뿐 아니라 trace, intermediate context, complete input을 활용한다. TDAD와 Cordon은 code-test 또는 typed lineage와 external effect를 연결한다.

복구는 처음부터 다시 하는 것이 아니라 valid work를 살리는 일이다

Failure Recovery는 explicit recovery boundary를 정하고, invalid state만 retract하거나 affected region만 replay하며, irreversible external effect에는 compensation을 수행하고, 필요하면 alternative branch로 갈라진다.

MAGE, ALAS, CausalFlow, ReflexGrad는 selective repair를, AgentGit·Shepherd·event sourcing은 replay/rollback/branching을, DART는 semantic recovery boundary를, SagaLLM·RAC·Atomix는 external effect compensation과 transactional settlement를 다룬다.

실행의 결과가 다음 실행의 구조를 바꿔야 ‘진화’라고 부를 수 있다

조건부 routing이나 임시 worker assignment는 한 run을 바꿀 뿐 다음 run의 조직을 바꾸지 않을 수 있다. 논문이 요구하는 self-evolving graph system은 execution evidence를 persistent and reusable structural change로 변환한다.

Task Organization의 진화에는 TDAG, Flow, DynTaskMAS, DyFlow, EvoFlow, QualityFlow가 등장한다. Agent Coordination에서는 SwarmAgentic, AgentNet, self-organizing agents, Meta-Team, DyTopo, CARD, QueenBee Planner가 team topology와 communication rule을 바꾼다. Runtime State에서는 ReCreate, SkillGraph, Swarm Skills가 실행경험을 재사용 가능한 pattern/skill로 만들고, MemTX와 event-sourced designs가 잘못된 persistent update를 수정·retract·fork할 수 있게 한다.

다만 FlowSteer가 보여주듯 replanning signal 자체가 조작되면 graph evolution은 더 나쁜 구조로 갈 수 있다. 따라서 self-evolution의 목표는 무제한 self-modification이 아니라 evidence-gated, versioned, reversible structural improvement다.

memory, skill, tool registry를 따로 두는 방식도 구조적 한계에 닿는다

현재 agent system은 memory store, skill library, tool registry를 별도 collection/service로 유지하는 경우가 많다. 그러나 capability가 늘면 selection은 관계문제가 된다. 어떤 skill은 다른 skill에 의존하고, 어떤 tool은 대체 가능하며, 특정 permission이나 runtime condition에서만 쓸 수 있다.

논문은 A-MEM, Zep, Graph of Skills, SkillDAG 등을 단서로 models, tools, skills, memories, data sources, verifiers, execution environments를 typed nodes로 묶는 unified capability graph를 제안한다. edge는 dependency, compatibility, composition, substitution, authorization, cost, reliability를 표현한다. 핵심은 capability graph를 task graph, agent graph, state graph와 연결하는 것이다.

Task graph만 바꾸면 team과 permission이 함께 깨질 수 있다

Graph Engineering의 여러 graph는 독립적으로 진화할 수 없다. task decomposition을 바꾸면 요구 capability가 달라지고, agent replacement는 communication relation, permissions, runtime assumptions를 무효화할 수 있다. 그래서 future system은 cross-graph consistency와 impact analysis를 관리해야 한다.

workflow framework를 넘어 시스템 object와 transaction을 제공하는 runtime

현재 stack은 model serving, harness, workflow engine, memory, multi-agent framework, state store가 서로 다른 abstraction을 쓴다. MCP는 capability access를 표준화하지만 complete system organization의 공통 표현은 제공하지 않는다. LangGraph는 graph-oriented workflow/state를 제공하고, AIOS는 scheduling·context·memory·storage·tools·access control을 OS service처럼 다룬다.

논문이 그리는 graph-native Agent OS에서는 task, agent, capability, runtime state가 typed and versioned first-class graph object가 된다. runtime은 graph scheduling, capability discovery, state storage, event/provenance logging, structural transaction, permission enforcement, checkpointing, replay, rollback, graph-level observability를 공통 서비스로 제공한다.

시스템 지능은 정보의 복제와 책임의 분산도 함께 키운다

multi-agent long-horizon system에서는 sensitive information이 여러 component와 workflow를 따라 복제되고 persistent state에 남을 수 있다. cross-task leakage와 unauthorized inference 위험이 커지고, bias나 faulty evidence가 여러 agent를 통해 증폭되면 책임소재도 모호해진다.

따라서 privacy-preserving state management, scoped permissions, provenance-aware logging, human oversight가 Graph Engineering의 부가 기능이 아니라 구조적 요구사항이다.

Graph는 관계를 명시하지만 그 관계의 의미까지 자동으로 합의시키지는 않는다

두 agent가 같은 “done” edge를 보더라도 task completion의 기준, sufficient evidence, valid state, authorized action의 뜻을 다르게 해석할 수 있다. Ontology Engineering은 어떤 entity가 존재하고 relation이 무엇을 뜻하며 어떤 constraint가 성립해야 하고 어떤 conclusion을 derive할 수 있는지를 machine-interpretable form으로 정의한다.

논문은 monolithic ontology보다 layered and modular ontology를 제안한다. core ontology 위에 goal/value, agent/capability, observation/evidence, action/state, evaluation modules를 두고, 특정 domain ontology가 이를 확장한다.

ontology는 가치를 결정하지 않지만 목표의 규칙을 검증 가능하게 만든다

candidate goal의 provenance, priority, authorization scope, completion criteria, constraints를 명시하면 goal conflict와 unauthorized modification을 탐지하고 completion에 필요한 evidence를 정할 수 있다. 중요한 한계도 분명하다. ontology는 시스템이 어떤 가치를 선택해야 하는지 결정하지 못한다. 다만 선택된 규범을 explicit and verifiable하게 만든다.

LAMP 계열 예시는 Planner, Builder, Verifier가 domain ontology를 MCP를 통해 공유하고, Agentology는 개별 prompt보다 ontology-defined environment를 system design의 중심에 둔다.

의미의 일치와 사실의 일치는 다르다

shared ontology는 tool output, environmental observation, timestamp, provenance, validation result와 연결되어야 한다. semantic consistency만으로 factual correctness가 생기지 않기 때문이다. OntoCodex는 여러 agent를 이용해 biomedical ontology를 확장하면서 structural constraints와 curated knowledge grounding을 유지하고, CoA-Text2OWL은 ontology learning을 worker-manager collaboration으로 분산한다. AgentO와 Ontology-to-Tools는 semantic concept를 executable capability와 연결한다.

future ontology는 agents가 concept와 relation을 제안하더라도 provenance checking, consistency validation, impact analysis를 거쳐야 하며 version control, compatibility, migration, rollback을 지원해야 한다.

AI Co-Scientist에서 중요한 것은 hypothesis refinement보다 구조의 기억이다

SciAgents는 ontological knowledge structure로 specialist agents를 ground하고, AI Scientist는 ideation부터 experiment, visualization, writing, review까지 long-running process를 구성한다. Virtual Lab은 PI agent와 specialist scientist team을 physical validation에 연결한다. Co-Scientist는 generation, critique, ranking, refinement를 비동기 supervisor가 조정하고, Robin은 literature/data-analysis agents와 lab result를 연결해 hypothesis를 갱신한다.

그러나 survey는 중요한 선을 긋는다. hypothesis가 반복 수정되는 것과 agent organization 자체가 persistent하게 진화하는 것은 다르다. Graph Engineering의 더 강한 기준은 hypotheses, negative results, data lineage, experimental interventions, causal dependencies를 보존하고, evidence가 이후 시스템 구조를 재현 가능하게 바꾸는 것이다.

그래프는 추적성을 높이지만 정답을 보증하지 않는다

Healthcare에서 longitudinal state는 단순 conversation memory가 아니다. 이전 symptom, treatment, response, investigation이 이후 action의 타당성을 바꾼다. 그래서 provenance, uncertainty, access control, human authorization이 필수다. Enterprise에서는 permission, separation of duties, policy, transaction boundary, rollback이 실행성공만큼 중요하다.

Social/economic simulation에서는 graph topology 자체가 관찰되는 emergent behavior를 바꿀 수 있다. 따라서 simulated emergence를 real-world causality로 읽으려면 실제 관측과 calibration, explicit uncertainty analysis가 필요하다.

그래프를 쓴다고 Graph Engineering이 되는 것은 아니다

논문의 appendix가 가장 명확하게 구분한다. 기존 graph-agent research는 graph를 reasoning, planning, memory, retrieval, tool organization, workflow, communication을 향상시키는 representation 또는 computational mechanism으로 쓴다. Graph Engineering은 한 단계 더 나가 explicit graph structures 자체를 intelligent system의 organizational substrate로 둔다.

Task Organization, Agent Coordination, Runtime State Management는 서로 연결돼 있고, one graph의 변경이 다른 graph의 assumptions를 바꾼다. System Evolution은 execution experience를 persistent structural improvement로 만들며, Ontology Engineering은 이 모든 graph의 entity, relation, constraint를 공유 의미로 묶는다.

Dynamic graph transformation 관점과도 가깝지만 organizing question이 다르다. dynamic graph transformation은 “agent components가 어떻게 계속 rewrite될 것인가”에서 출발한다. Graph Engineering은 “System Intelligence를 이루려면 tasks, actors, states를 어떻게 공동으로 조직·통제·개선할 것인가”에서 출발한다. evolution은 전체 중 한 축이다.

현재 가장 성숙한 것은 Work와 Team, 가장 부족한 것은 persistent System Evolution이다

실제 응용에서는 objective decomposition, role assignment, parallel work, communication topology가 이미 흔하다. checkpoints, task boards, event streams, longitudinal records처럼 Runtime State도 빠르게 늘고 있다. 하지만 성공과 실패의 evidence를 이용해 다음 실행에서도 유지되는 조직구조 자체를 자동으로 수정하는 시스템은 아직 드물다.

그래서 이 survey의 주장을 “multi-agent를 graph로 연결하면 System Intelligence가 된다”로 읽으면 과장이다. 더 정확한 해석은 이렇다. 오늘의 시스템은 graph-structured해지고 있지만, full Graph Engineering은 structural objective, observability, governed mutation, cross-graph consistency, transferable structural improvement까지 요구한다.