Google's 'graph engineering' frames an agent system as an org chart of nodes — some LLM agents, some deterministic functions — wired by explicit edges and a shared state. The claim worth keeping: when you already know the workflow, pinning it as a graph buys the predictability, debuggability, and control that a single loop or an emergent swarm gives up. Fan-out, join, and router are just parallelism, a barrier, and a switch statement wearing new names.
Not yet scoped — the deliverable is a decision, not a build. For one workflow you actually run (a PR review, a digest triage), first disambiguate the three scopes the talk separates: the harness (one agent's environment — its tools, memory, guardrails), the loop (that agent reasoning → acting → observing until its goal is met), and the graph (the multi-node orchestration coordinating agents, loops, and deterministic functions through a shared state). Then pick the shape by how much of the path you know in advance: a single loop for a simple iterative task, a graph when the steps are known and you want them predictable, a swarm only when the path is genuinely open-ended. Source: Google Cloud Tech, 'Graph Engineering 101' (youtube.com/watch?v=IrW0_f-w4kA) — agent vs function nodes, shared state via ADK, a PR-review pipeline built from fan-out / join / router, and the loop vs graph vs swarm trade-off table. Confirm timings and terms against the video before citing them.
Why
Three scopes get called 'the agent,' and most confused arguments are two people meaning different ones. They nest: the harness is one model's environment (tools, memory, guardrails); the loop is that harness running — reason, act, observe — until a goal is met; the graph is many of those, plus deterministic functions, wired into one workflow through a shared state. 'Make the agent do X' is ambiguous until you say which scope owns X. Naming the three is most of the value.
Graph engineering is ordinary computer-science control flow, with LLMs as some of the nodes. The PR-review example makes it concrete: fan-out is parallelism (split into five checks at once instead of five in a row — latency drops); the join is a barrier (wait for the slowest branch, then aggregate); the router is a switch statement (branch on the synthesized result — fail → a fixer agent, pass → human approval). None of that is new; what is new is that a node can be a non-deterministic reasoner. So the discipline is old data-structures-and-control-flow, applied to parts that no longer behave deterministically.
It is not a knowledge graph, and the shared word hides the difference. A knowledge graph is a data model — entities, relations, retrieval (graph RAG). Graph engineering is control flow — what runs, in what order, routed on results. Same noun, orthogonal axis: one describes what the system knows, the other what the system does.
The real decision is loop vs graph vs swarm, and it is a bet on how much of the path you already know. A swarm (agents with personalities and loose directives, collaborating without fixed edges) buys flexibility for open-ended problems — at the price of predictability. A graph spends the knowledge you have — every node, edge, and transition pre-defined — to buy predictability, debuggability, and isolation of responsibility. The common mistake is reaching for a swarm when the workflow is actually a known DAG: you surrender determinism you never needed to give up, and then debug an emergent system to get it back. The opposite mistake is forcing a rigid graph onto a genuinely open problem, pretending to a certainty you do not have. This is exactly the harness/workflow choice a coding agent makes every day — one subagent loop, or a fan-out workflow with a join and a router — which is why the card is a decision rule, not a framework.
How it works
Reading note, not a demo.
Three nested scopes people conflate
Scope
What it is
The one question it owns
Harness
one model's environment: tools, memory, guardrails
what can this agent see and do?
Loop
that harness running: reason → act → observe, until the goal
is this agent done yet?
Graph
many loops + deterministic functions, via shared state
what runs next, and in what order?
The PR-review patterns are old control flow
Pattern
Classic CS name
What it does
Fan-out
parallelism
run five checks at once, not in sequence — latency drops
Join
a barrier
wait for the slowest branch, then aggregate + synthesize
Router
a switch statement
branch on the result: fail → fixer agent, pass → human merge
The choice is a bet on how much you know
Shape
Pre-defined?
Best when
Buys
Gives up
Loop
one agent, iterating
a simple, single-goal task
simplicity
multi-step structure
Graph
every node & edge
the workflow is known ahead
predictability, debuggability, control
flexibility
Swarm
personalities, loose rules
the path is open-ended
exploration
determinism
The failure mode is a category error: a swarm for a known DAG (throwing away determinism you didn't need to) or a graph for an open problem (faking a certainty you don't have). Cross-refs: the-harness-not-the-model (the harness is the innermost scope here — govern it, don't rebuild it), ai-engineering-is-framing-non-determinism (a graph pins the non-determinism to specific nodes and makes the edges deterministic), agent-ask-not-write (the router's fail branch is where a human ask belongs), cli-batch-vs-mcp-interactive (a graph favours artifact-leaving batch steps over open conversation).
구글의 '그래프 엔지니어링'은 에이전트 시스템을 노드들의 조직도로 봅니다 — 일부는 LLM 에이전트, 일부는 결정론적 함수 — 명시적 엣지와 공유 상태로 엮인. 붙들 주장: 워크플로를 이미 알 때, 그것을 그래프로 고정하면 단일 루프나 창발적 스웜이 포기하는 예측 가능성·디버깅 가능성·통제를 사옵니다. 팬아웃·조인·라우터는 각각 병렬화·배리어·switch 문이 새 이름을 쓴 것일 뿐입니다.
아직 범위 미정 — 산출물은 만들기가 아니라 결정입니다. 실제로 돌리는 워크플로 하나(PR 리뷰, 다이제스트 분류)에 대해, 먼저 영상이 구분하는 세 범위를 분리하세요: 하네스(한 에이전트의 환경 — 도구·메모리·가드레일), 루프(그 에이전트가 목표 달성까지 추론 → 행동 → 관찰), 그래프(공유 상태를 통해 에이전트·루프·결정론적 함수를 조율하는 다중 노드 오케스트레이션). 그다음 경로를 얼마나 미리 아는지로 형태를 고릅니다: 단순 반복 작업이면 단일 루프, 단계가 알려져 있고 예측 가능하길 원하면 그래프, 경로가 진짜로 열려 있을 때만 스웜. 출처: Google Cloud Tech, 'Graph Engineering 101'(youtube.com/watch?v=IrW0_f-w4kA) — 에이전트 대 함수 노드, ADK 공유 상태, 팬아웃/조인/라우터로 지은 PR 리뷰 파이프라인, 루프 대 그래프 대 스웜 트레이드오프 표. 타이밍·용어는 영상으로 확인.
왜
세 범위가 모두 '에이전트'라 불리고, 헷갈리는 논쟁 대부분은 두 사람이 서로 다른 범위를 뜻하는 것입니다. 셋은 중첩됩니다: 하네스는 한 모델의 환경(도구·메모리·가드레일); 루프는 그 하네스가 도는 것 — 추론·행동·관찰 — 목표 달성까지; 그래프는 그런 루프 여럿에 결정론적 함수를 더해, 공유 상태로 하나의 워크플로로 엮은 것. '에이전트가 X를 하게 하라'는 어느 범위가 X를 소유하는지 말하기 전엔 모호합니다. 셋에 이름 붙이는 것이 가치의 대부분입니다.
그래프 엔지니어링은 평범한 컴퓨터과학 제어 흐름이고, 노드 일부가 LLM일 뿐입니다. PR 리뷰 예가 구체화합니다: 팬아웃은 병렬화(다섯을 차례로 대신 한 번에 — 지연 감소); 조인은 배리어(가장 느린 가지를 기다렸다가 취합); 라우터는 switch 문(종합 결과로 분기 — 실패 → fixer 에이전트, 통과 → 사람 승인). 새로운 건 없습니다; 새로운 건 노드가 비결정론적 추론자일 수 있다는 것뿐. 그래서 이 규율은 오래된 자료구조·제어흐름을, 더 이상 결정론적이지 않은 부분에 적용한 것입니다.
지식 그래프가 아니며, 같은 단어가 차이를 가립니다. 지식 그래프는 데이터 모델 — 엔티티·관계·검색(graph RAG). 그래프 엔지니어링은 제어 흐름 — 무엇이, 어떤 순서로, 결과에 따라 어디로. 같은 명사, 직교하는 축: 하나는 시스템이 아는 것을, 다른 하나는 시스템이 하는 것을 기술합니다.
진짜 결정은 루프냐 그래프냐 스웜이냐이고, 이는 경로를 얼마나 이미 아는지에 대한 베팅입니다.스웜(성격과 느슨한 지시를 가진 에이전트들이 고정 엣지 없이 협업)은 열린 문제에 유연성을 사옵니다 — 예측 가능성을 대가로. 그래프는 가진 지식을 씁니다 — 모든 노드·엣지·전이를 사전 정의 — 예측 가능성·디버깅 가능성·책임 격리를 사려고. 흔한 실수는 워크플로가 사실 알려진 DAG인데 스웜에 손을 뻗는 것입니다: 포기할 필요 없던 결정성을 내주고, 그걸 되찾으려 창발 시스템을 디버깅합니다. 반대 실수는 진짜로 열린 문제에 경직된 그래프를 강요해, 갖지 않은 확실성을 가진 척하는 것. 이건 코딩 에이전트가 매일 하는 하네스/워크플로 선택 그대로입니다 — 서브에이전트 루프 하나냐, 조인과 라우터가 달린 팬아웃 워크플로냐 — 그래서 이 카드는 프레임워크가 아니라 결정 규칙입니다.
동작 방식
데모가 아니라 정독 노트입니다.
사람들이 뭉뚱그리는 세 중첩 범위
범위
정체
소유하는 한 질문
하네스
한 모델의 환경: 도구·메모리·가드레일
이 에이전트가 무엇을 보고 할 수 있나?
루프
그 하네스가 도는 것: 추론 → 행동 → 관찰, 목표까지
이 에이전트는 다 됐나?
그래프
루프 여럿 + 결정론적 함수, 공유 상태로
다음에 무엇이, 어떤 순서로 도나?
PR 리뷰 패턴은 오래된 제어 흐름
패턴
고전 CS 이름
하는 일
팬아웃
병렬화
다섯 검사를 순차가 아니라 한 번에 — 지연 감소
조인
배리어
가장 느린 가지를 기다렸다가 취합 + 종합
라우터
switch 문
결과로 분기: 실패 → fixer 에이전트, 통과 → 사람 머지
선택은 얼마나 아는지에 대한 베팅
형태
사전 정의?
최적 상황
사는 것
포기하는 것
루프
에이전트 하나, 반복
단순·단일 목표 작업
단순함
다단계 구조
그래프
모든 노드·엣지
워크플로를 미리 앎
예측·디버깅·통제
유연성
스웜
성격·느슨한 규칙
경로가 열려 있음
탐색
결정성
실패 모드는 범주 오류입니다: 알려진 DAG에 스웜(필요 없던 결정성을 버림) 또는 열린 문제에 그래프(갖지 않은 확실성을 꾸밈). 교차: the-harness-not-the-model(하네스는 여기서 가장 안쪽 범위 — 다시 짓지 말고 다스려라), ai-engineering-is-framing-non-determinism(그래프는 비결정성을 특정 노드에 고정하고 엣지를 결정론적으로 만든다), agent-ask-not-write(라우터의 실패 가지가 사람에게 묻는 자리), cli-batch-vs-mcp-interactive(그래프는 열린 대화보다 산출물을 남기는 배치 단계를 선호).