Harnesses for Personal AI Agents: The Code Around the Model

Ask people which personal AI agent to use and the debate quickly turns to models: which is smartest, cheapest, or remembers the most. After working through a handful of recent podcast episodes about agents, I've come to think the better question, for builders and curious users alike, is a less glamorous one. What sits around the model?

Claire Vo gives the cleanest definition I've heard, in an episode of How I AI about building with the Claude Agent SDK: "A harness is some code around an AI agent that makes it more effective." It's not a framework or a product category. It's the scaffolding that decides what the agent sees, which tools it can call, and what counts as done.

Vo's rule of thumb is practical. You don't need a harness for one-off questions. You need one when the same workflow keeps coming back with the same setup and the same expected outcome. Her example is bug triage. A Sentry error comes in. Someone has to read the stack trace, find the related code, check recent deploys, open a ticket and maybe draft a fix. A general chat assistant can help with each step, but you re-explain the context every time.

Her harness wires the agent to the services the job actually touches: Sentry for the error, Linear for the ticket, GitHub for the code, Vercel for deploys. She also gives it a small terminal UI so a human can follow along. The architecture is four plain nouns:

The idea underneath is constraint. In her words, these agents "can help us solve very, very specific problems by constraining that work." A narrower agent with the right tools often beats a brilliant agent with no boundaries.

The harness idea shows up again, in different language, in conversations about consumer personal agents. A topic roundup on personal agents that I've been reading suggests a test for any new agent. Give it a first task with a checkable outcome and watch three things:

These are harness questions. Progress reporting is an artifact, asking before acting is a permission rule inside the tools layer, and a stop button is part of the run.

Greg Isenberg makes a similar point from the merchant's side. He describes trust as a ladder: first you let an agent research, then prepare, and only later pay. Most of the friction sits on the "pay" rung. His own setup gives the agent a goal, a few rules, and a spending threshold. In one example, reordering a household filter, the agent has to check with him before spending more than about fifty dollars. That threshold is a one-line harness, and it does more for safety than any amount of prompt engineering.

Back in 2024, on The Ezra Klein Show, Dario Amodei said agents need very high per-step accuracy, around 99.9%, because errors compound across long chains of actions. Ninety-five percent per step sounds great until a task has twenty steps.

You can wait for models to get there, or you can shorten the chain. A harness shortens chains: it hands the agent pre-fetched context instead of making it search, it checks outputs between steps, and it stops at the points where a human should look. Amodei also observed, in a 2025 conversation with John Collison, that models will make mistakes far less often than people, "but they'll be stranger mistakes." Strange mistakes are exactly what deterministic checks around the model are good at catching.

If you're thinking about wrapping an agent around one of your own workflows, here's the list I'd start with:

None of this came from one source. I compared several long conversations, and the fastest way to do that was to read them rather than replay them. When I want to pull a definition or a quote out of an hour-long show, I transcribe a podcast episode and search the text for the moment I half-remember. Then I go back to the audio to confirm the wording before quoting it. That habit matters with agents too: verify before you act.

If you've built a harness for your own work, whether it's for triage, research or inbox cleanup, I'd love to hear which constraint made the biggest difference.