Yes, It's a Graph. That's Why We Call It Flow Engineering.

Spend a week reading AI-agent job posts and Discord threads and you'll watch a role split harden into two words: flow engineer and graph engineer.

The taxonomy is real and it's useful, so let's state it fairly before we argue with it.

The split, stated honestly

The mental images are just as clean. The flow engineer sees a pipe:

Receive email → Extract invoice → Store in DB → Send confirmation

The graph engineer sees a topology whose path depends on state:

        ┌─→ Research Agent ─┐
User ───┤                   ├─→ Planner ─→ Executor
        └─→ Retrieval Agent ┘
                 ↑
                 └──── Memory

A fair rule of thumb has settled underneath it: flow engineering = workflow automation; graph engineering = agent orchestration and dynamic execution. Most "AI agent engineer" jobs today are actually flow engineering with a few graph concepts sprinkled in. Full graph engineering is the specialized end — the teams building agent platforms, not agent pipelines.

So the obvious question, the one people ask the moment they see the FloMorphic canvas: is this a flow tool or a graph tool?

The blunt answer

Ignore the branding. Look only at the runtime.

FloMorphic is a durable cyclic graph. Nodes and edges. State that persists. Cycles formed by an edge pointing backward plus a condition. Routing decided at each node from the current context. Multi-agent collaboration over a shared, long-lived state object. There is no loop node because a loop is just topology; there is no checkpoint feature because resumption is an execution primitive.

Every one of those is a graph-runtime concept. If you handed the technical description to an engineer with the product names stripped off, they'd say: this is a stateful cyclic graph with durable execution and a visual authoring layer — closer to LangGraph or a Temporal-plus-modeling system than to anything in the n8n column.

We're not going to argue with that. It's correct. The runtime is a graph.

So why does the discipline get called flow engineering? Because the graph is the substrate, and flow engineering is the practice. Those aren't competing answers to one question — they're answers to two different questions. And the fact that people expect them to be the same answer is the interesting part.

Why the split exists at all

Here's the claim: the flow-engineer / graph-engineer split is not a fact about the work. It's a fact about the tools. Two independent axes got welded together because no single tool spanned both.

Axis one — execution power: can the thing express a genuine cycle, or only a DAG? An agent is a loop (perceive, reason, act, check, repeat), so this axis is really "can it build agents, or only pipelines?"

Axis two — authoring surface: is the process a visual artifact a business-literate person can change, or is it code that only a programmer can touch and only a redeploy can ship?

Now plot the field:

The two populated corners are exactly the two roles. Flow engineer = the top-left tools taught you to think in DAGs you can draw. Graph engineer = the bottom-right tools required cycles and required you to be a programmer to get them, so the power and the code-only authoring arrived as a bundle.

The roles split because the tools forced a choice: you could have the expressive power of a cyclic graph, or you could have a process your team could see and change without a redeploy — not both. Two products, two skill sets, two hires.

The bottom-left quadrant — cyclic power with visual, no-redeploy authoring — was mostly empty. That emptiness is what made "graph engineer" sound like a separate, more specialized species. It wasn't the graph theory that made it specialized. It was that cycles only ever shipped inside a codebase.

FloMorphic lives in the empty quadrant

That empty corner is the entire design target.

FloMorphic gives you the graph-engineer's execution model — cyclic, stateful, dynamically-routed, multi-agent, durable over days — with the flow-engineer's authoring surface — a visual artifact you update, integrate, and extend without a redeploy. The graph is real all the way down; you just don't have to be a programmer holding a graph-theory textbook to author one.

That is why we don't accept the split as a description of our users. On FloMorphic:

• You get cycles without hand-rolling a state machine in Python — a backward edge and a condition.
• You get dynamic routing without wiring a router class — the node reads context and decides.
• You get durable long-running without adopting Temporal's programming model — resumption is built in.
• And you get all of it as a graph you can see and change in place, not a codebase you rebuild.

The "graph engineer" capabilities and the "flow engineer" ergonomics stop being a trade-off you resolve by hiring two people. That's not a marketing softening of the graph reality. It's the specific technical bet: that cyclic, durable graph execution does not have to be code-only — and once it isn't, the role split has nothing left to stand on.

Then why not just call it "graph engineering"?

Because naming a discipline after its data structure describes the wrong layer.

Databases run on B-trees; we don't call building web apps "B-tree engineering." The B-tree is how the substrate stores rows. What the developer is doing is modeling a domain. Same shape here. The durable cyclic graph is how the substrate executes an intelligent process. What the practitioner is doing is flow engineering — the discipline named in 2024, when structuring an LLM task as states and transitions took AlphaCodium from 19% to 44% on competitive-programming problems.

Flow engineering (in the LLM sense) means something precise: the human draws the corridor — the states, the transitions, the boundaries — and the model exercises bounded judgment inside it. Control is offloaded from the probabilistic model onto a predictable, visible layer. That's the what. The durable cyclic graph is the how the corridor is expressed and executed.

Call it "graph engineering" and you foreground the data structure and imply the barrier to entry the bottom-right quadrant taught everyone to expect. Call it "flow engineering" and you name the actual practice — drawing corridors for a bounded model — while the graph does its job underneath, the way B-trees do theirs. The name isn't hiding the graph. It's pointing at the layer the practitioner works on.

The split dissolves

So take the two role definitions and hold them up against FloMorphic one more time.

The flow engineer's world — visual, changeable, owned by people who understand the process — is the authoring surface. The graph engineer's world — cyclic, stateful, dynamically-routed, durable — is the execution model. In every existing tool you pick one column and inherit its limits. FloMorphic's whole reason to exist is that you shouldn't have to.

A governed agent is a flow all the way down, and a flow with real loops is a graph all the way down. They were never two things. They looked like two things because the tools that gave you one couldn't give you the other, and the job market dutifully split into two roles to match.

So: is FloMorphic a flow tool or a graph tool? It's a durable cyclic graph you practice as flow engineering — the execution model of the graph engineer, in the hands of a flow engineer, with no redeploy in between.

The graph is the honest answer to what is it built on. Flow engineering is the honest answer to what are you doing on it. Getting to keep both answers, without hiring two people to hold them, is the point.

This is a companion to Flow Engineering Is an Architecture, Not a Prompting Trick, which lays out the two hard requirements — real loops and durable long-running — and where FloMorphic sits against n8n, heym, LangGraph, and Temporal. New here? Start with The Model Proposes, the Graph Decides, then Pausing Is Easy, Resuming Is the Hard Part for the durability the whole argument rests on.