Graph Engineering: When AI Agents Need Explicit Topology

Here's a question that sounds simple but ruins AI agent projects: when the agent finishes step one, what's allowed to happen next?

If the answer is "the model decides," you have an agent. If the answer is "the workflow topology decides," you have a graph. And the difference between the two is the difference between a system that occasionally does something brilliant and a system that reliably does the right thing every time.

Graph engineering is the newest of the three agent architecture disciplines — harness, loop, graph — and it's the one people understand least. Partly because "graph" is an overloaded term in AI (knowledge graphs exist and are completely different), and partly because the frameworks are still maturing. But the core idea is straightforward: instead of letting the model decide what to do next, you define the allowed execution paths as explicit nodes and edges in a directed graph.

What a Graph Actually Is

In agent architecture, a graph is a state machine. Each node is a unit of work — an LLM call, a deterministic function, a specialist agent, or a human review step. Each edge defines what can happen after that node: sequence, conditional branching, parallel fan-out, joins, or controlled cycles. State flows through the graph, and the topology makes the control flow inspectable and testable.

LangGraph — the dominant framework in this space, now at v1.0 — describes itself as "low-level orchestration infrastructure for long-running, stateful agents, with durable execution, state, and human-in-the-loop control." Microsoft's AutoGen has GraphFlow, which runs a directed graph topologically with the same primitives. Both frameworks converged on the same answer: when you need exact control over agent behavior, make the paths explicit.

A graph in code looks like this:

graph = StateGraph(State)
graph.add_node("research", research_agent)
graph.add_node("draft", draft_agent)
graph.add_node("review", review_agent)
graph.add_edge("research", "draft")
graph.add_conditional_edges("draft", should_revise, {True: "review", False: END})
graph.add_edge("review", "draft")  # revision loop back

Research feeds into draft. Draft either goes to review or ends. Review loops back to draft if revisions are needed. Every path is explicit. There's no "the model decides to do something unexpected" — the topology constrains what's possible.

When You Actually Need a Graph

LangChain's own guidance, from their three-year retrospective on graph engineering, is blunt: "In some cases, you don't want to represent the system as a graph but rather just use an agent harness. Generic deep research is a good example." Not every problem needs a graph. In fact, most don't.

You need a graph when the process has meaningful branches, parallel work, approvals, recovery paths, or multiple specialist agents. You don't need a graph when the job is "give one agent three tools and let it work."

A practical decision framework: start with a harness. Add a loop when you need quality control. Only add a graph when the workflow forces your hand — when you have multiple specialist agents that need coordination, when branches depend on intermediate results, when certain steps must happen in parallel and then join, when human approval gates are required at specific points.

The mistake teams make is building a graph before understanding the work. They translate a business process into dozens of nodes before they've observed how a capable agent actually solves the problem. The result is a brittle, over-engineered system that's worse than a simple agent loop. LangChain's advice: start with traces from a simpler harness, observe the stable paths the agent naturally takes, then formalize those paths into a graph.

What Graph Engineers Actually Decide

Building a production agent graph involves six specific decisions:

Node boundaries — which work belongs in a deterministic function (regex, API call, database query), which needs an LLM call, which needs a specialist agent, and which needs a human. This is where most graph design goes wrong. People put LLM calls where deterministic functions would be faster, cheaper, and more reliable.

State schema — what each node can read or update, and how parallel updates merge. Typed state prevents the agent from accidentally corrupting shared data. LangGraph uses typed state classes; AutoGen uses a similar pattern. This is the "typed shared memory" that makes multi-agent coordination possible without race conditions.

Routing conditions — which evidence sends work forward, backward, sideways, or to escalation. The routing function is the brain of the graph. It's where you encode "if the code review found critical bugs, send back to coding; if it found minor issues, auto-fix and proceed; if it found nothing, ship."

Concurrency — what can run in parallel, what must join, and what shared resources need coordination. Research and outline can happen in parallel. Draft and review cannot. The graph makes these dependencies explicit instead of hoping the agent figures out the sequencing.

Cycles and exits — where retries are legal, how many are allowed, and what makes the cycle safe. A revision loop that can repeat forever is a cost bomb. A revision loop with a maximum of three attempts and an escalation path is engineering.

Durability — where checkpoints occur and how execution resumes after interruption. LangGraph's checkpointing is one of its strongest features. If a long-running graph is interrupted (server restart, timeout, human pause), it resumes from the last checkpoint rather than starting over.

How Graphs Fit With Harnesses and Loops

The three layers nest. The graph runs inside the harness. One or more loops live inside the graph. The harness supplies the state, tools, and evaluators those loops need.

Consider a research-and-publishing agent. The graph defines the workflow: research node → draft node → fact-check node → review node → publish node, with a conditional edge from review back to draft if revisions are needed. Inside each node, the agent loop runs — the model calls tools, reads sources, writes content. The harness provides the tools (browser, file system, API access), the memory (what's been researched so far), and the safety (don't publish without approval).

The categories overlap because software layers overlap, but each gives the team a different lever to pull when the system fails. If the agent is hallucinating tool calls, that's a harness problem. If it's producing work that doesn't meet quality bar, that's a loop problem. If work is going to the wrong agent at the wrong time, that's a graph problem.

The Production Reality

Graph engineering is powerful, but it has a real cost: ceremony. A graph is more code, more configuration, more moving parts than a simple agent. It's harder to change — adding a new node means updating edges, state schemas, and routing logic. It can freeze assumptions too early, encoding a workflow that turns out to be wrong.

LangGraph's production users — companies like Klarna and Replit — adopted graphs when their agent workflows reached a complexity where ad-hoc code became unmaintainable. Multi-step approval processes, parallel research across different data sources, conditional routing based on intermediate results — these are problems where explicit topology beats implicit model decisions.

But the discipline required to maintain a graph is real. If your team can't answer "which paths must be deterministic, where can work run in parallel, which state is shared, and where are the human gates" — you don't have a graph engineering problem yet. You have an observation problem. Go watch what your agent actually does. Then decide which paths need to be formalized.

The clean mental model for all three layers: harness builds the environment, loop engineers the feedback, graph makes the flow explicit. None of them is a substitute for the others. A beautiful graph won't save a broken harness. A perfect harness is a money pit without evidence-based loops. Carefully crafted loops are impossible to operate when branching and parallelism live in ad-hoc code.

Design all three together, and you get reliable agent systems. Skip any layer, and you get a demo that doesn't survive production.

---

CopperRiver handles the harness layer for you — browser, terminal, files, memory, scheduling — so you can focus on loops and graphs. Runs on open-source models locally. Plans from $9/mo. Check it out.