# Graph Engineering vs Loop Engineering — mi változott valójában és mi csak átnevezés

**Szerző:** Shirley (AI Builder Club)  
**Dátum:** 2026. július 20.  
**Forrás:** [aibuilderclub.com/blog/graph-engineering-vs-loop-engineering](https://www.aibuilderclub.com/blog/graph-engineering-vs-loop-engineering) (10 perc olvasás)  
**Típus:** public-affairs tech-elemzés (single-page blog poszt, AI Builder Club "Build AI Agents" kurzus 4.16-os lecke)

## A szerző központi tézise

A 2026. július 18-án elindult "graph engineering" vita ("Loop engineering halott, éljen a graph engineering!") túlreagálás mindkét oldalon. A graph engineering **valódi paradigmaváltás** három konkrét új képességgel — de a gyakorlat (topológia, párhuzamosság, explicit vezérlési folyamat) nem új: a LangGraph, Microsoft AutoGen és Google ADK évekkel a buzzword előtt szállítják. A lényeg: **a loop a graph speciális esete (egy node önmagába visszacsatlakozó éllel)**, és minden graph-node továbbra is loop. Nem dobjuk el a loopokat, hanem komponálunk belőlük graphot, amikor egy loop már nem elég.

## A cikk struktúrája

### 1. A két fogalom tiszta szétválasztása

A cikk egy összehasonlító táblázattal nyit, ami a két megközelítést dimenziók mentén választja szét:

| Dimenzió | Loop engineering | Graph engineering |
|----------|------------------|-------------------|
| **Egység** | Egyetlen ügynök ciklusa | Több node + él + megosztott állapot |
| **Alak** | Ciklus: discover → plan → execute → verify → ismétlés | Irányított graph: node-ok vezérlési élekkel összekötve |
| **Node-ok** | Nincs (maga a loop) | Specializált ügynökök vagy lépések (researcher, writer, reviewer) |
| **Élek** | Az egyetlen "repeat" nyíl vissza az elejére | Vezérlési folyamat node-ok között: elágazások, fan-out/fan-in, loopok |
| **Állapot** | Az ügynök kontextusában | Az élek mentén áramlik, node-ok között megosztva |
| **Amit tervezel** | A ciklus és a stop condition | A topológia és a routing |
| **Mikor csődöl el** | A verifier gyenge | A topológia rossz, vagy az állapot szivárog a node-ok között |

A kulcsmondat @rohit4verse metaforája: **"az ügynökök a while-loopokból org chartokká érettek"** — specializált node-ok párhuzamosan futnak, az állapot közöttük áramlik. A loop a while-loop, a graph az org chart.

### 2. Az öt AI engineering réteg kontextusba helyezése

@sairahul1 keretezése: egy AI alkalmazás öt rétegből épül fel, kívülről befelé haladva: **Prompt → Context → Harness → Loop → Graph**. A graph a legkülső, ötödik réteg, ami nem helyettesíti az alatta levőket, hanem körbeveszi őket. A cikk hangsúlyozza: a graph engineering vita arról szól, hogy a nyilvános beszélgetés végre eljutott a legfelső rétegig, nem arról, hogy a többi elavult.

### 3. Mi változott valójában? — A napi kutatási brief példája

A cikk egy konkrét feladaton, a "napi kutatási brief"-en mutatja be a különbséget. A feladat: minden reggel forrásokat olvas, egyoldalas összefoglalót ír, és ellenőrzi a pontosságot, mielőtt a postaládába érkezik.

**Egyetlen túlterhelt loopként** egy ügynök mindent egy kontextusban csinál: keres, beönti a nyers HTML-t, megírja a briefet, majd "saját magát review-ja". Mire a review-hoz ér, a kontextus mocsár — nyers keresési HTML, félig megírt próza, korábbi érvelések összemosódnak. A review ugyanabban a kontextusban fut, ami írta, tehát **saját munkáját igazolja**. A forrásokat egyenként olvassa (a loop szekvenciális).

**Egy kis graphként** ugyanaz a feladat három node-dá válik, állapot áramlik közöttük:

```
in → [researcher] → notes → [writer] → draft → [reviewer] → brief
                    (fan-out       (clean      (fresh ctx, brief
                     N forrás,     notes       + accuracy bar)
                     párhuzamos)   only)
```

- A **researcher node** párhuzamosan fan-out-ol a források felett, strukturált jegyzeteket ad vissza, soha nem ír prózát.
- A **writer node** csak tiszta jegyzeteket lát, soha nem a nyers HTML-t, és megírja a briefet.
- A **reviewer node** tiszta kontextusban fut, csak a briefet és a pontossági mércét látja, és hiba esetén visszairányítja a writer-hez.

A graph három valóban új képességet ad:

1. **Párhuzamos specializált node-ok tiszta, szeparált kontextussal** — a writer nem fullad a keresési dumpokba, a reviewer nem a saját piszkos kontextusában dolgozik.
2. **Explicit, auditálható vezérlési folyamat** — a routing előre definiált ("ha review elbukik, menj vissza"), diagramként olvasható, nem kell kibogarászni egy hosszú transcriptból. Pontosan az a fegyelem, amit @DavidKPiano (XState készítője) évek óta képvisel: a vezérlés legyen explicit és inspektálható, ne implicit és remélt.
3. **Fan-out / fan-in** — egy loop ezt nem tudja: tíz research node tíz forráson, párhuzamosan, aztán merge. Google's ADK és a LangGraph is ezt a primitívet szállítja.

### 4. A graph ára (és az átnevezés valósága)

A graph nem ingyenes. Három promptot kell karbantartani egy helyett, kell egy állapot-séma a node-ok között ("mit ad át a researcher a writer-nek?"), és új failure mode-ok jönnek: merge ami csendben eldob egy forrást, routing bug ami örökké loopol, állapot ami szivárog egyik node-ból a másikba. A napi brief esetén ez a felhajtás megéri a minőséget. Egyszeri feladatnál tiszta adó.

A "graph engineering" szó maga **naming event, nem technical event**. A state-machine és graph orchestration a LangGraph-ban (StateGraph: add_node, add_edge, state az élek mentén), Microsoft AutoGen GraphFlow-ban (DiGraph: szekvenciális, párhuzamos, feltételes, loop flow), és Google ADK-ban (graph workflows, routing, multi-agent delegation A2A protokollal) **mind a buzzword előtt** szállítják. A topológia, a párhuzamosság és az explicit vezérlés valódi képességek; a "graph engineering" elnevezés csak címke.

### 5. A 4-kérdéses gut check — tényleg paradigmát váltottál?

A cikk egy használható önellenőrző listát ad. Mielőtt azt mondod magadnak, hogy "átmentem loopról graphra", számold meg az igennel válaszolt kérdéseket:

1. **Szétválasztottad egy kontextus több specializált kontextusra?** Külön promptok és tool-ok node-onként, nem egy ügynök ami kalapot vált egyetlen transcripton belül. (Nem = átnevezted a loopot.)
2. **Van valódi fan-out / fan-in?** Valami párhuzamosan fut és összeolvad, nem egy dobozokkal rajzolt szekvencia. (Nem = flowchartos loop.)
3. **A vezérlési folyamat diagramként olvasható?** A routing ("ha review elbukik, visszamegy") előre definiált és inspektálható, nem egy ügynök megítéléséből emergál. (Nem = implicit loopod van.)
4. **Az objektív és a siker-mérce megváltozott?** @PawelHuryn érve: ha "kész és helyes" pontosan úgy van definiálva mint eddig, a mögöttes fegyelem nem mozdult, csak a rajz.

**Értékelés:** 0-1 igen = loopod van graph diagram alatt. Tartsd meg loopnak és kíméld meg magad a failure mode-októl. 2-3 igen = valóban komponálsz loopokat graphba, az új képességek megérik az árukat. 4 igen = paradigmát váltottál, és ezt a munka követelte meg, nem a timeline.

Az egysoros teszt: **ha meg tudod nevezni a specializált szerepeket és tudsz köztük nyilat húzni, az graph. Ha egyetlen feladat amit ismételgetni kell amíg helyes, az loop — tartsd meg loopnak.**

## A cikk érvelési stratégiája

A szerző három technikát alkalmaz a hype lehűtésére:

1. **Pozitív és negatív szkeptikus idézése egyaránt** — a "graph engineering halott" tábor (@PawelHuryn "I call BS") és a "state machine, kedd van" tábor (@DavidKPiano) is megjelenik, és a szerző mindkettőből integrál: Huryn-től a fegyelmet, DavidKPiano-tól a topológia prior art-ját.
2. **Egy konkrét feladat (napi kutatási brief) szembeállítása** — a két megközelítést nem absztrakt módon hasonlítja össze, hanem egy konkrét use-case-en demonstrálja a különbséget és az árát.
3. **A 4-kérdéses gut check** — a szerző nem állítja, hanem eszközt ad: az olvasó maga dönti el, hogy az ő rendszerénél van-e paradigmaváltás vagy csak átnevezés.

A prior art rész konkrét és ellenőrizhető: LangGraph StateGraph API, AutoGen GraphFlow DiGraph, Google ADK graph workflows + A2A protokoll. A cikk explicit módon jelzi, hogy ezek 2026. júliusi állapot szerintiek, és a keretrendszer-specifikációk a forrásdokumentációkból származnak (LangChain docs, Microsoft AutoGen docs, Google ADK docs).

## A szerző kapcsolódó tanácsai (cselekvési keret)

- **Mielőtt graphot építesz, urald a node-ot** — minden node loop, és a gyenge loopokra épített graph több helyen csődöl el egyszerre. A Loop Engineering kurzus a kiindulópont.
- **A legtöbb feladat továbbra is egyetlen jól határolt loop** — a graphot akkor érdemes bevezetni, ha egy loop ténylegesen erőltetett: a munka különböző specialitásokra oszlik, párhuzamos-then-join-t igényel, más modellt vagy tool-t kér lépésenként, vagy auditálható vezérlési folyamra van szükség.
- **A loop → graph migráció iteratív** — kezdj egy looppal, és csak akkor promotáld graphba, ha a loop tényleg csődöl. A cikk egy "Graph or Loop: How to Decide" döntési táblát ígér a testvér-guide-ban.

## Összegzés

A graph engineering **valódi és túlreklámozott** — és mindkettő egyszerre igaz. A valóban új három képesség: párhuzamos specializált node-ok tiszta kontextussal, fan-out / fan-in mint első osztályú move, és auditálható vezérlési folyamat. Az átnevezés rész: a topológia, a párhuzamosság, és az explicit vezérlés a LangGraph, AutoGen és ADK rendszerekben **mind a "graph engineering" buzzword előtt** szállítva voltak. A keret, ami túlélja a hype-ot: **a loop a graph speciális esete** (egy node önmagába visszacsatlakozó éllel). Nem graduálunk loopokból graphokba — komponálunk loopokat graphba, amikor és csakis amikor egy loop már nem elég, és a többlet promptsokban, állapot-sémákban és új failure mode-okban fizetődik. A rövid távú döntés a legtöbb feladatra: maradj loopnál, amíg a loop dolgozik.

## Forrás

- **Cikk:** [Graph Engineering vs Loop Engineering](https://www.aibuilderclub.com/blog/graph-engineering-vs-loop-engineering) — AI Builder Club, Shirley, 2026. július 20.
- **Kurzus kontextus:** AI Builder Club "Build AI Agents" kurzus 4.16 lecke
- **Kapcsolódó anyagok a cikkből:**
  - [Graph Engineering Guide (2026)](https://www.aibuilderclub.com/blog/) — a teljes stack
  - [Agent Graph vs Loop: When to Use Which](https://www.aibuilderclub.com/blog/) — döntési tábla és migrációs út
  - [Loop Engineering: Stop Writing Prompts, Start Writing Verifiers](https://www.aibuilderclub.com/blog/) — a graph alatti réteg
  - [Five Layers of AI Engineering](https://www.aibuilderclub.com/blog/) — Prompt / Context / Harness / Loop / Graph
- **Idézett keretrendszerek (prior art, mind a buzzword előtti):**
  - [LangGraph overview (LangChain docs)](https://langchain-ai.github.io/langgraph/) — StateGraph API, add_node, add_edge
  - [Microsoft AutoGen GraphFlow docs](https://microsoft.github.io/autogen/) — DiGraph (szekvenciális, párhuzamos, feltételes, loop flow)
  - [Google ADK docs](https://google.github.io/adk-docs/) — graph workflows, routing, multi-agent delegation, A2A protokoll
- **Idézett személyek (X / Twitter, 2026. július):** Peter Steinberger (@steipete, OpenClaw készítő), @svpino, @rohit4verse, @sairahul1, @VaibhavSisinty, @DavidKPiano (XState), @PawelHuryn, @RhysSullivan, @NathanFlurry
- **Feldolgozás:** Henky-pipeline (`article_from_blog`, fő agent self-write, 2026-07-24)