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. When a harness is worth building 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: Runs: one execution of the workflow, start to finish. Tasks: the steps inside a run. Tools: the adapters the agent may call. Artifacts: what the run produces (a ticket, a diff, a summary). 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 same idea, from the consumer side 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: Does it report progress, or go silent? Does it ask before important actions? Can you stop it? 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. Why reliability makes this non-optional 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. A starter checklist If you're thinking about wrapping an agent around one of your own workflows, here's the list I'd start with: Write the success criteria first. The personal-agent roundup puts it simply: write down a task and what success looks like. If you can't, you're not ready to automate it. List the tools, then cut half. Every tool is another way to fail. Start read-only. Decide where it must ask. Payments, sending messages, deleting anything. Log every run as an artifact. You'll need it to debug, and to measure whether the agent saves time once you count the minutes spent explaining and checking. Track cost per run. Retries and latency add up, and a smaller model inside a tight harness is often enough. How I studied this 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.