Prompt, loop and graph engineering: three ways to get work out of a model
Three practices have grown up around getting reliable work out of a language model, and they are often confused because each one grew out of the last. Prompt engineering works on the text of a single call. Loop engineering works on the control flow around many calls. Graph engineering works on the shape of the whole job, written down as a graph before anything runs. This guide says what each one is, what it is good for, and how to tell which one your work needs.
Prompt engineering: the text of one call
Prompt engineering is the craft of the input to a single model call: the instructions, the examples, the format you ask for, the order you put things in. It exists because models are sensitive to phrasing in ways a person is not, and a well-built prompt turns an unreliable answer into a reliable one without changing the model.
Its unit of work is one call. That is its strength, because one call is easy to test, and its limit, because most real jobs are not one call. A prompt can ask for the extraction and the classification and the description all at once, and it will do all three worse than three prompts that each do one. The first thing most teams learn after prompt engineering is that the job has steps.
Loop engineering: the control flow around calls
Once a job has steps, something has to run them. Loop engineering is the practice of arranging calls in code: call the model, check the answer, retry if it failed, call a tool with the result, feed that into the next call, stop when a condition is met. Agents are loop engineering with the model choosing the next step. The agent frameworks are its tooling.
Its unit of work is still one call. The loop decides what the next call is, one at a time, as it goes. That is exactly right for open-ended work where the steps are not known in advance: a research task, a debugging session, a conversation. The loop can go anywhere, because it decides at run time.
It is the wrong shape for a job that does the same seven things to ten thousand items. The steps are known. The loop still discovers them one call at a time, so nothing can be said about the job before it runs: not how long it will take, not what it will cost, not which steps could have run side by side. And the loop code, with its retries and its queue and its checks, is yours to write and operate, and it is usually the least reliable code in the system.
Graph engineering: the shape of the whole job
Graph engineering starts from the job rather than the call. The job is a set of steps. Each step reads some inputs and some other steps’ outputs, and produces an output of a declared shape. Written down, that is a graph: a node for each step and an edge wherever one step reads another’s output. The graph is the unit of work. Calls are what happens when it runs.
The point of having the graph is what can be read off it before a run. Which steps are independent, and so can run at the same time. The longest chain of dependent steps, which is how long the job takes. The cost, from each step’s token estimate, with a worst case if every retry fires. And the places where the job changes hands: a call to your own system, a wait for a person, a move from a small model to a large one. A loop discovers all of these as it goes. A graph shows them in advance.
The graph should be derived, not declared. The dependency is already in the prompt: if step B’s prompt reads step A’s output, B depends on A. Declaring it a second time creates two sources of truth that drift apart the first time someone edits a prompt. A compiler that reads the prompts and finds the references builds a graph that cannot disagree with them. The only ordering left to say by hand is the kind that carries no data, such as “log after the send has settled, whether or not it succeeded.”
Deriving the graph has a consequence: every step needs a declared output shape, so that a reference to a field can be checked and a malformed answer can be caught before the next step reads it. Structured output stops being a nicety and becomes the type system of the job. A step that is validated can be retried, handed to a larger model, or skipped, without the steps after it inheriting garbage.
What a DAG is, and why the A matters
The graph of a job is a directed acyclic graph, a DAG. Directed, because an edge has a direction: data flows from the step that produces it to the step that reads it. Acyclic, because there are no loops: no step can depend, through any chain, on its own output. Data pipeline tools such as Apache Airflow have used the same structure for years, for the same reason.
The acyclic part is what separates graph engineering from loop engineering, and it is a feature. A graph with no cycles has a topological order, a sequence in which every step comes after everything it reads, so it can always be run to completion. It has a critical path, so its duration is known. It can be checked for a reference to a step that does not exist, or to a field a step never produces, before it runs. A loop can do none of these things, because a loop can, by construction, go round again.
Retries live inside a node, not as an edge back to it, and that is what keeps the graph acyclic while still letting a step try again. A step that fails validation runs again, or on a larger model, within its own node; the graph around it is unchanged.
Which one your work needs
| Prompt engineering | Loop engineering | Graph engineering | |
|---|---|---|---|
| Unit of work | One call | One call, chosen at run time | The whole job |
| Steps known in advance? | There is one | No | Yes |
| Best for | One call per item | Open-ended, interactive work | Known steps, many items |
| Known before the run | Nothing beyond the prompt | Nothing | Parallelism, duration, cost, hand-offs |
| Where the structure lives | In the prompt | In your loop code | In the document, derived from the prompts |
| What you maintain | Prompts | Prompts and an orchestrator | Prompts, a document and its tests |
The three build on each other rather than replacing each other. Every node in a graph is a prompt, so prompt engineering never goes away. A loop can submit a graph as one of its steps, when an agent decides that a known pipeline should now run over a set of items. The question is only which one is the unit you are reasoning about, and for work that is not interactive, the honest answer is usually the graph.
Frequently asked questions
Is graph engineering just workflow orchestration with a new name?
The structure is the same, a DAG of steps, and tools like Airflow have run DAGs for years. What is new is where the graph comes from and what the nodes are. In an orchestrator you declare the edges and the nodes are arbitrary code. In graph engineering the nodes are model calls with declared output shapes, and the edges are derived from which prompt reads which output, so the graph is checked against the prompts rather than maintained beside them.
Do I still need prompt engineering if I have a graph?
Yes. Every node is a prompt, and a graph of bad prompts produces bad results in parallel. What the graph changes is the size of each prompt: one job each, which is easier to write and to test than one prompt that does everything.
Can an agent use a graph?
Yes, and it is a good division of labour. The agent decides, at run time, that a known pipeline should run over a set of items; the pipeline runs as a graph, with its duration and cost known in advance. The open-ended part stays a loop and the repetitive part becomes a graph.
Related guides
If your AI work is a pipeline, submitting one request at a time discards the structure that would let it be scheduled well. What the research says that costs.
Most useful AI work is several model calls in a row. The common patterns, where chained jobs lose time and money, and how to design steps that hold up.
Schemas, validation, retries and escalation: how to get JSON from a language model that your code can trust, and what to do with the answers that fail.
An injected instruction can only do what the system around the model allows. Where the three ingredients of an attack live in an agent loop and a fixed graph.
Work backwards from when the output is needed, not from how fast it could be. A practical way to set deadlines for batch AI jobs and pipelines.