Demystifying Loop Engineering, From LLM to Graphs

Which loop are you talking about? What is there to engineer about it? What do you mean by a harness, and what exactly is an agent?

If you are asking yourself those questions, this article is for you. In the following paragraphs we are going to demystify the buzzwords and understand in practical terms what they mean for you on a day-to-day basis. If you are using a coding agent, you are probably already doing tasks related to harness engineering and loop engineering without realizing it. We are also going to examine some routine tasks and understand which conceptual layer they belong to. Let's go.

LLM

We are going to start our journey at the bottom, where we find the first building block of the stack, the LLM.

LLM stands for Large Language Model. This is the engine of the whole stack on which the agentic paradigm is built. To understand in simple terms what an LLM is, we can refer to a quote by Andrej Karpathy that I like: "You can think of an LLM as a probabilistic ZIP file of the internet". Think of it as a package that holds a compressed version of most of the information on the internet, stored as statistical connections. During the training process, those statistical relationships are "baked" into the model and expressed as weights. You can also copy this package from machine to machine. Make sure to check out the LLM Visualization to get an overview.

The LLM is the engine of the stack, we will fill the rest of the blocks as we go

To grasp the idea of an LLM even better, let's try to understand each of the concepts separately.

The first L in LLM stands for Large. It is large because it is trained on an enormous volume of data from the internet. At its source, that data is measured in petabytes. Then the data is cleaned, filtered and curated before it is used to train the model, in what is known as the training process. The FineWeb post on HuggingFace is an interesting read, and it explains the main steps in obtaining and processing the data before it is used for training.

The second L in LLM stands for Language. The model is trained on human language and notation. It can "understand" characters and words and can string them into sequences that make sense to us (although not always) as humans. While English is the dominant language in the training data, that data contains other languages as well, which means the model is able to understand and respond in languages other than English.

Calling it a model means that the weights encode, in compressed form, which strings tend to follow which. The Transformer Explainer website visualizes this nicely, showing the probabilities that emerge as the output of the model given a specific set of characters or words as an input string. You have probably heard of the term "temperature", which controls how varied that output is.

There are a few important characteristics to be aware of about an LLM:

• The LLM is frozen in time. It has knowledge only of information that was present in the training data at the "cutoff" moment.
• The LLM is stateless. It does not remember previous conversations, so each time we prompt a bare LLM it responds as if it were the first time. Like the guy from Memento.

Harness

The harness is all the code, tools and additional infrastructure that surrounds the model and turns it into an "Agent". This relationship is expressed as: Agent = LLM + Harness.

The harness is everything around the LLM that turns it into an agent

Analogies help us better understand new concepts, and for this purpose we are going to use an analogy of a car. We can think of an LLM as a car engine. The harness (chassis) is everything around the engine that makes it into a car you can actually drive. It is the frame, the gearbox, the drivetrain, the wheels, the fuel tank, the electrical system, the seats, the air conditioning, the interior and everything else.

This example is intuitive and demonstrates the difference in subjective experience we may get from a car (agent) when using the same engine (LLM) with different chassis (harness) types. Imagine an off-road open-frame dirt buggy versus a family SUV with all the perks. Although both might use the same engine, the chassis makes the experience and the purpose totally different. As in the example of the car, we can use different combinations of LLMs and harnesses to create the agent that we want for a specific purpose.

Agent

When we add a harness to an LLM, we get an agent (engine + chassis = car). Claude Code is one of the best-known agentic harnesses available.

When we pair Anthropic LLMs such as Opus, Sonnet or Fable with the Claude Code CLI agentic harness, we get a coding agent. There are many other harnesses out there: Copilot CLI, Google Antigravity CLI, Kiro, Cursor, Pi (the basis of OpenClaw) and others.

Coding agents are LLMs paired with an agentic harness

As the Wikipedia Agent harness page states, the harness may contain elements like tools, memory, persistence, context management abilities, guardrails, monitoring and more. It is everything related to the environment setup. It is what allows the LLM to read files, remember conversations and reach out to the internet to search for fresh information. If we take Claude Code CLI as an example of an agentic harness, it provides codebase navigation, search, automatic memory, bash command execution, subagent spawning and much more.

The User Part of the Harness

Although some of the abilities listed above seem intuitive when we mention them as part of the harness, others are not so obvious. "Harness" covers both the part bundled with the tool we use (Claude Code CLI, Pi, and so on) and the part we set up ourselves as users.

When working with Claude Code CLI, for example, we use additional techniques to improve the part of the harness that is controlled by the user.

Before asking the agent to perform a task, we create project memory and guides in the form of CLAUDE.md and rule files, which are eagerly loaded at session start. We use skills that load lazily, on demand, for multi-step tasks that can make use of additional scripts or templates to perform the job. We write specs, task lists, and try to provide any other valuable information that can improve the accuracy of the task being performed.

After completing the task, we provide the agent with linters, tests, skills (code-review), static analysis tools, logs, metrics and anything else that gives back sensory feedback. Feedback is a critical mechanism, and it has a dramatic effect on the precision and the quality of the final result.

The user part of the harness, which we can set up ourselves, is critical to the agent's performance

The important concept to understand here is that we as humans are also responsible for the harness.

Harness Engineering

Once we understand the idea that the harness is everything that surrounds the LLM, and that we as users also have the ability to create it, we are entering the layer of "Harness Engineering".

So what exactly is harness engineering, and which of our daily activities fall under that category? Harness engineering is about creating the right chassis for our car based on the purpose. Anything related to building and setting up that environment belongs here:

• Creating and compiling a knowledge base (LLM Wiki) that the coding agent can use to learn information or business rules
• Providing access to various APIs to fetch data and perform operations
• Providing and allowing access to command line tools and utilities
• Creating mocks for component tests of the service or an app
• Setting up MCP servers for Jira or Confluence access
• Setting up a Docker Compose environment so that the agent can spin up a container and test newly written code
• Creating a new steering file for Kiro or a rule for Claude
• Creating a skill for a multi-step process, with scripts, assets and references
• Creating an AGENTS.md or a CLAUDE.md
• Selecting a strongly typed language for your next project

Have you done any of the above? Congratulations, you have been doing "Harness Engineering".

Loop

The loop refers to the iterations that the agent performs to reach the goal. It is everything that happens during an interaction session and dies with it. The loop contains the definitions of how an agent moves from step to step to reach a goal.

The loop starts when we ask the agent to perform a certain task. The agent reads the request, the session history, project memory and any other information available. Then the agent reasons and plans the next steps. It performs some actions, like writing code or updating documentation. Then it observes the result by relying on available feedback (tests, lint rules, etc.) and performs self-correction until the end goal is achieved or a stop condition is met.

For example, the agent might write some code, then run unit tests which fail. The agent takes the unit test errors as feedback, runs a second pass on the code to fix the issues, and so on until the tests are green. The harness keeps the LLM iterating on the task towards the goal without manual intervention.

Loop Engineering

Loop engineering is a term that has only been popularized in the middle of 2026, and there is no single agreed definition. It is about efficiently steering the agent (driving the car) towards a final goal. If we continue our car analogy, it means defining the "traffic safety rules" and "traffic laws" for the agent to follow throughout the steps.

Examples of tasks that fall under the Loop Engineering category:

• Explicitly describing the definition of done, for example telling the agent "a build must pass after feature implementation"
• Applying critical thinking and decomposing a big feature into a few granular ones (as Claude likes to say: "Reduce the blast radius")
• Telling the agent "do not make assumptions, ask me if there is missing information or an architectural decision that needs to be made"
• Asking the agent to create a task list which it can follow on the way to the implementation (this is something that Kiro SDD implements)

Loop engineering is about steering the agent towards a goal

Have you done any of the above? Congratulations, you have been doing "Loop Engineering".

Until recently, loop engineering was the hottest buzzword in the context of agentic development, but as of August 2026 a new one is emerging: Graph Engineering. In essence, it is orchestrating multiple agentic loops from above to achieve complex tasks. (Can you think of a "car" analogy to describe what graph engineering is?)

As humans in the loop (graph?), we engage in harness, loop and graph engineering to make our agents more autonomous, efficient and precise, and to get meaningful results. Each time the final result does not meet the standard we want, this is where we as humans step in and improve the setup, so that next time the results are better.

Next time you are working with a coding agent, try to identify which layer you are working in. Are you setting up the harness, steering the loop, or orchestrating multiple loops?

Also if you have a nice car related analogy for graph engineering, feel free to share it!