Three concepts the term 'graph engineering' lumps together
Graph engineering is confusing because three things get lumped under one word: control graphs (making agents reliable through SOPs), knowledge graphs (retrieval based on entity relationships — an unrelated concept) and graphs of loops (coordinating multiple loops, still unsolved). The one that is useful in practice is the control graph. Behind it is a shift from people prompting directly to orchestrators that direct trigger-based loops and teams of agents, and the remark that Boris, who built Claude Code, runs thousands of agents overnight conveys the scale. A graph is made of nodes, edges and state, but what is new is that nodes have gone from scripts, through LLMs, to being agents themselves; for implementation, both code graphs such as LangGraph and LLM graphs in which the model reads an SOP as a skill are valid. Four principles make a checklist: split the checker and the planner into separate nodes, handle routine data processing in code, define input/output boundaries for each node, and manage state with Markdown files and append-only logs.
Key points
- Control graphs, knowledge graphs and graphs of loops are different concepts; the practical core is the control graph
- What's new is that nodes became agents; code graphs and LLM graphs are both valid
- Four design principles: separate nodes (checker, planner), use code, I/O boundaries, state management
- Breaking tasks down isn't enough — the loop runs only when agents are given testing tools
This is a note: my own write-up after reading several sources. It has no source link; events checked against a source are kept as records.