Prompt, context, loop, graph: the four eras of AI engineering

There's a shape to how we build with AI, and it's changed four times in about eighteen months. Each era didn't replace the one before it. They layered. You still write prompts. You still manage context. But the hardest problem moved, and the name of the work moved with it.

Looking back from mid-2026, the arc goes something like: prompt engineering, then context engineering, then loop engineering, and now what I think people are going to call graph engineering. Each one was the right abstraction for its moment, and each one broke at a certain scale.

Era one: prompt engineering

Late 2022 through most of 2023. You had one call to one model, and the whole job was in the prompt. Write the right instruction, include the right examples, format the output, and hope.

Prompt engineering was a craft of words. Chain-of-thought, few-shot examples, system vs user separation, output format constraints: these were the skills. It worked surprisingly well for single-step tasks. Summarize this. Classify that. Generate a response from these facts.

The limit appeared the moment you needed the model to do something it couldn't do in one pass. Look something up. Call an API. Reason over more text than fits in a context window. Prompt engineering alone couldn't solve that, because the model was still a function: text in, text out. So we added tools, and suddenly the prompt wasn't the only input anymore. That broke the first abstraction.

Era two: context engineering

Late 2023 through mid 2025. Models got bigger context windows (100k, 200k, eventually a million tokens and beyond), and tool use became first-class. Now you weren't just writing a prompt. You were assembling a context: relevant documents retrieved from somewhere, tool definitions, conversation history, system instructions, all stuffed into one giant input and handed to the model in a single turn.

The craft shifted. It became about what you included and what you left out. Too much context and the model lost the signal. Too little and it hallucinated. The art of RAG (chunking, embedding, reranking, deciding which pieces of your knowledge base to retrieve) was context engineering. I wrote about this in building an AI concierge that doesn't hallucinate. The prompt still mattered, but retrieval quality mattered more.

Context engineering broke when the tasks got multi-step. You can't stuff everything a five-step workflow needs into one context window and expect the model to execute it in order, reliably, with branching logic. So we stopped trying to do it in one shot.

Era three: loop engineering

Mid 2025 through early 2026. Instead of one call, you made many. The model ran in a loop: think, act, observe, repeat. Agents. Each step produced a result that fed into the next. The model decided which tool to call next, or whether it was done.

This is where the hard problem moved from "what goes in the prompt" to "how do you control a sequence of model decisions." Loop engineering meant designing the feedback cycle: how the model sees its own output, how it decides to continue or stop, what happens when it gets stuck, how you prevent infinite loops, how you handle partial failures. The agent pattern gave you power but took away predictability. A prompt is deterministic-ish; a loop can go anywhere.

The limit here was complexity. A single agent loop with a handful of tools works. Two agents passing work between each other, less so. A system where five specialised agents collaborate, each with its own tools, memory, and termination conditions, is not a loop anymore. It's a graph. And graph engineering is what you need when the thing you're orchestrating stops looking like a sequence and starts looking like a directed acyclic graph of decisions, merges, and fan-outs.

Era four: graph engineering

This is where we are now. Graph engineering is the practice of designing systems where multiple agents, tools, retrievers, and human-in-the-loop checkpoints are wired together into a computational graph. Not a single loop. Not a chain. A topology.

A graph-engineered system might fan out three agents in parallel to research different aspects of a problem, merge their findings, run a critique agent that decides whether the synthesis is good enough, loop back to the fan-out if it isn't, then pass the final result through a human approval node before publishing. That's not one prompt. It's not one context window. It's not one loop. It's a graph with branching, parallelism, convergence gates, and a human node at the edge.

What you engineer in this era isn't the prompt (though you still write them) or the context (though you still manage it). You engineer the topology. Which nodes talk to which. What information flows where. Where the parallelism is safe and where it isn't. Where the human gate belongs. How to handle a node failure without tearing the whole graph down.

What's actually hard about it

The hard parts aren't what I expected. The models keep getting better, so the individual node quality keeps rising. What's hard is the plumbing between nodes.

The first hard thing is state. In a graph, intermediate results have to flow between nodes that might run in parallel, might run at different times, might fail and rerun. A shared key-value store per invocation kind of works, until two parallel nodes try to write the same key. You need namespacing, or immutable results, or both. This is the kind of systems problem that prompt engineering never had to think about.

The second hard thing is termination. A single agent loop has a stop condition. A graph can have cycles, intentional ones like a critique-then-revise loop, and those cycles need bounded iteration counts or quality gates, otherwise you burn tokens forever. Every loop in the graph needs an explicit budget or an explicit convergence criterion. Neither is satisfying, and both are your problem.

The third hard thing is observability. When a single prompt fails, you read the prompt and the response. When a graph fails, you need to know which node failed, at which iteration of which cycle, with what inputs, and whether the failure cascaded or was contained. Tracing across a graph of model calls is a genuinely unsolved problem, and it's where most of my debugging time goes now.

The pattern across all four

Each era moved the hard problem one level up. Prompt engineering was about the content. Context engineering was about the input assembly. Loop engineering was about the control flow. Graph engineering is about the architecture.

The thing that's stayed true through all of them: the models get better, and each time they do, the abstraction moves. What was expert work eighteen months ago becomes a library call. The people who thrive are the ones who let go of the old abstraction and climb to the next one.

Right now, the next one is graphs. If you're still perfecting your prompt templates, you're engineering one floor below where the hard problems live. The hard problems are topology, state, termination, and observability across multi-agent systems. That's graph engineering. It's what prompt engineering wanted to be when it grew up, and it's what loop engineering becomes the moment parallelism shows up.

I don't think it's the last era. There will be a fifth, and it'll make graphs feel like prompts feel now: necessary but not the interesting part. But for this moment, this is where the work is. Not what you say to a model. How you wire the models together. That's the job now.