Yuval Avidani
Author
"You write the agent, we run it." That one-liner from AWS sums up the word everyone's suddenly obsessed with this month: harness. If you've ever tried building a real AI agent, you already know the hard part isn't the AI itself, it's the loop that runs it. And that's exactly what the harness is here to solve.
Let's break this down slowly, because behind this one word is hiding the most practical shift in the agent world this year.
First, what even is an "agent loop"
Let's start from the ground up, because without this you can't understand the rest. An agent is software that gets a goal and decides on its own what steps to take to reach it. It thinks about what to do, picks a tool, runs it, looks at the result, and decides on the next step, again and again, until the job is done.
Think of a personal assistant you told: "schedule me a meeting with three people this week." It opens the calendar on its own, checks availability, sends invites, reads replies, and coordinates. That cycle, think then act then look at the result, is called the agent loop. And here's the catch: up until now, we had to code that cycle ourselves, line by line. That's called orchestration code, and it's most of the work.
So what is a harness
Now we can actually define it. A harness is the managed infrastructure that runs the agent loop for us, so instead of writing the loop in code, we just define three things: a model, a system prompt, and tools. You define them, and it runs right away, without writing a single line of orchestration.
Think of the difference between building an engine yourself versus getting one ready-made. We used to have to assemble the pistons ourselves: when to call the model, how to keep memory between steps, what to do when a tool fails, how not to lose context. The harness takes all of that mechanics and serves it up as configuration. AWS put it nicely: if the model is the brain, the harness is the body. Everything the brain needs to actually get work done in the real world.
Why everyone's talking about this exact now
Here's the fun part, the timing. On June 17, 2026, Amazon announced that the managed harness for Amazon Bedrock AgentCore reached General Availability (GA), meaning it moved out of preview and became a product you can actually rely on in production. The idea: just two API calls, one to define the agent and one to run it, no orchestration code and no server to build.
But AgentCore isn't alone, and that's exactly what turns this into a trend rather than one company's feature. Every major player has built this same approach: OpenAI Agents SDK, LangChain's LangGraph, Amazon's Strands, CrewAI, and Google ADK. They're all answering the same question: how do we stop rewriting the same loop from scratch in every single project.
harness vs framework vs runtime: don't get confused
Worth stopping here, because these three terms get mixed up and people use them wrong all the time. Let's sort it out, based on AWS's official definitions:
In short, the core difference is how much code we write: in a runtime, the loop is our code and they just host it; in a harness, the loop is managed and we just declare what the agent needs. A framework, like LangGraph, is the toolkit we use to build the behavior itself. One doesn't replace the other, they're different layers.
There's also a second use of the word harness worth knowing, because it's confusing: in the benchmark world, a harness is the code that runs the test on the model. Take SWE-bench, a test that checks whether a model can fix real bugs, it comes with a harness that takes the model's fix, runs it against the code, and checks if the tests pass. Same word, different context: one is a harness that runs an agent, the other is a harness that runs a test.
What this actually looks like in practice
So this doesn't stay abstract, here's what defining an agent through a harness actually looks like. Notice how little code this is, and how much of it is declaration rather than logic:
The point I want us to take from this: our value as developers shifts from writing the plumbing to writing the idea. Isolation between users, memory, monitoring, failure handling, all of that has been solved a thousand times already. When it becomes off-the-shelf commodity, we're freed up to focus on what actually makes our agent different: what it knows how to do, and for whom.
Bottom line, as I see it
So let's wrap this up in a format I like. A harness is managed infrastructure that runs the agent loop, for developers who want to deal with the agent's logic and not with the plumbing underneath it. You define a model, a system prompt and tools, and it takes care of the rest.
In my eyes, this is exactly the kind of move that's worth more than a model upgrade: it doesn't make the model smarter, it lowers the barrier to entry down to the floor. Suddenly someone who isn't an infrastructure expert can ship an agent. The catch, and this matters: when we give up control of the loop, we also give up flexibility. There are cases where we'll specifically want to write the orchestration ourselves, because our need is unique. There's no "better" here, there's a new abstraction layer that fits most use cases.
So here's the question I'll leave us with: if building an agent becomes a matter of a three-line declaration, what's the first thing we'd spin up tomorrow morning?