The harness is the product

Models keep getting better, and they're available to everyone. What isn't available to everyone is the harness: the tools, context and checks that let a model do real work inside a specific product. That's where the difference is now, and it's why I think building AI-friendly harnesses is one of the biggest product opportunities right now.

The same model, two results

Give a strong model a vague task and a pile of screenshots, and you get something plausible. Give the same model a tool with clear actions, a way to look at its own output and a human who can step in, and you get something you'd ship.

The model didn't change. The harness did.

modelharnessproduct

1. 01Verbssmall, named actions: add_frame, set_caption, render
2. 02State you can readthe agent can inspect what exists before it changes it
3. 03Eyesscreenshots, previews, test output: the agent checks its own work
4. 04Guardrailspermissions, dry runs, undo, limits on what can be deleted
5. 05A human seata live view you can watch and take over at any moment

Five layers

1. Verbs

Small, named actions that match how an expert thinks about the work. For App Store screenshots that's add_frame, set_caption, set_background, render, not one giant make_screenshots(options). Small verbs let the model plan, recover from mistakes and change one thing without redoing everything.

2. State it can read

Before changing something, the agent needs to see what's there: which frames exist, what each caption says, which layer is on top. A harness that only lets an agent write, never read, forces it to guess.

3. Eyes

The single biggest upgrade: let the agent see its own result. A rendered screenshot, a preview frame, a test report. Then it can do what any good designer or engineer does: look, notice what's off, and fix it before saying "done".

4. Guardrails

Permissions, dry runs, undo, and limits on anything destructive. Guardrails aren't there because the model is bad. They're there so you can let it run longer without watching every step.

5. A human seat

A live view where a person can watch the work happen and take over at any moment, with the agent picking up from the new state. This turns "the AI did something" into "we did it together", which is what people actually trust.

Why this is a product, not plumbing

I build tools this way. Shelf designs App Store screenshots and Cutscene makes launch films, and both are built for Claude Code and Codex first:

• The agent works through the tool's own actions over MCP, not by guessing at a UI.
• The agent renders its work and looks at it before handing it back.
• Everything happens on a canvas you can watch and grab.

Building for agents tends to make a tool better for people too. Clear verbs make clear buttons. A render-and-check loop is a preview everyone can use. Designing for a user who can't guess removes the guessing for everyone.

If you're building a product today

Ask what your product would look like with an agent as a first-class user:

• Can an agent do everything a person can? If only the UI can do something, agents can't help with it.
• Can it see the result? If not, it can't check its work, and neither can your users' agents.
• Is every destructive action explicit and undoable? That's what lets people say yes to automation.
• Is there a seat for a human? The best experience is the agent doing the hundred small steps, with a person steering.

Products that answer yes will be the ones people's agents reach for. The rest will be scraped, screenshotted and guessed at.

The short version

• Models are becoming a commodity; the harness is where products differ.
• Give agents verbs, readable state, eyes, guardrails and a human seat.
• Building for agents tends to make the product clearer for people too.

This series continues with how I build with AI day to day.