Agent Harness explained in 8min..

0:00Agent harness is just one of those terms

0:01that is so confusing to understand

0:03because of how broad and also specific

0:06the term harnessing actually is. A

0:08common rhetoric out there is that

0:09harness refers to an environment for the

0:12agent, but that still doesn't really

0:13help us understand what it is and what

0:15it isn't. How exactly is harness

0:17engineering different from prompt

0:19engineering and context engineering?

0:21Welcome to Kayla Bright's Code where

0:22every second counts. Quick shout out to

0:24Cursor, more on them later. To put it

0:25simply, harness engineering actually

0:27existed before the term harness was

0:29coined around early 2026. Shortly after

0:32the release of ChatGPT in 2022, we were

0:34dealing mostly in the context window of

0:374,000 tokens. And this small context

0:39window really limited our ability to do

0:41anything substantial with it. And we

0:43could build an agent around this, but

0:45what we found is that simple prompting

0:48ChatGPT to get what we want to do just

0:50wasn't good enough. So, the question

0:52started to emerge on how to recycle this

0:55small memory space to effectively do

0:57more with less. So, we quickly expanded

1:00from prompt to context engineering by

1:03using various techniques like tool

1:05calling, MCP, and rag for the purpose of

1:08managing the context window more

1:09efficiently. Tool calling allowed us to

1:11explore the repository and read only

1:14specific files that are relevant to the

1:16task at hand and creating actions

1:19externally. MCP allowed vendor-specific

1:21features to be added on top of the

1:23model. And finally, rag allowed custom

1:26databases to be connected for an

1:28on-demand data to be available at any

1:30time. All these gave birth to a new era

1:33of agents, mostly in coding agents.

1:35Cursor, WinServe, Cline, Rue, and Aider

1:38are all examples of early players that

1:41adopted tool calling for context

1:43engineering. And they were really good

1:44tools that got the job done. And while

1:47all of this work was undergoing, the

1:49underlying models actually evolved and

1:51context window started to grow as well,

1:53which meant that coding agents started

1:55to be able to do longer duration tasks.

1:57And that's exactly what we were seeing.

1:59People started to ask these coding

2:01agents to work on features and bug fixes

2:04at a bigger and bigger scope. And

2:06suddenly, context engineering that

2:08autonomously loaded proper context and

2:10take necessary actions gave these coding

2:13agents more and more ability to work on

2:15more complex tasks. But even this had

2:18its own limits, because as the duration

2:20of tasks got longer and we asked the

2:23coding agent some incredibly long tasks

2:25like clone an entire website, a simple

2:27prompt engineering will give you a very

2:29sketchy website because it can only

2:31respond in one shot. And even with

2:33context engineering, the result you got

2:35was not that great given the huge scope

2:37of the task. Not because context

2:39engineering was necessarily bad, but

2:41because you have symptoms like this

2:43where the website will be partially

2:45finished and some buttons would just not

2:47work and features aren't really tested

2:50all the way through. And one major issue

2:52with context engineering was that we

2:53typically use context summarization to

2:56essentially keep shrinking down the

2:58context as it was topping up. So, if the

3:01task that we gave to an agent took,

3:03let's say, 12 hours, as the context

3:05window started to fill up, it would

3:07summarize its context to shrink it and

3:09continue working on them without having

3:11to run out of context window. So,

3:13effectively, the agent was bound by its

3:15own ability to properly summarize its

3:18previous work. And that's why you see

3:20tasks that are either half completed or

3:22not even attempted at all. If context

3:25started to fill up mid-task, it would

3:27summarize and assume the task is already

3:29finished in some instances or

3:31oversimplify the task and assume some

3:33features are completed and verified when

3:36it really wasn't. So, as much as this

3:38elastic way of self-managing the context

3:41window gave the appearance of ability to

3:43work on longer-range tasks, it really

3:46wasn't all that effective. Now, this

3:48narrative I'm putting out here is an

3:49overview of what happened in the past,

3:51Meaning, people had been experimenting

3:54with different ways to get around this

3:56problem by implementing sub agents for

3:58hierarchical context management or even

4:00swarms of agents where you deploy

4:02multiple agents with their own context

4:04window. So, we were already converging

4:07towards a point of harnessing the

4:09underlying agents. And as you can see,

4:12having a better orchestration layer and

4:14having a better execution environment

4:16and better context management are all

4:18ingredients that we needed to master for

4:20harnessing the agent. And this is when

4:23the concept of harnessing an agent or

4:25agent harness started to emerge and

4:27officially coined the term in early

4:292026. And while you can certainly make

4:31the argument that harnessing is a

4:33buzzword, it does capture the essence of

4:36something transformative that was

4:37happening in the AI industry. So, the

4:39question is, how is harnessing an agent

4:42really different from what we've seen

4:43before? But first, a quick word from

4:45Cursor. I'm always trying to build on my

4:47websites, but not only do I have

4:49multiple devices that I have to keep

4:50track of, but I also want to keep

4:52working on them on my browser or my

4:54phone without having to set up the

4:56entire project on my devices. I use

4:58Cursor for that reason. For example, I

5:00can see that the models tab on my

5:01website is already behind in information

5:04since OpenAI released newer models

5:06since. So, I can just spin up Cursor

5:08locally to keep this up to date. And

5:09while the agent is working on that, I

5:11can concurrently fix different features

5:14at the same time, spawning multiple

5:16agents with their own context as needed.

5:18Pretty cool, but I want to raise the

5:19bar. With cloud agents, I can actually

5:21have this entire thing run on cloud

5:24instead of my desktop, which means I can

5:26just close Cursor and the job will

5:28continue on without my machine and

5:30create a pull request once it's done.

5:31Pretty cool, but I want to raise the bar

5:32again. I can integrate with Slack to

5:34send my feature requests to Cursor and

5:37it'll also run the cloud agent to get

5:38the job done and ping me once it's done

5:40with a PR. Pretty cool, but now I want

5:42to raise the bar again. Now I want to

5:44take this website and somewhat run it

5:46autonomously because I don't want to

5:48manually check for new information, I

5:50can add automation in the cloud to check

5:51daily for new model releases, and Cursor

5:54now keeps my website up-to-date

5:56autonomously. One of the most critical

5:57changes that happened with the rise of

5:59harness engineering was the idea of

6:01loops. By stepping away one layer above

6:04context engineering and essentially

6:06looping the agents in a loop where at

6:08each iteration they have a fresh clean

6:11set of context but under a strict rule

6:13of how the agent should start and finish

6:15its task, we started to see an

6:17incredible result by putting the agent

6:19under this very environment. One of the

6:21primary example is Raw, which took over

6:23the internet given how effective it was,

6:26but more importantly, just how simple

6:28the architecture was underneath. One

6:30clarification to be made here is that

6:32harness engineering doesn't necessarily

6:34deprecate context engineering and it

6:36certainly doesn't deprecate prompt

6:38engineering. If you peek below

6:39open-source coding agents like Klein,

6:41you see that their system prompt is

6:43still largely driven by a well-written

6:46prompt. So, prompt engineering is still

6:48used but a much smaller component in

6:50comparison to the system as whole. So,

6:53prompt engineering reminds the coding

6:55agents who the agent is and gives them

6:57the persona of a coding agents. In the

6:59layer above that is context management

7:01and context engineering. So, harness

7:03engineering effectively leverages both

7:06prompt and context engineering. It's a

7:08shift away from relying on these two

7:10approaches but a paradigm change on the

7:12environment that puts the agent into

7:15series of steps where typically you

7:17start by generating a large requirement

7:19file and then looping each task and

7:22selecting only one task to be completed

7:24from the document. And it tests and

7:26documents each steps and this loop

7:28continues on iteration after iteration

7:30until the entire step is finished. And

7:33at each iteration they're given a fresh

7:35set of prompt and fresh set of context.

7:37You see this kind of architecture

7:39mirrored in Raw's documentation as well.

7:41Where first starts with creating a

7:43production requirement document, which

7:45gets outlined into a JSON file, and it

7:47goes into a loop implementing feature

7:49after feature until completion. And you

7:50can see just how simple this entire

7:52architecture is when you look at how

7:54small the repository really is. Same

7:56thing for Anthropic's simple

7:58demonstration of harnessing when we look

7:59at their repository. Similar story here,

8:02lightweight and simple environment. In

8:04fact, many coding agents now have

8:06already adopted this harnessing layer

8:08directly inside the application.

8:10Although each of them implemented their

8:12own way of harnessing their agents.

8:13That's why you're seeing so many

8:15companies talking about harnessing layer

8:17these days because of how effective it

8:19really is.