I just published ** Graph Engineering for Agentic AI Systems**, and I am honestly buzzing about it. Fourteen chapters, 364 pages, and a clear craft for declaring what graph engineering is and how to practice it: from topology you own, through production and security, to what still matters after the hype fades. This is the field manual I wished I had when agent demos turned into systems with money on the line, side effects in the wild, and humans waiting on irreversible steps. Grab the Kindle edition
Before you buy, watch the high-level overview with screenshots of pages from Chapter 1 on YouTube at ▶https://youtu.be/wRrwEJYvrX8, and download the buyer's guide at this Google Drive link.
Most agent systems get their shape by accident. A prompt. Then a tool. Then a retry. Then a second agent because the first one got long. Nobody writes the topology down. It exists either way. You just do not own it. This book exists so you can own it: the specialized nodes that earn their keep, the edges that are legal, the shared state that travels with the run, the places work can fan out and join, and the gates that sit on every irreversible step.
While you are here, subscribe to my YouTube channel Agentic AI Signal for the latest on agentic AI: https://www.youtube.com/@AgenticAISignal/shorts.
Below is a full tour of every chapter. I wrote each one for a different failure mode I keep seeing in the past.
Chapter 1 names the job before it names the week. Graph engineering, as I use it, is the work of declaring how an agent system is allowed to run. You pick the specialized nodes, the edges that are legal, the shared state that travels with the run, the places work can fan out and join, and the gates that sit on irreversible steps. A loop is that picture with one worker and an edge back to itself. You add structure when one cycle cannot hold the job.
The question that runs through the whole book starts here: did you design that structure, or did you allow it to happen? Allowed-to-happen is how most demos get built. Designing too soon is the other failure: a five-node graph for "summarize this PDF." Chapter 1 also frames the July 2026 "loops versus graphs" noise as a naming event, not a new runtime. LangGraph, AutoGen GraphFlow, and ADK already asked you for nodes, edges, and state. The name did not invent the skill. The chapter leaves you with a sharper eye for costumes, and a definition you can defend in a design review.
One English word keeps wrecking design reviews. Chapter 2 forces you to hold three objects apart before you argue about any of them.
An execution graph is a topology of work: agents, tools, evaluators, and humans on the nodes, control flow on the edges, shared run state in the middle. A knowledge or memory graph is a topology of facts: entities as nodes, typed and provenance-bearing relations as edges. A learned computational graph is a third object entirely: GNNs, graph transformers, and causal graphs trained offline, whose weights are not a runtime. LangGraph, ADK Workflow Runtime, and AutoGen GraphFlow live in the first family. GraphRAG, Neo4j, and similar stores live in the second.
The book uses notation on purpose: G_A
for the execution graph, G_K
for the knowledge graph. When someone says "we are doing graphs," the room should know which object is on the whiteboard. Do not take a GraphRAG course and think you learned LangGraph. Chapter 2 exists to make that category error expensive to ignore.
Chapter 3 puts graph topology inside a wider craft. Prompt, context, harness, loop, graph, and memory are siblings, not a career ladder of replacements. I use harness engineering for the paradigm under them: the shift from deterministic software specified in advance to non-deterministic agentic systems constrained, verified, and steered at runtime.
Graph engineering, in this frame, is topology. The other crafts get space where they constrain topology. You see why the orchestrator is not magic, why the spine under the nodes matters, and how harness choices either protect irreversible steps or quietly erase your design. If Chapter 1 is the why, Chapter 3 is the stack view that keeps graph talk from floating above the runtime you actually operate.
Chapter 4 opens the machine. Nodes, edges, shared state, reducers, checkpointers, interrupts, fan-out and join, human gates, and the types that make a handoff real. An edge is a permission about the run: after this node, that node may fire. An edge is not a business fact about the world. If you catch yourself storing world knowledge as orchestrator edges, you have started to smuggle a knowledge graph into an execution graph, and you will regret it the first time two runs disagree.
Shared run state is a schema, not a prompt. After this chapter, "add another agent" stops being a strategy and becomes a claim about vertices and legal transitions. Chapter 4 is the anatomy lesson you need before you argue about frameworks, because frameworks only make sense once you can name the parts they are implementing.
A graph book that never refuses a graph is selling costumes. Chapter 5 is the refusal chapter: master the loop first, and split only when the work forces your hand. If you cannot name the handoff, you do not have a graph yet. You have a feeling.
The chapter carries hard evidence and industry warnings: token multiples that turn a lift into a budget problem, sequential stop rules for work that does not parallelize, and multi-agent failure modes where parallel workers do not share context. The point is not anti-structure. The point is anti-theater. You leave with a diagnostic you can print, take into a review, and use without apologizing. Most tasks never become topology problems. That is not conservatism for its own sake. It is cost, context, and the operator.
Once refusal fails honestly, you need a language for what to build. Chapter 6 is that pattern language. A small set of topologies covers almost all of what you will ship: sequential pipelines, supervisor trees, orchestrator-worker fan-out, parallel map-reduce over tools, human gates on irreversible actions, and recovery after partial failure.
Each pattern is a loop that outgrew itself, then a graph, then the failure if you skip the verifier or share a writer context with the checker. Multi-agent material folds into those patterns. It does not get its own religion. If a box does not pay for itself in handoffs you can name, it does not belong on the whiteboard. Chapter 5 gave permission to refuse. Chapter 6 is the language you speak after you have failed the refusal for the right reasons.
Chapter 7 is ruthlessly practical. You walk what actually runs under shipping substrates such as LangGraph, AutoGen GraphFlow, and ADK's Workflow Runtime: state, persistence, interrupts, streaming, recursion limits, and the footguns that only show up when someone has to operate the thing at 2 a.m.
The goal is portable judgment across vendors, not a fan club for one logo. You should finish able to map your topology onto a framework without letting the framework invent your topology for you. If Chapter 4 gave you anatomy, Chapter 7 shows how that anatomy appears in the tools teams are already choosing.
Durable memory is not a synonym for orchestration. Chapter 8 treats the knowledge graph as a first-class design object: entities, relations, provenance, identity over time, and what must not be overwritten by the next model turn.
GraphRAG appears as a retrieval pattern over remembered facts, not as "doing graphs." You can run GraphRAG inside a G_A
node. That does not make the orchestrator a knowledge graph, and it does not make community detection a routing edge. You learn the boundary between runtime control flow and long-lived structure that survives a single session, which is exactly where many agent stacks quietly corrupt themselves. Chapter 2 separated the objects. Chapter 8 builds the memory object with enough care that you stop confusing it with the runtime.
A graph that works in a notebook becomes a distributed system the moment it has side effects, money, and a human waiting. Chapter 9 is operations on G_A
, not a generic MLOps chapter with the noun swapped.
A production graph is a long-running program with shared mutable state, partial failure, human latency, and a cost function that is both stochastic and multiplicative. The notebook hid that. Most of the bugs you will spend the next year on are not model bugs. They are state bugs, reducer bugs, resume bugs, budget bugs, and versioning bugs. The model takes the blame because it talks. The model is rarely the cause. Design is a drawing. Operations is a ledger. If you only read one chapter after the foundations, make it this one before you scale autonomy.
Chapter 10 exists so you inherit the computer science instead of reinventing it. The topology is not new. State machines, actors, and scheduling intuitions already earned decades of scars. What is new is the payload: nodes that are probabilistic language-model agents.
The useful question is not whether graph engineering invented graphs. It did not. The useful question is what stays true when a node samples among legal successors, burns tokens, and fails in ways that look like judgment. You get enough formal clarity to argue in a room full of skeptics without drowning in theory for its own sake. The payoff is confidence: you can defend topology with computer science, not vibes.
A loop that can be prompt-injected is a confused worker. A graph that can be prompt-injected is an organization whose org chart is the exploit. Chapter 11 does not invent a new class of model attack. It tells you the execution graph is already a security artifact.
The vertex set is who may act. The edge set is who may walk which edge. A missing edge is a control that no amount of prompt hygiene can replace. Reachability is the proof that a human-approval node cannot be walked around. Blast radius is the cut of the graph a compromised node can poison through shared state. Every node runs as someone: human, service, agent, or vendor runtime. Put principal on the vertex and authorization stops being philosophy. The hard line I defend: topology that needs a live LLM to be secure is not secure.
Chapter 2 put a third object in a room and closed the door. Chapter 12 opens that door on purpose. The object is a learned computational graph: a GNN, a graph transformer, a causal graph estimated from data. Vertices carry features. Edges carry relations or estimated influences. The load-bearing extra is weights fit on examples.
Learned graphs are not the runtime. That object is not an orchestrator. It is not a store of facts. It is not what the industry meant by graph engineering in the naming wave. Chapter 12 walks the real intersections with agentic graph engineering, and it names the non-intersection that keeps getting sold as if it were a method. This chapter protects your design review from a category collapse that wastes quarters.
Pretty demos are not evidence. Chapter 13 exists to test walks, not only strings. Prompt evals score a completion. Graph evals score a path. If you only grade the final paragraph, you will ship a diamond that arrives at a pretty brief by skipping the reviewer, retrying past the cap, or applying a patch the human never saw.
You get deterministic checks where topology can prove properties, probabilistic evals where models force uncertainty, and gates that belong on irreversible steps. Chapter 9 named these concerns as an operations checklist. Chapter 13 gives you the method, including runnable harness thinking on scout-review style graphs. If Chapter 9 is how graphs fail in ops, Chapter 13 is how you catch those failures before customers do.
Chapter 14 is the close. I wrote it so you keep the graph after the name fades. The label "graph engineering" may not survive the hype cycle that produced it. The systems that last will share one trait: their structure is explicit, versioned, and owned.
Prompt engineering, context engineering, harness engineering, and graph engineering all leave residue. Keep the residue that is topology you can version and operate. Throw away the title the day the title becomes a tax. The artifact you own is the topology. Draw it, or it will draw itself.
Teams are already doing this work under other names. Job posts ask for graph engineers. Slides show five boxes and get approved for jobs one agent was already doing. Frameworks already ask you for nodes, edges, and state. The missing piece is ownership: a clear craft for declaring legal paths, shared state, and irreversible gates before the system invents them for you.
That is what Graph Engineering for Agentic AI Systems is. Excited is not empty marketing here. I am excited because the book gives you vocabulary, refusal criteria, patterns, framework judgment, memory design, production ops, CS grounding, security checks, and verification discipline in one continuous argument from Chapter 1 through Chapter 14.
Start with the Chapter 1 walkthrough video at ▶https://youtu.be/wRrwEJYvrX8, skim the buyer's guide at this Google Drive link, then grab the Kindle or paperback. And subscribe to Agentic AI Signal so you catch the next agentic AI signal before it shows up as an unowned topology in your stack.
