Apparently, joking about LinkedIn's next AI buzzword is one way to get quoted in The Register.
Back in June, I had a brief exchange on X with Peter Steinberger, creator of OpenClaw. Peter had suggested that instead of prompting coding agents, we should be designing loops that prompt them.
I joked:
Oh god, LinkedIn will now start a new fad, 'Loop Engineering'. Harness Engineering is so last year. Loop Engineering is what you should be doing.
Peter replied:
Don't worry it'll take 3 months until it's there. We'll be talking about fleets that design your loops then.
Thomas Claburn included the exchange in The Register's article, "Loop engineering, latest AI buzzword, still needs humans in the loop".
Attention is not usefulness
Looking at Google Trends now, interest in "loop engineering" spiked around June (way before three months!) and then declined. "Harness engineering" peaked earlier and also declined.
Google Trends, captured on 18 October 2026. Worldwide, past year, all categories, Web Search. The comparison uses the quoted search terms "loop engineering" and "harness engineering". Values represent relative search interest, not absolute search counts.
That measures attention, not usefulness. I would not use this chart to conclude that the underlying practices have stopped being useful.
The buzzwords don't matter nearly as much as what changes in our day-to-day work. But before dismissing the labels, I think it is worth asking why they resonated.
Why harness engineering, and then loop engineering?
My reading is that both terms caught on because they gave a name to a change people were experiencing while building with AI. The chart alone cannot establish why either term became popular, but I can see why each idea resonated.
With a chat interface, the prompt is the most visible part of the interaction. It is natural to focus on how to ask a better question. But once I ask a model to do real work, the prompt is only one part of the system. What information can it retrieve? Which tools can it use? What permissions does it have? How do I check what it did?
"Harness engineering" puts a name to that surrounding software. I think part of its appeal is the recognition that a more capable model or a better prompt is not enough. The environment in which the model operates matters too.
But giving that work a name doesn't remove the need to understand the engineering beneath and around it. If I split a workflow across several agents, I need to orchestrate their work, decide which tasks can run concurrently, and define how the agents communicate and hand off results. I also need to manage shared state, dependencies and failures. These are system-design questions, not just questions about an individual model or prompt.
"Loop engineering" draws attention to a different shift. Instead of asking for one result, inspecting it myself and writing the next prompt, I can arrange for the system to act, inspect feedback and continue. Some of the coordination that I was doing manually moves into software. But there are two different loops here, and I think it is important to distinguish them.
The first is the agent execution loop: the model chooses an action, calls a tool, observes the result and decides what to do next. It repeats this process until the task is complete, it needs help or it reaches a limit. This loop carries out the work using the current instructions, tools and workflow.
The second is the self-improvement loop: evaluate how the agent or workflow performed, identify a weakness, propose a change, test it and decide whether to keep it. That change might affect instructions, context retrieval, tool use or orchestration. Here, I am not just asking the system to finish a task. I am asking it to help improve how future tasks are performed.
These loops can interact, but they are not the same thing. Calling another tool or revising an answer does not, by itself, improve the workflow for the next run. Nor does "self-improvement" necessarily mean changing model weights; it can mean changing the software and configuration around the model.
I can see why that gets people excited. The unit of delegation becomes more than one response. But the important question is not how long I can keep an agent running. It is whether the feedback helps it make progress, whether it knows when to stop, and whether the result is useful.
I am not advocating "loop engineering" as a new discipline or a label we need to adopt. I want to separate the mechanisms from the terminology. Both loops need tools, context, state, permissions and checks. The self-improvement loop also needs controls over what it may change and how those changes are validated. Those engineering requirements matter regardless of what we call the work.
A new primitive for knowledge work
Generative AI gives us a powerful computational primitive: describe an intended result, provide context and examples, and get an output without explicitly programming every intermediate step from input to output.
This is what I find interesting. I can express parts of my tacit knowledge through instructions, examples and evaluation criteria, and delegate parts of knowledge work that previously resisted automation.
Take preparing a report from meeting notes and project updates. I can describe what matters, provide examples of useful reports, and ask the model to identify risks and summarize progress. I don't have to write an explicit rule for every way a risk might be expressed in a meeting note.
But that doesn't make the result correct. These are probabilistic components, not deterministic functions. I still need to check whether the report missed an important risk or introduced a claim that the source material does not support. That changes how I must test, constrain and integrate the component.
Loop engineering: haven't we seen this loop before?
As people experiment, they discover useful ways to organize both kinds of loop. Part of the excitement is about agents doing more work without a person directing every step. Another part is about agents helping evaluate and refine the way that work is done.
The underlying pattern, however, is nothing new:
Implement. Observe. Evaluate. Refine. Repeat.
We have done this a ton of times in the past!
What changes is the component inside the loop. A model can now interpret feedback and propose either the next task action or a change to the workflow itself. But I still need a meaningful way to evaluate the result. Asking an agent to check its own work is not the same as independently verifying that work. Nor does another iteration guarantee improvement.
If I let an agent propose changes to its own workflow, I need to compare the changed version against a baseline, test it on representative cases and retain a way to roll it back. A change that helps on one task may make other tasks worse. Producing a revised workflow is not evidence that the workflow improved.
The engineering beneath and around harness engineering and loop engineering
The deeper I go into building these systems, the more I draw on established ideas from software engineering and adjacent disciplines: systems thinking, domain-driven design, theory of constraints, orchestration, distributed systems, message passing, observability, concurrency control, idempotency, dependency graphs, authorization policies, decision theory, and the like.
For instance, if an agent retries a step, can it accidentally send the same message twice? That's an idempotency problem. If two agents update the same record, I need concurrency control. If an agent can draft a response, does that also mean it should be allowed to send it? That's an authorization decision.
And if I generate reports faster but create a backlog for the people reviewing them, have I really improved the workflow? Systems thinking and the theory of constraints help me ask the right question instead of celebrating the speed of one step.
These ideas don't answer every new question. But they help me distinguish a genuinely new capability from a familiar pattern with a fashionable name.
For me, the useful work is to investigate what has actually changed, reason from first principles, and measure whether the complete workflow improves.
Before learning the next label, understand the underlying mechanism.
The fundamentals are what matter.