Harness engineering inside the app: the runtime that lets an agent drive native screens

Everyone builds a harness around their own desk. The unclaimed move is a harness inside the product you ship, the registry and runtime that let an agent render native UI it can trust.

Most of the talk about harness engineering points at one place: the developer's desk. Coding agents, research assistants, second brains. A model wrapped in enough structure that it can act in your work instead of guessing about it. That is real, and it works. But there is a corner almost nobody is standing in, and it is the more interesting one. A harness inside the app you ship, not just around the person building it.

Here is what that means, and why generative UI is exactly where it pays off.

First, the thing the desk version got right

A harness is everything around a model that lets it work in a real context: standing rules, memory, access, standards. The model is the swappable part. The structure around it is the edge. People found this out building for themselves: stop hand-feeding the model context every session, and give it a scaffold it reads on its own.

That lesson does not stop at the desk. Point the same idea at a running app and it changes what the app can do.

A harness for a product, not a developer

A coding harness is a CLAUDE.md and some memory files. A product harness is different furniture for the same idea. It is the structure that lets an agent act safely *inside* a live mobile app: a validated component registry the agent must draw from, a streaming runtime that survives on a real phone, and an agent that drives screens instead of a chat box.

The payoff is the thing hard-coded onboarding cannot do. Instead of the same six questions for every user, a model wrapped in that structure can render a different flow per user, and you can trust the result because the harness constrains it. The agent does not get to invent a component. It picks from a registry you validated. That constraint is the whole point, the same way a developer's memory file constrains what the coding agent assumes.

Where the trust comes from

An agent that emits UI is only safe if something checks what actually rendered. That is the product-harness version of "the model is not the point." The model proposes a screen; the runtime renders it natively and the registry decides whether each piece is allowed to exist. A component the model invented does not silently ship as an empty view, it gets rejected before a user sees it.

This is what Wire RN is: the registry, the streaming runtime, and the agent-to-UI layer that turns a model's output into a real native screen with guardrails around it. The mechanics are in how generative UI works on React Native and the Wire RN SDK overview, and the agent protocol side in A2UI on React Native.

This harness rots too

The maintenance lesson carries over. A component registry drifts as the app grows, and a registry that lists components that no longer exist is a stale memory file with a UI attached. The runtime has to stay honest about what it can actually render on a current device. Untended, a product harness fills with the same confident lies a neglected memory folder does, except now the user sees them. Prune the registry, keep the runtime tested. Owning it does nothing; maintaining it is the return.

The unclaimed corner

The people naming harness engineering are right. They are mostly looking at their own desk. The more interesting move is putting the harness inside the thing you ship, so the app itself runs a model it can trust. That is the corner generative UI sits in, and it is where Wire RN is built to live.

*First published on Code Meet AI.*