How AI Engineering Keeps Renaming Itself; The Evolution of AI Engineering, From Prompt to Graph

A developer's twelve-word question about whether the industry had shifted from loops to graphs drew millions of views and spawned competing definitions, highlighting how AI engineering has renamed itself roughly once a quarter since 2022. The job has evolved through six labels—prompt engineering, context engineering, harness engineering, loop engineering, tool use, agents, and now graph engineering—each reflecting a growing unit of work from a single sentence to a network of programs. The core insight is that the bottleneck has always been the interface to the model, not the model itself, and the discipline's expansion follows a single direction: the hard part moves from the model outward into the structure built around it.

Midway through 2026, a developer posted a twelve-word question. Are we still talking loops, or did we shift to graphs yet. Within a day it had drawn millions of views, spawned three competing definitions, and picked up a widely shared study that, it later turned out, had never existed. That question was only the newest name for a job the industry has renamed roughly once a quarter since 2022. First came prompt engineering. Then, faster and faster, context engineering, harness engineering, loop engineering, and now graph engineering, with a quieter stretch of tool use and agents folded in between. Six labels in four years for something that, squinted at from across the room, looks like one stubborn job. Getting a machine to do what we actually meant. What follows is a field guide to all six, built from the ground up so a newcomer can follow every step, and it ends on the question hiding under the whole parade. Are these six genuinely different disciplines, or one idea we keep renaming as the work grows from a sentence into a system. One idea sits under all six labels, and it is the thing to hold onto before the detail begins. Across the whole timeline, the unit of work keeps getting bigger. We began by engineering a sentence, the prompt. We are now engineering a network of programs that talk to each other, the graph. Everything between those two points is the story of that expansion, and it runs in a single direction. With each stage, the hard part of the job travels a little further from the model itself, out into the structure built around it. Prompt engineering is the craft of wording the instruction you give a model so it does what you want. A prompt is simply the text you send. That is the whole surface area at this stage, the words in, and the words back. To see why this was the first thing anyone engineered, it helps to picture the tool as it was in 2022, when ChatGPT arrived and a much wider audience met large language models for the first time. A large language model, or LLM, is a program trained on an enormous amount of text to predict what comes next, one piece at a time. It is frozen after training. It does not look anything up, it does not remember your last conversation, and it cannot press a button in the world. It sits there, and it responds. When the only thing you can change is the text you type, the text you type becomes the entire discipline. And it turned out the wording mattered far more than anyone expected. A famous early result showed that simply adding a short instruction to reason step by step, rather than answer immediately, made models dramatically better at arithmetic and logic problems. That technique, chain of thought prompting, came out of Google researchers in 2022, and it was a small shock, since nothing about the model had changed. The same frozen weights, asked more carefully, produced better answers. A whole toolkit grew from that observation. Giving the model a couple of worked examples before the real question, called few-shot prompting. Assigning it a role to steer its tone and priorities. Asking it to reason before it concludes. None of these touch the model. They only shape the request. The core discovery of the prompt era was that a frozen model already contained more capability than a careless question could reach. This is worth sitting with, because it sets up everything that follows. The bottleneck was never only the model. It was also the interface to it. And once people noticed that the interface was where the leverage lived, the natural next question was obvious. If wording the request unlocks this much, what else around the request could we shape. What prompt engineering could not do was let the model act. It could reason beautifully about a flight booking and still had no way to check a live price, because it had no hands. That limit is what forced the next rung into existence, and it is the rung most timelines skip. The next shift did not arrive with a tidy name and a launch date, which is exactly why it often gets left off the timeline. But it is the most important change in the whole story, because it is the moment the model stopped only talking and started doing. Two ideas landed close together in 2023. The first was tool use , also called function calling. A tool is any external capability the model can invoke, a web search, a calculator, a database query, a call to another piece of software. Function calling gave the model a structured way to say, in effect, I need to run this specific operation with these inputs, and to receive the result back and carry on. The second idea was the agent , a model placed inside a loop where it can reason, take an action through a tool, observe what came back, and then reason again with that new information, repeating until the task is done. The pattern that made this concrete was named ReAct, a compression of reason and act, from researchers in 2022 whose influence landed through 2023. The move was to interleave thinking and doing. The model writes a thought, chooses an action, sees the observation, and updates its next thought accordingly. Around the same time, the first frameworks for stringing these steps together appeared and spread quickly, LangChain among them, alongside more experimental projects like AutoGPT that tried to let an agent run almost entirely on its own. Retrieval augmented generation, usually shortened to RAG, arrived in the same window as the standard way to give a model access to outside knowledge, by fetching relevant documents and placing them in front of the model before it answers. The instant a model could call a tool and read the result, a text generator became something that could take action in the world. Picture the difference plainly. Asked in 2022 for the current price of a flight, a model could only produce a confident guess from stale training data. Given a search tool and an agent loop in 2023, the same model could reason that it needed a live figure, call the search, read the actual number, and answer from it. Nothing about the underlying intelligence changed. What changed was that it now had hands, and a simple loop to use them in. This era did not settle on a single banner, which is why later writers often bundle it into the stages on either side. Some fold tool use into context engineering, since a tool result is one more thing you place in front of the model. Others fold the agent loop forward into loop engineering. Both are fair, but leaving the rung out entirely creates a strange three-year silence in the timeline between 2022 and 2025, and it hides the single most consequential change of all. Everything after this point, every harness, every loop, every graph, assumes agents that can act. This is where they were born. Giving a model hands created a new problem the moment it solved the old one. An agent that can pull in search results, documents, tool outputs, and its own past steps is an agent drowning in material, and what it gets to see, and in what order, starts to decide whether it succeeds. Managing that flood is the next rung. Context engineering is the craft of managing everything a model sees when it works, beyond the immediate prompt. That includes the system instructions that set its behaviour, the documents retrieved for the task, the memory of earlier turns, the definitions of the tools it can call, and the results those tools return. If prompt engineering was about the sentence, context engineering is about the whole briefing pack. The reason this became its own discipline is a hard limit called the context window . A model can only consider so much text at once, its working memory, and everything the model knows in the moment has to fit inside that window. Early on, teams treated the window like a bucket and simply poured everything in, dumping ten retrieved documents wholesale and expanding the window whenever it overflowed. That approach fails in a specific and well-documented way. Models pay less attention to material buried in the middle of a long context, so stuffing the window can bury the very fact the task depends on, a failure sometimes called context rot. The craft, it turned out, is not stuffing more in. It is curating what goes in, in what order, and what gets left out. The term itself reached prominence in 2025. Andrej Karpathy helped push it into common use, and Anthropic’s engineering team gave it a formal treatment in a September 2025 post that called context engineering the natural evolution of prompt engineering, describing the work of tuning the blend of system prompt, user input, history, tool results, and retrieved knowledge that enters the window. LangChain and others formalised it around the same time. The confidence level here is high on the naming, since the September 2025 Anthropic piece is a primary source, though it is worth being honest that the underlying practice is older than the label. The retrieval techniques at its heart date to 2023. What 2025 added was the recognition that all of these moving parts, retrieval and memory and tool definitions and history, are one problem, the problem of composing a context, and that it deserved a name. After a few years of the prompt being the centre of attention, the harder question became what to put around it. A concrete picture helps. Imagine a support assistant answering a customer question. The prompt engineering view is a well-worded instruction. The context engineering view is the instruction plus the three most relevant help-centre articles retrieved for this exact question, plus a short summary of the customer’s previous tickets, plus the definitions of the two tools it may call, all assembled to fit the window with the most important material placed where the model will actually attend to it. Same model, same question, a far better answer, and none of the improvement came from the wording. Managing what a model sees gets you a well-briefed agent for a single task. But once these agents were trusted to run longer, on real work, a different weakness surfaced. A well-briefed agent still makes mistakes, and left alone it makes the same mistake again and again. Fixing that is no longer about the briefing. It is about the entire environment the agent runs inside, and that is the next rung. Harness engineering is the craft of designing the whole environment an agent operates within, the rules it follows, the tools it can reach, the checks it must pass, and the feedback loops that stop it repeating a mistake. If context engineering shapes what the model sees, harness engineering shapes everything around the model that turns raw intelligence into a reliable worker. There is a compact formula that captures it, agent equals model plus harness. The model supplies the intelligence. The harness makes that intelligence dependable. The name has a precise and recent origin, and it comes with a nuance worth stating plainly, because it is the clearest example in this whole story of a label arriving after the thing it names. On 5 February 2026, Mitchell Hashimoto, the creator of Terraform and a co-founder of HashiCorp, published a post about his own experience working with coding agents. He described a habit. Every time an agent made a mistake, he would engineer a permanent fix into its environment, so that the same mistake became structurally impossible to repeat. He wrote that he had grown to calling this harness engineering, while openly admitting he was not sure whether an accepted term already existed. Six days later, on 11 February, an OpenAI engineer named Ryan Lopopolo gave the idea a fuller, formal treatment in a post describing how his team shipped a real product with no human-written code, and the phrase spread from there through Anthropic, Thoughtworks, and a large secondary commentary. Here is the nuance. Hashimoto crystallised the phrase, but the underlying idea was already in circulation. The term agent harness appears in a benchmark paper from December 2024, in an agent framework from mid 2025, and in Simon Willison’s writing in September 2025, all before Hashimoto’s post. So the honest way to describe it is that he coined the phrase, not the concept. That distinction matters, and we will come back to it, because it is a pattern rather than a one-off. The realisation behind the harness was simple. As models got good enough, the bottleneck moved from the model to everything around it. The most vivid example is Hashimoto’s own habit, sometimes called the ratchet. An agent writes code that breaks a convention. Rather than just correct that one instance, you add a rule to the agent’s instruction file, or a test to the suite, or a check to the pipeline, so the agent can never break that convention again. The environment tightens by one notch each time, and it never loosens. Multiply that over weeks and the agent operates inside a dense, hard-won set of guardrails that make whole categories of error impossible. The OpenAI account pushed this to its limit, a team shipping a large codebase where humans wrote none of the code and instead spent their effort designing the structure, the documentation, and the automated checks that kept the agents on track. The tagline that stuck was that humans steer while agents execute. A good harness keeps a single agent honest over a long task. But it still assumes a person is there to kick off each run and decide what happens next. The next shift asks a sharper question. What if the agent could drive itself, deciding what to do next and when it is finished, without a human typing the next instruction each time. That is loop engineering. Loop engineering is the craft of designing the cycle an agent repeats on its own, the plan, the action, the check, and the decision about whether to continue or stop. The unit of work moves here from a prompt you type to a loop you design. Instead of prompting the agent yourself, turn after turn, you build the system that prompts the agent, and you step out of the seat. The idea rests on a small, almost humble definition. A loop is a task with a check. The agent does something, then verifies the result, then decides whether to keep going or quit. Everything hard about loop engineering lives in that check and that stop condition, because a loop without a real check is just a fast way to repeat a mistake, and a loop with no sensible stop can spin forever or quietly go off the rails while no one is watching. The genuinely difficult parts are defining a goal the agent can pursue unattended, giving it a reliable way to tell whether it has succeeded, and deciding what makes it stop. The naming moment is well documented and, like harness, it is a shared story rather than a single author. In early June 2026, Peter Steinberger, a developer known for the tool OpenClaw, posted a line that spread fast, arguing that we should stop prompting coding agents by hand and start designing loops that prompt them for us. Boris Cherny, who leads work on Claude Code at Anthropic, said much the same from inside a vendor, describing how he no longer writes prompts and instead writes the loops that drive the model. Then, on 7 June 2026, the writer and Google engineer Addy Osmani published an essay titled Loop Engineering that gave the pattern its name and, more usefully, an anatomy, laying out the parts every real loop needs, discovery, task decomposition, an orchestration layer, verification, and persistent memory. Credit here is genuinely shared. Steinberger lit the fuse, Cherny echoed it from the vendor side, and Osmani named and structured it. The shift the loop era captured was from prompting an agent turn by turn to designing the system that prompts it for you. This rung also has a clear predecessor, which strengthens the pattern of names trailing practice. Before anyone said loop engineering, there was a technique some called Ralph, described by the engineer Geoffrey Huntley in 2025, which was almost comically simple. Run a coding agent inside a plain while loop. Feed it the same instruction against a written specification, let it pick one task and implement it, then start a fresh iteration. It worked well enough to be taken seriously, and it was loop engineering in all but name, a year before the name. The concrete example most people meet first is exactly that coding case. A developer writes a specification and a checkable definition of done, then sets an agent running in a loop against it. The agent selects a task, implements it, runs the tests, reads the result, and either moves to the next task or fixes what failed, hour after hour, with the developer checking in rather than typing each step. Get the verifier right and the loop compounds real work unattended. Get it wrong and it confidently produces a pile of code that passes no meaningful check. A well-designed loop lets one agent run itself. But a single agent, however tireless, is still one worker doing one thing at a time. Real work often needs several specialists whose outputs depend on each other, and once you have many loops running, something has to coordinate them. Wiring them together is the last rung on the map. Graph engineering is the craft of wiring multiple agent loops together into a structure, where each agent is a node, the connections between them are edges, and shared state flows along those edges. A graph, in this plain sense, is just nodes and the links between them. When one agent running one loop is not enough, you connect several, each with a defined job, and you design how work routes between them and how their results combine. The motivation is easy to feel once loops are working. Suppose you have ten good loops, each an agent that runs itself well. You still have a person standing in the middle, carrying the output of one loop to the input of the next, deciding what starts when, checking which result can be trusted, and restarting whatever failed. The individual work became autonomous, but the coordination did not. Graph engineering is the attempt to encode that coordination itself, the dependencies, the routing, the trust between agents, into an explicit structure rather than a human’s attention. A common mental picture is an organisation chart. Each node is a role with a job, work routes between roles along defined lines, and results roll back up. This is the newest rung, the most contested, and the one to handle with the most care, because its story includes a cautionary tale about hype. The spark is well attested. On 18 July 2026, Peter Steinberger, the same developer behind the loop moment six weeks earlier, posted a short question asking whether the field was still talking about loops or had shifted to graphs yet. It drew millions of views within hours. There is an earlier documented use, a quieter blog post from a few weeks before, and a serious essay by Carlos Perez followed within a day. But then came the noise. Within forty-eight hours the term meant three different things to different people, copycat posts flooded in, and a claim about a 3.1 million dollar Stanford and Anthropic study circulated widely before an investigator found that the study did not exist at all. It was fabricated engagement bait. That detail is not a smear on the idea. It is a useful thermometer for how hot and how thin the discourse around a brand-new term can run. The honest summary of graph engineering is that a real discipline with decades of prior research is currently wearing a one-week-old name. Underneath the froth there is a genuine practice, and it is not new. Wiring specialised agents into a graph is what frameworks like LangGraph, Microsoft’s AutoGen, and Google’s Agent Development Kit already do, building systems as explicit nodes joined by edges with state passed along them, and it rests on a decade of research into multi-agent systems and graph-structured computation. A concrete pattern that people find persuasive is the worker and the checker. One agent does the work, researching or writing or building. A second, entirely separate agent looks at the output with fresh eyes and hunts for weak reasoning, missing evidence, and false claims of completion. The two have different jobs and different incentives, and connecting them as two nodes in a small graph catches errors that a single agent, marking its own homework, would sail straight past. That is the sixth rung, and the current edge. Which leaves the real question, the one this whole tour was built to ask. Six names in four years. Is that six disciplines, or one. There is an honest case on both sides, and a piece that only argued one would be selling something. The case that these are genuinely distinct disciplines is stronger than a cynic expects. Each rung has a different failure mode and rewards a different skill. Prompt engineering fails on ambiguous wording and rewards clear instruction. Context engineering fails when the window is stuffed or the crucial fact is buried, and rewards careful curation. Harness engineering fails when an agent repeats avoidable errors, and rewards the discipline of building a permanent fix for each one. Loop engineering fails when the verifier is weak or the stop condition is missing, and rewards the design of a check that actually checks. Graph engineering fails when coordination breaks down between agents, and rewards clear structure, defined roles, and clean interfaces. A person who is excellent at wording a prompt is not automatically good at designing a verifier or wiring a multi-agent system. The skills really do diverge. By that reading, these are separate crafts that happen to share a lineage. The case that it is one continuous idea is also strong, and it is the quieter, more structural argument. Every stage is a version of the same task, getting a model to do what we actually meant, applied to a larger and larger unit of work. The unit grows from a sentence, to a briefing, to an environment, to a self-driving cycle, to a network of cycles. And the names, on close inspection, keep arriving after the practice they describe. Context engineering named retrieval techniques that were years old. Harness engineering, by its own coiner’s admission, put a phrase on a concept already in use. Loop engineering named a pattern that the Ralph technique had already demonstrated. Graph engineering put a fresh label on multi-agent orchestration that frameworks had shipped long before. The skeptics have a real point. LangChain, among others, argued that graph engineering was nothing new, and a chorus of practitioners has called the whole sequence a series of rebrands of orchestration, state management, and verification. Even the maps disagree with each other. Some serious taxonomies insert an intent engineering rung, others speak of agent engineering as a distinct paradigm, and when the mapmakers cannot agree on the stages, it is hard to insist the stages are crisp and separate. Here is where I land, offered as a judgment rather than a fact. It is mostly one continuous discipline, and the renaming is mostly a symptom of the work getting bigger rather than of five genuinely new fields being discovered. But mostly is not entirely, and the renaming is not empty. Each name, whatever its hype, did mark a real moment when the hard part moved outward, from the wording, to the briefing, to the environment, to the cycle, to the wiring. The labels are inflated. The underlying shifts are real. The most accurate picture is not five separate disciplines, and it is not one static skill wearing costumes. It is a single skill whose centre of gravity keeps moving away from the model, and each new name is a marker planted at the spot where the difficulty had travelled to that season. The clearest way to see this is that the stages nest rather than replace. Prompt engineering did not die when context engineering arrived. It became the innermost layer. You still write a prompt, but now it sits inside a curated context, which sits inside a harness, which runs inside a loop, which is one node in a graph. Nothing was thrown away. The work simply wrapped itself in another layer, and gave the new outermost layer a name. If the pattern holds, and the unit of work keeps expanding, then graph engineering will not be the last marker planted. It is worth noticing what was already stirring in the days right after the graph moment. In the same stretch of late July 2026 came talk of parallel programming for agents, a fresh wave of model launches, and a widely shared call from Y Combinator for what it termed multiplayer AI, shared live agent sessions treated as the product itself. Whether any of these hardens into the next named rung, or whether the whole naming treadmill finally slows as the practices settle and consolidate, is genuinely unknown. So the question to sit with is not which term wins next. It is whether we are watching a field discover truly new disciplines, one per season, or a single craft maturing in public and narrating its own growth a little breathlessly as it goes. The honest answer is that it looks like both at once, and the next name, whenever it lands, will be worth the same careful look. What actually changed underneath it. And whether the label is doing real work, or just wearing a new coat. Prompt engineering Tool use and agents Context engineering Harness engineering Loop engineering Graph engineering On the taxonomy itself How AI Engineering Keeps Renaming Itself; The Evolution of AI Engineering, From Prompt to Graph https://pub.towardsai.net/how-ai-engineering-keeps-renaming-itself-the-evolution-of-ai-engineering-from-prompt-to-graph-3be81a8852cd was originally published in Towards AI https://pub.towardsai.net on Medium, where people are continuing the conversation by highlighting and responding to this story.