What an agent harness is, and the one that won me a challenge

October 8, 2026 was my birthday. I spent it in class. That same day, Ricardo Celis announced the results of his harness challenge at Gradiente School of Engineering in Colombia. We won.

The challenge: build your own harness and show it working. Mine was a robot that tests the checkout of the online store I run with my wife.

Before I explain how I built it, let me answer the question I got most afterwards: what is a harness, exactly?

A harness, in plain English

Think of a climbing harness. It doesn’t make you climb. It makes sure that if you slip, you survive.

AI works the same way. A model like Claude can write code, read documents and make small decisions. The harness is everything around it that makes that work safe, repeatable and verifiable:

• Instructions: what it must do and what “done” means.
• Tools: what it’s allowed to use. A browser, a database, files.
• Limits: what it must never touch.
• Tests: how we know it did the job right.
• Evidence: what it leaves behind for a human to review.

The word gets used in two overlapping ways. In software testing, a test harness is the setup that runs tests automatically. In AI agents, the harness is the frame that controls the agent. My project is a bit of both: a testing robot built and governed with agents.

The problem

I run an online perfume store. Every change, a price, a line of copy, a new section, can break checkout. And when checkout breaks, you lose sales without ever knowing.

Checking it by hand on desktop and mobile after every change is slow. Honestly, I almost never did it.

What I built

With a single command, the harness:

1. Spins up a test copy of checkout. Never the live store.
2. Walks through it on desktop and mobile, like a real customer would.
3. Fills the form with synthetic data, leaves marketing opt-ins unticked and places the order.
4. Leaves a video, a trace and a summary in Spanish of everything that happened.

All in about 65 seconds. In the demo: 20 of 20 checkout cases green, plus 60 unit tests.

What makes it worth anything: the negative test

A robot that always says “all good” proves nothing. How do I know it’s actually checking?

I plant a bug on purpose. In my case, marketing opt-in boxes come pre-ticked, which a trustworthy store should never do. The robot has to catch it on both screen sizes.

If it doesn’t catch it, the robot is useless. It caught it.

For me, that’s the core idea of the whole project: AI doesn’t need more freedom. It needs clear rules. And a way to prove it follows them.

My harness’s hard rules

• It never touches the live store. Test copy only.
• No real purchases or payments. Synthetic data only.
• It can’t claim “done” without evidence. No video, trace and summary, no delivery.
• It tests itself with the planted bug.

I was also upfront in the video: the robot tests a copy with fake data. It doesn’t certify real payments or the live site. I think that honesty helped. Judges, like buyers, trust you more when you’re clear about what your system doesn’t do.

How I built it

I built it with Claude Code and Codex, on Playwright, a tool that drives a browser the way a person would.

My job wasn’t writing every line. It was defining:

• What the robot should check.
• What it must never touch.
• When the job counts as done.
• What evidence it has to leave.

The agents wrote the code and the tests. I reviewed, ran everything and recorded the video.

Build your own in five steps

1. Pick a flow that costs you money when it breaks. Checkout, sign-up, booking.
2. Write the limits before the code. What it can’t touch, which data it uses.
3. Define the evidence. What would make you believe it? A video and a plain-language summary work very well.
4. Add a negative test. Break something on purpose and confirm it gets caught.
5. Make it one command. If it’s a hassle to run, nobody will run it.

What came next

Using the same idea, I built a second reviewer that checks the live store for design, content and SEO issues, and tests the purchase flow right up to payment.

The harness video also became one of my best-performing posts on LinkedIn, and a lot of people asked what a harness was. Hence this post.

Thanks to Gradiente and to Ricardo Celis’ class for pushing us to build, not just listen.

Why this matters beyond my store

Every serious AI deployment needs a harness: limits, evals, evidence and a human checkpoint. Whether it’s a checkout robot or a customer-facing agent, the pattern is the same. It’s how I approach every system I build for clients.

See the full case study, or message me on LinkedIn if you want one for your store, or someone on your team who builds this way.