Lots of fun debates on LinkedIn these days in the AI expert circles throwing words around that all too often don’t have a clean definition. But with all of us now having to roll out AI at enterprise scale, it makes sense to take a step back and sort out our thoughts: if it comes to AI, agents, and platforms, how can we think about platform engineering, and what’s a platform engineer's job in that context? In comparison to that, what is harness engineering? And finally, what is loop engineering?
Before we get started, let's do a brief first summary of all three terms and then dive deeper:
Platform engineering is the discipline of deliberately designing, building, and improving platforms for knowledge work, and treating them as products. In the agentic context, that mandate now covers the agentic platform: the tooling agents call, the paths that define what work looks like, and the agent infrastructure that runs and governs the fleet. The platform sets the rules everything else operates inside, whether it's identity, security, observability, or the criteria an agent's output has to pass. So platform engineering is the umbrella discipline that contains the other two.
Table 1: What are the things platform engineering, harness engineering, and loop engineering are responsible for tuning? What’s the scope, on what time scale, and what is it they don’t do?
Harness engineering is the craft of tuning the machinery of a single agent turn, from execution through to evaluation. The harness is everything around the model that turns intelligence into work: execution, context, capability, evaluation. Agent equals model plus harness. The model's weights are the one thing in a turn you cannot tune, so the harness is the whole surface you can. And that’s the reason why a decent model in a great harness beats a great model in a bad one. It is one agent's operating system, and a subset of platform engineering rather than an alternative: the harness runs one agent, the platform governs the fleet.
Figure 1: The map. Platform engineering is the discipline of building internal platforms for knowledge workers. With that, Platform Engineers are also responsible for all agentic platforms. The harness has a place inside these platforms. The loop runs through it.
Loop engineering is the craft of tuning what happens between turns: the gate verdict, the feedback that carries forward, the retry, and the stopping condition. Where harness engineering works inside a turn, loop engineering works across them. It’s like using the same machine, several times, in two time scales. The loop isn't a component you can buy or a container that holds the harness; it's the repeated traversal of the platform, drawing criteria from the path layer, tools from tooling, and retries on the harness. So loop engineering is also a subset of platform engineering, for the same reason: the loop runs on the platform's paths, tools, and gates.
Why does this matter?
Why do each of the three disciplines matter if it comes to AI adoption in the enterprise? To answer this question, let’s turn it around: assume you’d throw any AI at your raw enterprise setup. And let’s say you’d give it access to all your data and all your systems and then tell it to, let’s say, write custom software to optimize any given process. Would we then assume anything good and productive would come from that? We wouldn’t, for a variety of reasons:
Most current setups are a mess, with information in some employees' heads, poor documentation, and a general lack of access.
If the agent were to return something, it’s unlikely it’s correct on the first try. So how do we verify? What’s the definition of done?
It would be wildly insecure to let any system act unguarded and on its own. Who would be accountable for the actions?
These three points show that something needs to surround the model to guide and structure each turn and execution. And it makes you realize that in everything that happens inside the turn of an agent, only a small fraction is actually “artificial intelligence” at work. A big chunk is just deterministic wiring in the background. In late 2025, the Claude Code source code was leaked, and a paper found that the model did 1.4% of the lifting in every run, while 98.6% was the platform around it doing deterministic routing, like loading context, checking results, and evaluating outcomes.
This substrate around the model is what’s called a platform, and the discipline of building platforms is called platform engineering. We’ve made the argument before: there is no AI adoption in the enterprise without building an agentic platform.
Platform engineering is about building agentic platforms
The sum of all the systems, tools, paths, and infrastructure components that help agents do stuff productively, over and over again, is called an Agentic Platform.
Agentic platforms differ by business vertical; in the end, most verticals will likely have their own shade of grey, and we will see Marketing, Sales, Finance, and other platforms. For now, the most advanced teams are (again) software teams, as they are building Agentic Engineering Platforms (AEPs). Yet all agentic platforms show the same 3-layered architecture.
Figure 2: Agentic Platform (AXP). An enterprise-grade platform that helps manage large numbers of agents across many different verticals. The tooling and path spec differ per function. Everything below it is shared.
Let’s go through Figure 2 top to bottom. Tooling is one of the layers that changes per vertical: marketing's agents call HubSpot, finance's call NetSuite, development's call GitHub. Path specs define the work: a path turns a recurring intent into a repeatable route with standards, approvals, and a definition of done. This is where the agent.md files or even deterministic workflows live that the harness can consume. Of course, most paths differ by vertical too. In marketing, this could be a “launch campaign” path, in finance a “consolidate report” path, and in software development a “spin up ephemeral environment” path.
Finally, Agent Infrastructure is what runs the agents, and it is de facto identical for every vertical.
Harness engineering is about building the harness part of an agentic platform
For a single agent to run, you need more than the model. The model carries the intelligence; the harness adds everything that turns that intelligence into work on top. In the end, it’s usually made out of four components: execution, context (what the agent knows, including feedback), capability (the tools it may call), evaluation (the gates its output must pass).
Figure 3: Agent infrastructure band including the harness, governance, and model planes. The harness does the work. Governance makes it safe at scale. The model does the “thinking.”
One pass through these components, to assemble context, reason, act, and check, is a turn; an attempt, in plain language. Harness engineering is the art of enabling the machinery of a turn, everything from execution to eval. The model's weights are the one thing in the turn you cannot tune; the harness is everything you can. Look closely, and every component of the harness is a connection between the model and the platform: context feeds it data, capability hands it the platform's tools, execution sequences the steps and invokes them, evaluation checks its output against the platform's criteria. The practitioners' favorite metaphor is right: if the model is the processor, the harness is the operating system. The agent's operating system. And they are right about its leverage too: a decent model in a great harness beats a great model in a bad one.
But notice the second band in Figure 3 too. A harness can log its own turns. It cannot decide how an agent runs and which agent, issue their identities, or aggregate what a thousand agents did last Tuesday. Identity, agent security, and agent observability are fleet concerns, owned once, enforced everywhere.
Loop engineering tunes how to repeatedly run an agent until an outcome is achieved
Now let’s set things in motion and do a full turn of an agent run: An intent triggers the run, the correct path is loaded, and the necessary context is assembled. Then the first turn begins: the model reasons, picks a capability, the tool acts in the real world, and the gate evaluates the result against criteria the agent did not write for itself. On failure, the result enriches the context and the next turn begins, knowing what did not work. That’s a classical loop and during this loop all parts of the agentic platform are touched.
Figure 4: The loop wheel. The loop is the repeated execution of a path by an agent. The cycle repeats until the gate passes and the outcome is achieved.
The loop is not a separate thing the platform contains, or that contains the harness. Loop engineering is a way to tune all parts of a harness and, with it, the platform in order to retry until the definition of done is met. The platform is the control layer; the harness is machinery. The loop is the traversal of that machinery, repeated.
Figure 5: Loops allow for retries, essentially running, failing, and iterating until a threshold is reached and the definition of done is satisfied.
Loop engineering is the art of tuning what happens between the turns: the gate verdict, the feedback, the retry, the stopping condition. Harness engineering tunes within a turn. Loop engineering tunes between turns. Same machine, two time-scales. The cynics call agentic loops a stupidly expensive way of running gradient descent, and for ungated loops they are probably right: an agent that declares itself done burns tokens and converges by luck. The gate is what turns token burn into a system that gets measurably closer every turn.
And notice where the loop reaches: criteria from the Path layer, tools from the tooling layer, retries on the harness. The loop is not a component you can buy. It is a flow through the whole platform.
Figure 6: One turn of the loop, traced through Agent Infrastructure. The model reasons for 800ms inside the execution plane. Everything else is the system carrying the turn, and the dimmed governance band is the part you should not build yourself.
There is no productive use of AI without platform engineering, harness engineering, and loop engineering
The debate got the diagnosis right: what surrounds the model matters more than the model. It just stopped one layer short. Harness engineering is real and loop engineering is real, but both are crafts practiced inside something larger. Tune a turn, and you get a better agent. Tune what happens between turns, and you get an agent that converges instead of guessing. Build the paths, the gates, the identities, and the observability underneath, and you get an organization that can run thousands of them without losing track of what any of them did. That last part is platform engineering, and it's what your AI transformation actually rests on. Which is the uncomfortable part for anyone hoping to buy their way out of it: there is no enterprise AI adoption without an agentic platform, and no agentic platform without platform engineering.