The Frameworks That Were Doing “Graph Engineering” Before It Had a Name

On July 17, Peter Steinberger, the developer behind OpenClaw, posted a question that landed harder than most tweets do: “Are we still talking loops or did we shift to graphs yet?”

And even though there was no new release or updates around the time of the tweet, within a day it had over a thousand replies and “Graph engineering” was already circulating as the successor to “loop engineering,” a term that had only been dominant since June.

If that sentence made you tired, you’re tracking the pattern correctly. In the last eighteen months, the same underlying work of getting AI systems to behave reliably has been renamed four times: prompt engineering, then context engineering, then harness engineering, then loop engineering, and now graph engineering.

Some of these terms describe genuinely different problems. Others describe the same problem from a slightly different angle. Worth sorting out which is which before adopting the fifth one.

Five Terms, Five Definitions

Here’s what each one actually covers, so you can judge the distance between them yourself instead of taking anyone’s word for it.

• Prompt engineering is designing the instructions you give a model in a single exchange. You write a prompt, get a response, evaluate it, and iterate.
• Context engineering is managing everything the model knows at inference time beyond the prompt itself: retrieved documents, memory, tool definitions, session history. Prompt engineering addresses what you say to the model. Context engineering addresses what it knows when it says something back.
• Harness engineering is the structural layer around an agent: the constraints it can’t override, the verification gates it has to pass, the state that persists across sessions. A good prompt won’t stop an agent from rewriting your entire codebase if nothing architecturally prevents it.
• Loop engineering is designing the discover-plan-execute-verify cycle a single agent runs on repeat. It decides what triggers each step, what counts as done, and what happens when it fails. Most production systems combine several loop engineering patterns rather than relying on just one.
• And now Graph engineering which is described as wiring multiple agents, each running its own loop, together through nodes, edges, and shared state, instead of relying on one agent to handle everything sequentially.

Lay these five out next to each other and the picture gets clearer. Prompt, context, and harness engineering describe genuinely different layers of the same single-agent problem: what you say, what it knows, and what it’s allowed to do.

Loop and graph engineering sit much closer together. A graph is just what you get when a single loop isn’t enough and you need several of them coordinating.

Graph Have Always Been Here

The idea that AI systems benefit from being modeled as graphs rather than single sequential processes isn’t new to July 2026, or even to agent orchestration. Graph RAG has used knowledge graphs, structured nodes and edges representing entities and their relationships, to get multi-hop reasoning that flat text retrieval can’t match. It’s been doing that for longer than the loop engineering cycle it followed.

That’s the same nodes-and-edges thinking, just applied to retrieval instead of orchestration. Whenever an AI system needs to represent more than one path through a problem, someone reaches for a graph.

Agent orchestration catching up to that is expected, not novel.

The Frameworks That Were Already Doing Graph Engineering

If “graph engineering” describes agents as nodes connected by edges over shared state, here’s where that’s been shipping in production for a while.

LangGraph

• What it is: A low-level orchestration framework from LangChain for building stateful, long-running agents as an explicit graph. It was in active use well before “graph engineering” became a phrase, and now leads the space in enterprise adoption with tens of millions of monthly downloads.
• Orchestration model: You define a StateGraph, add nodes, and wire them together with conditional edges. Agents, tools, and checkpoints are all nodes; transitions between them are edges you define yourself.
• State handling: Built-in checkpointing with time-travel debugging, so you can roll back to an earlier point in the execution and replay from there.
• Best for: Complex, stateful Python workflows that need explicit control over branching, retries, and human-in-the-loop steps.

Microsoft Agent Framework

• What it is: The unified successor to AutoGen and Semantic Kernel, reaching general availability in April 2026.
• Orchestration model: Combines AutoGen’s multi-agent conversation abstractions with Semantic Kernel’s enterprise tooling, and adds graph-based workflows for explicit control over multi-agent execution paths.
• State handling: Session-based state management, middleware, telemetry, and type safety carried over from Semantic Kernel.
• Best for: Teams already on the Microsoft stack who want graph-based workflows with Python and .NET runtimes.

Google ADK

• What it is: Google’s Agent Development Kit, built for multimodal and Google Cloud-native agent stacks. Its standout feature is native support for the A2A (Agent-to-Agent) protocol, which lets an ADK agent discover and invoke an agent built in LangGraph or CrewAI through a standardized task interface. That’s “graph” thinking extending across framework boundaries, not just within one.
• Orchestration model: A hierarchical agent tree, where a root agent delegates to sub-agents, which can in turn delegate further down the chain.
• State handling: Session state with pluggable backends, tightly integrated with Vertex AI and Gemini models.
• Best for: GCP-native teams, and any system where agents built on different frameworks need to talk to each other.

CrewAI

• What it is: A standalone multi-agent orchestration framework built around a role-based mental model, where each agent has a defined persona, a set of tools, and a specific task. The fastest path from idea to a working multi-agent prototype, with setup time measured in hours, not days.
• Orchestration model: Role-based crews with configurable process types governing how tasks pass between agents, rather than a literal node-and-edge diagram. The underlying shape is the same: agents as nodes, process flow as edges, task outputs as shared state.
• State handling: Task outputs passed sequentially between agents.
• Best for: Fast prototyping and role-based multi-agent systems where you want a working demo quickly.

LlamaIndex Workflows

• What it is: An event-driven orchestration layer built for document-heavy, data-intensive pipelines.
• Purpose-built for indexing and retrieval workflows since before the current agent-orchestration naming cycle.
• Orchestration model: Steps trigger conditionally based on what came before, rather than following one fixed sequence, which makes the “graph” shaped more by the data than by a predefined org chart of agents.
• State handling: Context passed along events as they fire, suited to retrieval-heavy and RAG-style pipelines.
• Best for: Data-centric applications where document ingestion, retrieval, and transformation steps need conditional routing.

OpenAI Agents SDK

• What it is: OpenAI’s production-grade toolkit for multi-agent coordination, released as the successor to the experimental Swarm framework. Clean and predictable for OpenAI-only agent chains, though model-locked with no bring-your-own-model support.
• Orchestration model: Explicit handoffs. Agent A finishes its part and hands off to Agent B, passing context through the transition. A lighter edge model than a full graph, closer to a chain than a network.
• State handling: Context variables that are ephemeral by default, with no built-in checkpointing for long-running workflows.
• Best for: Teams fully on the OpenAI stack who want a lightweight handoff model rather than a full graph, and a useful reminder that not every multi-agent system needs one.

What This Means for Your Stack

If you’re already using any of the frameworks above, you were already doing what’s being called “graph engineering” this month. The label doesn’t change your architecture.

What it can do is give you cleaner language to explain that architecture to your team, or to someone hiring for it.

The more useful question isn’t whether to adopt the newest term. It’s whether your system actually needs the coordination a graph provides: multiple agents, each running its own loop, with real dependencies between them that a single agent couldn’t handle sequentially.

If the answer is yes, the frameworks above have had years to work out the hard parts. If the answer is no, a well-built loop is still the right tool, whatever the timeline decides to call it next.

FAQ

Is graph engineering different from multi-agent orchestration? Not meaningfully. “Multi-agent orchestration” is the longer-standing term for coordinating multiple agents through defined routing and shared state. “Graph engineering” describes the same practice using nodes-and-edges language.

Do I need to switch from loops to graphs? Only if a single agent’s loop can’t handle the dependencies in your task. Most workflows don’t need a graph. Reach for one when you have genuinely parallel or branching work that one agent running sequentially would bottleneck.

Which framework should I start with? LangGraph is the most common default for complex, stateful Python workflows. CrewAI is faster to prototype with if you want a working multi-agent system in an afternoon. Google ADK is the strongest choice if you need agents built in different frameworks to talk to each other via A2A.

Is this just LangGraph with a new name? Largely, yes, for the mechanics. LangGraph’s own documentation describes exactly the node/edge/state model that “graph engineering” is now being used to describe