Bringing backend predictability to multi-agent systems
I've been hearing the phrase "graph engineering" thrown around a lot lately. I originally assumed it had something to do with knowledge graphs, or maybe GraphRAG. Not quite!
I sat down with Annie Wang and asked her to break it down from the ground up: what graph engineering is, and how it gives developers control over complex AI systems.
What's in the video
- Demystifying the terms: The actual differences between an agent harness, a loop, and a graph.
- A real-world example: Walking through an automated pull request (PR) review pipeline using fan-out, join, and conditional router patterns.
- What it isn't: Why graph engineering is fundamentally different from knowledge graphs and agent swarms.
- Shared state: How to orchestrate shared state and strict schemas using Google's Agent Development Kit (ADK).
The point that stuck with me is that graph engineering basically feels like modern backend architecture —like microservices— applied to agents. Instead of letting LLMs wander in a black-box loop and hoping for the best, you treat nodes with strict schemas and fan-out/join pipelines. It gives us back the predictability and debuggability that software engineers actually need.
(You can also follow along with the hands-on ADK Codelab).
Did your mental model of "graph engineering" match up? Are you still running straight loops for your agents, or have you started breaking them into graph patterns? Let me know in the comments!
Top comments (4)
My mental model was completely off coming in. I've been working on retrieval pipelines where "graph" basically means knowledge graph, so I'd expected this to go that direction. The microservices analogy is what clicked it into place for me - it's less about data relationships and more about making the agent's control flow something you can actually inspect and reason about. I'd really want to dig into how ADK handles a fan-out where one node silently fails, since that's been the crack in similar pipelines I've seen.
Same click here, on several subjects lately. Fifteen years of systems architecture, and I still catch myself arriving, after a day of thinking, at something that was a reflex in microservices four years ago. But what strikes me most is how similar the subjects turn out to be.
Mine matched the microservices comparison more than I expected. The part that clicks for me is treating it like backend structure you own instead of just hoping the model picks a good path. That's the whole thing.
Honestly I'm still on straight pipelines. Everything I build has a shape I already know going in, so I've never hit the point where I needed to branch or run stuff in parallel like this. But this is the first explanation that made me see where the line is. The day a job actually needs to split and come back together, that's when I'd reach for the graph instead of just piling on if-statements. Good to know the upgrade path before I need it.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.