glossary · The process

Graph engineering

definition

Graph engineering, in ConvOps, is the method of designing a process as a graph of small workflows that an AI agent walks one step at a time, behind one entry point, instead of writing the whole process into one large prompt.

in one line: Small workflows behind one door, walked one step at a time.

in context

Where does graph engineering fit?

The knowledge grows. The prompt does not. One door, detours that return, loops that go back. The agent only ever holds one step.

routerone door
which exit?
sub-workflowruns, returns
reviewfix and again
done
two ways to say it

What is graph engineering, in plain words?

Same idea at two depths: the plain version, then what the engine actually does.

Instead of one long instruction file, the process is a set of short workflows. A lesson becomes an edit to one step.

Others use the term for designing agent teams. Here it means the shape of the process.

for engineers

Workflows are ordered steps. Decisions invoke sub-workflows; resume_at returns to the next or an earlier step.

No goto. Steps in one workflow run one after another; parallel work is child tasks.

the longer answer

Why does graph engineering matter?

The term is used in more than one sense. Several authors use "graph engineering" for multi-agent topology design: which agents exist, what each one owns, how work is split between them and where a person signs off. Others use it near knowledge graphs. This entry defines the sense ConvOps uses, which is about the shape of the process the agent follows, not the shape of the agent team.

The idea starts from a common failure. Teams teach an AI agent their process by adding to an instruction file. Every incident adds a paragraph, the file grows, the agent skims more of it, and nobody can say which rule shaped a given change. Graph engineering moves the process out of prose and into structure. Each workflow is short and readable. A router takes new work and sends it down one exit. Decisions detour into sub-workflows that come back. Fix loops send failed work back to an earlier step. Shared fragments keep common steps in one place. The agent never holds the whole graph, only the step it is on.

The result is that knowledge grows while the prompt does not. A lesson from an incident becomes an edit to one step, a new fragment, or a new branch, and every future run follows it.

in convops

How does graph engineering work in ConvOps?

In ConvOps, the graph is held by the engine and walked by your own AI session over MCP. A workflow is an ordered list of steps; the only ways off the line are detours that return and loops that go back to a step the workflow names. There is no arbitrary jump, so anyone can read a workflow and know where a run can go. Steps inside one workflow run one after another; parallel work is expressed as child tasks. For the full guide, with examples and the disambiguation of the term, read what is graph engineering; for how the engine implements it, see graph engineering in ConvOps.

questions

What do people ask about graph engineering?

What is the difference between graph engineering and prompt engineering?

Prompt engineering improves the text a model reads. Graph engineering moves the process out of that text into a structure of steps, decisions, detours and loops that an engine holds, so the agent sees one step at a time and the prompt stays short.

Is graph engineering the same as multi-agent design?

Some authors use the term that way, for designing agent teams. In the sense ConvOps uses, it means designing the shape of the process an agent follows: workflows, routers, sub-workflows, fix loops and fragments.

Do steps in a graph-engineered workflow run in parallel?

Not in ConvOps. Steps in one workflow run one after another. Parallel work is expressed as child tasks, each with its own workflow, and the parent waits until they are complete.