You had barely digested prompt engineering (phrasing your request well), then context engineering (choosing well what you show the model), and now agent developers have a new word for you: graph engineering. Promise, this is not just another buzzword. It’s actually the oldest idea in software engineering applied to AI: draw the plan before you build. In chat, agent, loop, the whole difference fit in one question: who decides the next step? Graph engineering gives an unexpected answer: both of you. You draw the allowed routes; the model chooses at the junctions. Let’s take it apart together. You’ll see: it’s not rocket science.

The taxi, the funicular and the train

Until now, to put an LLM to work on a multi-step task, you had two options:

  • The fixed workflow is the funicular. One track, one direction: step 1, step 2, step 3. Predictable, cheap… and rigid. At the first unexpected situation, everybody off.
  • The free agent is the all-terrain taxi. You give the destination, it figures things out: its agentic loop decides every step along the way. Wonderful in unknown territory. But sometimes it takes surprising detours, the meter keeps running, and nobody knows in advance which way it will go.

Between the two sits the railway network: stations where the work gets done, tracks connecting them, and switches where one line is chosen over another. The train never leaves the rails (you decided the possible routes), but the exact journey depends on what happens along the way. Designing that network, station by station, switch by switch: that’s graph engineering. Keep this image in mind, we’re riding it to the last stop.

Four words to know: station, track, switch, waybill

An agent graph is four parts, not one more:

  • The node is the station. A step where work gets done. Inside, anything you want: a model call, plain old code, a tool call, or even a small complete agent locked inside the station.
  • The edge is the track. It says what comes next: when the “classify” station is done, head to the “search” station.
  • The conditional edge is the switch. Depending on the result, the train takes track A or track B. Who operates the switch? Sometimes three lines of code (a plain if), sometimes the model itself. It’s the only place where the model “chooses”, and only among the tracks you laid.
  • The state is the waybill. A document that travels with the train. Every station reads it, does its job, and fills in its part: the customer’s question, the detected category, the retrieved excerpts, the draft answer, the review verdict. At arrival, the waybill holds the whole story of the journey.

A concrete example: customer support

Let’s draw the network of a support agent:

flowchart TD
    Q([Customer question]) --> C{Classify}
    C -->|billing| F[Search the terms]
    C -->|technical| T[Search the docs]
    C -->|off-topic| H[Hand over to a human]
    F --> R[Draft the answer]
    T --> R
    R --> V{Review}
    V -->|needs work| R
    V -->|approved| E([Send])

Follow the train: the question pulls into the “classify” station, where a small, cheap model sorts it (that’s simply the routing pattern). The switch sends it to the right document search (classic RAG), then to the “draft” station where the big model writes the answer. The “review” station rereads against explicit criteria: incomplete answer? The train goes back for another try (two at most, then a human takes over). And the off-topic question never even visited the big model: straight track to a human.

Nothing magical: every station is small, specialized, and fills in its box on the waybill.

A real network has loops

On paper, we picture a well-behaved org chart flowing top to bottom. In production, that’s wrong: the graphs that work are full of loops. The “needs work” return in the diagram above is the evaluator-optimizer duo: one station produces, one station critiques, and it cycles until approval (or the retry cap). Another classic loop: the “ask the human for a clarification” station, from which the train departs again with a richer waybill.

Don’t take our word for it: the authors of LangGraph, the tool that popularized the term (65+ million downloads a month), insist after three years of practice that production graphs are never straight lines. Retrying, validating, asking again: loops are the rule, not the exception. On the Microsoft side, the Agent Framework calls the same idea “workflows”; the vocabulary varies, the network map remains.

Why go to all this trouble?

Against the all-terrain taxi, the railway has four serious arguments:

  1. Predictability. The train doesn’t leave the rails. A free agent can “forget” to review before sending; here that’s impossible, the “review” station sits on the track, the train passes through it, period.
  2. Testability. You test station by station, with real evals: does classification land right on 50 known cases? Does review catch the bad drafts? Testing a taxi that changes route on every ride is much harder.
  3. Cost. Each station picks its model. A cheap mini-model at the classification switch, the big model only where it earns its keep (the drafting). Over thousands of tickets, the difference shows on the token bill.
  4. Safety. Permissions are set per station. The “send the email” station requires a human sign-off; the “search the docs” station is read-only. Guardrails poured into the concrete of the network, not into the good intentions of a prompt.

The word of honesty

Graph engineering is not the answer to everything, and better to know it before laying rails everywhere:

  • If the route is fully known in advance (no choice along the way), you don’t need a graph: a simple sequence of calls (prompt chaining) will do. You don’t build a switching yard for a funicular.
  • If the task is genuinely exploratory (debugging an unknown problem, open-ended research), the taxi remains better: you can’t lay rails toward a destination you don’t know. That’s why coding agents remain largely “free”.
  • The graph shines in between: when the structure of the work is known (classify, search, draft, review) but not the exact path of each request.
  • The classic trap: over-engineering. Forty stations for a three-step task is an unmanageable network. Start with three stations; add a switch the day a real problem calls for it.

In summary

Graph element The image The role
Node the station a step that does work (code, LLM, tool, agent)
Edge the track what comes next
Conditional edge the switch picking the line based on the result
State the waybill the document stations pass along and fill in
The whole graph the network map every route you allow
  • The genealogy is logical: prompt engineering governs what you say, context engineering what you show, graph engineering the routes you allow.
  • The model decides at the switches, never about the rails: autonomy exactly where it’s useful.
  • Funicular when everything is known, taxi when nothing is, railway in between.
  • Our pattern collection (routing, prompt chaining, evaluator-optimizer…) is really a catalog of ready-to-lay pieces of network.

Next time someone shows you an “enterprise AI agent”, ask to see the network map. Stations, tracks, switches, a waybill: if you can read a metro map, you can read an agent graph. It’s not rocket science.