In five years the job has had three names. Prompt engineering, then context engineering, and since June this year, loop engineering. Each time, a new set of courses and job titles showed up within weeks.
It is easy to call this relabelling. I don't think it is. Each name arrived when the one before it stopped being enough. What stayed the same underneath is the part worth learning.
Prompt engineering: getting one call right
The first name was about wording. You had one call to the model, and the work was to phrase it well: clear instructions, a few good examples, the right output format.
This was real. The GPT-3 paper in 2020 showed that a model could pick up a new task from a few examples in the prompt, with no retraining. Two years later, chain-of-thought prompting showed that asking for steps before the answer could change results on reasoning tasks. Wording mattered, and people who were good at it got better results.
Then it stopped helping. The limit was simple: you can't phrase your way past missing information.
Context engineering: deciding what goes in
I wrote about our policy chatbot that answered from an old version of a policy. The prompt there was fine. The model answered faithfully from what it was given. What it was given was wrong, because the older document matched the question first.
No rewording would have fixed that. The fix was in deciding which documents went into the call at all.
That is what the second name is about. In June 2025, Shopify's Tobi Lütke said he preferred "context engineering" to "prompt engineering", and Andrej Karpathy agreed. Simon Willison collected both posts and guessed the term would stick. It did. Later that year Anthropic published Effective context engineering for AI agents, which calls it the natural next step after prompt engineering.
The work changes from "how do I say this" to "what does the model see": which documents, which part of the history, which tool results, which instructions. The window is limited, and more is not better. Anthropic's post puts the goal as the fewest, most useful tokens that make the outcome you want likely. There is evidence behind that. Lost in the Middle found that models used information at the start or end of a long input much better than information in the middle. Chroma's Context Rot report tested 18 models and found their performance got less reliable as the input got longer.
So noise hurts. Picking the right material became the job.
Then that stopped being enough too. Some tasks can't be done in one call, however good the context is.
Loop engineering: designing the cycle
An agent is many calls in a row. The model reads something, calls a tool, reads the result, decides what to do next. Anthropic's post uses a short definition: models using tools in a loop.
Once you have a loop, new questions come up that neither of the first two names covers. What happens after each step? When does it stop? What does it remember when the context fills up? Who checks the result before it counts?
In June 2026, Addy Osmani put a name on this in Loop engineering. His version goes further than one agent run: you stop being the person who prompts the agent, and you build the system that does it. That system finds the work, hands it out, checks the result, writes down progress and picks the next step. He also says this is harder than prompt engineering, not easier. I agree with that part most.
What was real, and what was relabelling
Each change was real. Each came when the previous approach hit a wall:
- Better wording stopped helping when the model was missing information.
- Better information stopped helping when one call couldn't do the job.
None of them replaced the one before. A loop still makes calls. Each call still needs the right context. The context still needs clear instructions. If you build an agent and skip the first two, you get a loop that repeats a bad call many times, quickly.
The relabelling is everything sold around each name: the courses, the certificates, the job title that changes every year. That part does expire.
On a platform we built, we had our own structure for memory, context and looped reasoning before any of these names reached us. I mention it only because it says something about the names. They describe work that teams were already doing because the problem forced them to. The name came after.
The skill underneath all three
The skill that stayed the same: knowing what the model needs to see to answer correctly, and checking whether it did.
That was true for the first prompt with three examples in it. It was true for the policy chatbot. It is true for an agent that runs for an hour and writes notes to a file between steps. In each case the question is the same. Did the model have what it needed at the moment it made the decision? And how would you know if it didn't?
The second half is the part people skip. You only learn what the model needed by reading what it did: the inputs, the outputs, the steps in between. For a single call that means reading answers. For an agent it means reading traces. If you can't see what went into a decision, you can't improve it, whatever you call the job.
If you are building agents and want help with the loop itself, the stopping rules, the memory and the checks, that is what we do in agentic automation.
What to ignore if you are learning now
Ignore the name of the month. Learn two things that don't expire:
- How to put a model inside a system that works: what it reads, what it can do, when it stops.
- How to check its output, on real inputs, every time something changes.
Tricks for one model expire in months. A phrasing that worked on last year's model may do nothing on this year's. Anthropic's own post says smarter models need less prescriptive engineering. The tricks shrink. The judgement about what goes in and what comes out does not.
One thing to do this week
Take one AI feature or agent you work on. Pick one answer it got wrong. Write down everything the model saw when it made that decision: the exact prompt, the documents, the history, the tool results.
Then ask one question: with only this in front of me, would I have got it right?
Most of the time, the answer tells you which of the three names your problem belongs to.