Harness Engineering: How AI Agents Are Reaching Their Golden Era

How the Last Four Years Shaped This Moment and What Comes Next

Before we get into Harness Engineering, allow me to explain what led me down this road.

I was recently talking with a colleague about the AI agents available to our team inside a highly regulated financial services environment.

She asked a perfectly reasonable question: if one of our Microsoft Copilot agents sees that an approval email has been sent, why can’t it just go update the downstream system on its own?

My answer was intentionally simple.

“Our agents have brains and voices. What they don’t have yet are arms and legs.”

That was my very simple way of saying that we don’t yet allow personal agents to take those actions autonomously in our environment.

The agents already have instructions, context, and some orchestration.

What they do not currently have in our environment for individual users is the full action layer: the tools, permissions, triggers, system access, and execution pathways required to observe an approval and autonomously change another enterprise system.

Her next question was obvious.

“When do we get the arms and legs?”

I explained that those capabilities are arriving gradually while the risks, controls, and operating boundaries are worked through.

Microsoft and other technology companies have these capabilities already, but for very good reasons, many enterprises are being cautious with their deployment strategy.

Did I mention that I work in a highly regulated financial services environment? 😉

The conversation with my colleague stuck with me because the question underneath her question was much bigger.

How did we get from ChatGPT answering questions to AI agents that can actually do work?

And how did that happen in barely four years?

Let’s take a trip down memory lane. Shall we?

Four Years in Fast Forward: Prompt to Context to Harness

When ChatGPT arrived in late 2022, the interaction model was simple. You typed. The model answered.

I still remember when my friend Ben introduced me to ChatGPT at the bowling alley like it was yesterday. (See The Evolution of The Prompt)

The early constraint back then was not just intelligence. It was working memory.

Small context windows meant the model could only keep so much of the conversation, instructions, and source material in view at once.

So that forced us to get very good at Prompt Engineering.

The question was: How do I say the right thing to get the best answer?

Then the problem changed.

As models gained larger context windows and access to retrieval, tools, code execution, and external systems, the challenge became deciding what information and capabilities the model should have at the moment it needed them.

RAG, or Retrieval-Augmented Generation, allowed an AI system to look up relevant information from trusted documents, knowledge bases, or databases before answering, rather than relying only on what the model learned during training.

Tool calling gave the model the ability to use external capabilities when needed, such as searching a database, running a calculation, sending a request to another system, or executing code.

MCP, or Model Context Protocol, introduced a more standardized way for AI systems to connect with external tools, applications, and data sources, reducing the need to build a custom integration for every connection.

Context compaction and summarization helped long-running agents compress what had already happened, preserve the important decisions and state, and free up working memory for what came next.

Together, these techniques shifted the challenge from writing better prompts to designing the right information environment around the model.

That became Context Engineering.

Anthropic documented the next problem clearly in November 2025: even with context compaction, long-running agents struggled when work crossed multiple context windows.

Its solution used initializer agents, progress files, feature lists, Git history, and testing so a new agent session could pick up the work without starting from zero.

That is already recognizable as harness thinking.

Here are the two key distinctions I want you to remember for now:

Prompt Engineering asks what we should tell the model.

Context Engineering asks what the model should know.

By late 2025 and early 2026, the next layer was coming into focus: Harness Engineering

Harness Engineering asks a much larger question:

What environment does the agent need in order to reliably do the work?

2026: The Harness Gets a Name, Then Becomes the Product

The ingredients existed before 2026. Coding agents, tool use, memory, subagents, sandboxing, browser control, RAG, MCP, and persistent runtimes were already converging.

Then the OpenClaw viral moment of late January and early February 2026 made the whole thing visible.

Peter Steinberger says the project began as a weekend experiment in November 2025.

By late January, the newly named OpenClaw had crossed 100,000 GitHub stars and drawn two million visitors in a week. More important than the numbers was what people could suddenly see: the model was only one part of the system.

The persistent gateway, messaging channels, tools, memory, Skills, files, browser, permissions, and runtime around the model were what made it feel like a working personal agent.

OpenClaw did not invent Harness Engineering.

But it did bake one hell of a cake from all the available ingredients.

Then the vocabulary caught up.

On February 5, Mitchell Hashimoto wrote that he had “grown to calling” his practice Harness Engineering: when an agent makes a recurring mistake, improve the surrounding instructions or verification tools so the same failure becomes less likely next time.

Six days later, OpenAI published Ryan Lopopolo’s account of a team building roughly one million lines of software with zero manually written application code.

OpenAI is obviously a vendor with a product to sell here, but the engineering lesson is still important.

Human work moved up a layer. Instead of primarily writing code, the team designed environments, specifications, tools, constraints, and feedback loops so Codex could execute reliably.

By April, The New Stack captured the market shift in six words:

“The harness is now the product.”

By May, NVIDIA, another vendor actively selling into this market, was describing Claude Code and Codex as general-purpose orchestrators that could load specialized capabilities as Skills.

Its framing was equally telling:

“The harness doesn’t need to own the research pipeline.”

That is a big architectural shift.

The harness was becoming a platform.

I Was Already Building Harnesses. I Just Didn’t Call Them That Yet.

This is where the story became personal for me.

In late January I bought a Mac Mini and spent an entire weekend planning my first autonomous personal agent, Cooper Tars.

Before I worried about clever prompts, I worried about two things: how I was going to secure it and how I was going to control the cost.

Cooper went live on February 1. I documented the whole beginning in The Cooper Logs

Two months later I brought Murph online on the same machine, but deliberately gave her a different harness.

Cooper ran on OpenClaw and Node.js with Claude through Anthropic.

Murph ran on Hermes and Python with a different model path through OpenRouter.

Different framework. Different runtime. Different configuration. Different service. Different failure domain.

My goal was resilience through diversity, not duplication.

Looking back, I was doing Harness Engineering before I had a clean name for it.

The agent was never just the model.

The useful system was the model plus the environment I built around it.

The Harness Maintenance Tax

Ownership has a price, and boy have I learned this the tough way.

I call it The Harness Maintenance Tax.

When you own the harness, you also own the upgrades, dependency drift, broken authentication, API changes, credentials, permissions, memory tuning, gateway health, integrations, cost controls, and the occasional Friday night surprise.

You also have to deal with the looks from your wife after you finally get to bed at 1am after you told her at 10:00pm that you’ll be there in 5 minutes.

In May, Cooper was twenty-two OpenClaw releases behind. I finally upgraded him and hit three separate filesystem permission failures.

Then the upgrade tool offered to apply “recommended defaults.”

Buried in the proposed change was a configuration update that would have removed environment values supporting Cooper’s Google Workspace authentication.

I caught it before accepting the change.

Full story here: Tonight Jaime Decided to Go Full Cowboy Mode Upgrading OpenClaw

That night ended successfully, but it crystallized something I had been feeling for months.

Open-source, self-operated agents give me extraordinary control.

They also turn me into the infrastructure team.

Something I really didn’t want to sign up for. 

That tradeoff matters if autonomous agents are going to move beyond enthusiasts and builders.

What Comes Next: Don’t Build the Harness. Rent It.

This is why Grok Bot caught my attention.

SpaceXAI launched Grok Bot on August 11 as a managed team of persistent agents.

According to its own product documentation, each user gets a managed cloud computer that the user’s Bots share.

The Bots can work in browsers, filesystems, terminals, connected tools, and MCP servers. They can collaborate with each other, retain working context, learn workflows, and run recurring routines.

This is SpaceXAI describing its own product, so the real-world quality still deserves independent testing.

Remember that as of this writing, the product only launched last week.

But the product direction is hard to miss.

The biggest change may be the user experience.

The builder-era pattern looks like this:

Design workflow → configure agent → debug → deploy → use

Grok Bot is aiming for something much closer to:

Give agent work → correct it → agent learns → save what worked → automate it

Its docs explicitly recommend starting with a one-time task, making it reliable, saving the method as a Skill, and only then automating it as a Routine.

That feels much more natural for ordinary knowledge workers.

You do not start by becoming an agent engineer.

You start by delegating.

I just started my new SuperGrok Plus subscription and will be taking these agents out for a spin. I will report back on my experience here soon.

Meanwhile, here is a side-by-side comparison of an owned agent harness vs a rented agent harness:

OpenClaw vs. Grok Bot

	OpenClaw-style ownership	Grok Bot-style service
Harness	You own and shape it	Vendor manages most of it
Infrastructure	Your machine, homelab, or VPS	Managed persistent cloud computer
Customization	Deep and open-ended	Guided through Bots, Skills, connectors, and routines
Maintenance	Mostly yours	Mostly vendor-managed
Control	Maximum	More abstracted
Time to value	Higher setup cost	Designed for immediate delegation
Best fit	Builders who want infrastructure ownership	Users who want outcomes without operating the stack

OpenClaw made the harness visible.

Grok Bot points toward making the harness disappear again, this time behind a subscription.

That may be the next important abstraction layer in agentic AI:

Harness-as-a-Service.

Or, put less politely:

Rented digital labor.

Back to the Arms and Legs

My colleague asked when our agents would get arms and legs.

Four years ago, the hard part was getting the brain to produce useful language.

Then we learned to manage what the brain could see.

Now we are engineering the body around it: tools, memory, permissions, runtimes, feedback loops, specialists, and environments that let an agent carry work forward instead of merely talking about it.

The first Harness Engineering revolution taught us how to build that environment around the model.

The next may make it unnecessary for most people to build the environment at all.

I am not planning to shut down Cooper or Murph. Quite the opposite.

My next Build Lab experiment is becoming clearer: keep learning what ownership teaches me, while testing where a managed harness can remove work that no longer deserves my time.

That is the comparison I want to run next.

Because the golden era of AI agents may not be defined by who has the smartest model.

It may be defined by who builds, or rents, the best place for that intelligence to work.