What did we build?
A harness: the system around a model that decides what it is told, what it remembers, which tools it may use, and how its work is checked. Ours improves itself. It learns from how our engineers work with agents, keeps what it learns as memory, and gets better at the work it is given, in web development, software engineering and QA testing.
We’re not the only ones working on the idea. Google Research published Harness², an agent that rewrites its own harness while it works, and we took it apart in an earlier post.123 Ours learns from people rather than from its own runs alone.
The model inside matters less than people think. Two teams with the same model get very different work out of it, and the difference is almost all harness: what the agent is told before it starts, what it is shown when it is wrong, and what it is asked to prove before it says it is done.
Where did it learn from?
From 35 software developers on our team, working the way they always do. We collected their chats with agents, the suggestions they made, the feedback they gave when a result was wrong, and the scenarios they wrote down: each one a situation, the result they wanted, and the prompting that got them there.
That last part is the valuable one. A chat on its own says what someone asked. A scenario says what good looked like, what the agent did first, why it was not good enough, and what finally worked. Thirty-five people produce a lot of those, about the same few hundred situations, from different angles.
| Part of a scenario | What it holds |
|---|---|
| The situation | The project, the task and what the engineer was trying to do. |
| The result wanted | What good looked like, in the engineer’s own words. |
| What the agent did first | Its first attempt, before anyone stepped in. |
| The feedback | What the engineer said was wrong, and why. |
| The prompting that worked | What finally got the result, word for word. |
| The check | How we can tell, next time, that the result was reached. |
How does a scenario become a pattern?
We read the scenarios side by side and looked for the ones that kept coming back. When several engineers corrected an agent the same way, in different words, on different projects, that correction was a pattern: something the agent should have known before anyone had to say it.
Each pattern is kept with what it is for, the scenarios it came from, and the check that proves it held. A pattern with no check is only advice, and advice is the first thing an agent forgets. So wherever we could, we turned a pattern into something a machine can measure.
How does it improve itself?
In a loop. The agent does the work, the work is checked against the result the scenario asked for, and the gap is compared with the patterns it already has. What closed the gap is kept. What did not is revised, or retired. Then the next piece of work starts from a slightly better place.
Two rules keep the loop honest. A model gives opinions, and code decides: a pattern is kept because a test, a measurement or a person said it worked, never because the model said so. And every lesson keeps its evidence, so a lesson learned from one bad afternoon can be found and taken back out.
What does it do better?
Polish, mostly: the part of the work that separates done from finished. In web development that is layout, spacing and text measured at every screen width, not judged from a thumbnail. In software engineering it is small steps, tests written first and run, and no claim that something works without the output to show it. In QA it is the case nobody thought to try.
One example from our own pages. An engineer was tired of headings that broke badly on phones and said so. That feedback became a pattern, and the pattern became a check that opens a page at seven widths, from a wide desk to a small phone, and measures every line: a word left alone, a label that wraps, a name split mid-word, a box with an empty slot. The agent now runs it before it calls any page done, on every project.
Why do we run phone farms?
Because most people meet software on a phone, and a phone in a browser window on a desk is not the same thing. We run several phone automation farms: real devices, driven by automation, where the work is run the way a person would run it, tap by tap, on the screens and networks people actually use.
For QA that closes the last gap between what passed on a developer’s machine and what a customer sees.
Does it replace engineers?
No, and it was never meant to. Everything it knows, it learned from engineers, and the point is to take the repetitive part off their desks: the second pass, the checklist, the case that is easy to forget at six in the evening. The judgment, the design and the decision to ship stay with people.
Can we use it for our team?
Yes. The same approach works on any team’s own way of working: we gather how your people work with agents, turn what they keep correcting into patterns and checks, and build the harness around your code, your tests and your devices. It runs where your code already lives.
Talk to us about building it around your team.
References
- Xu, Chen, CuiZhu, Dalvi Mishra, Ming, Yu, Han, Lee and Pfister, “Harness²: Recursive Agent Harnessing for an Open World,” arXiv 2610.14224, 2026. arxiv.org
- google-research/harness2, the code, Apache 2.0. github.com
- subinternal Research, “Inside Harness², the agent that rewrites its own harness,” October 2026. subinternal.com