--- title: "Shipping a high-accuracy AI agent: what to prioritize, what to ignore" description: "The gap between a 95% agent and a flaky demo is the harness, not the model. What actually raises an AI agent's hit rate, and the distractions to skip." date: 2026-06-26 url: https://valdemird.com/blog/high-accuracy-agent-priorities/ lang: en tags: ["ai-agents", "llm", "production", "reliability", "engineering"] --- # Shipping a high-accuracy AI agent: what to prioritize, what to ignore > The gap between a 95% agent and a flaky demo is the harness, not the model. What actually raises an AI agent's hit rate, and the distractions to skip. I spent the last few weeks building a [16-module wiki on agentic systems](/learn/agentic-systems/), from what an LLM physically is up to multi-agent frontier work. I didn't write it by hand. I ran Claude Code workflows, a multi-agent research pipeline, to draft and cross-check it, then I studied the result until I understood it well enough to argue with it. This post is what I took out of that. It's the condensed, practical version: what to prioritize and what to ignore if you want to build agents that actually hold up. Everything here is distilled from that wiki, and every section links back to the module where the full argument and the graded sources live. The uncomfortable part is that almost nothing on the priority list is about the model. This single curve routes every other decision. It gives you exactly three levers: raise `p` (per-step reliability), shrink `t` (shorten the chain), or break the chain into segments that each reset the error. "Use a smarter model" is a weak way to nudge `p` and does nothing for `t`. Most things that "need an agent" are better off as a deterministic workflow or a single call once you've seen what the math demands of you. That decision is the first thing the [agent-as-policy module](/learn/agentic-systems/agent-as-policy/) makes you confront. ## Break the chain: verify against ground truth If reliability decays geometrically, the highest-impact thing you can build (after knowing your number) is something that *resets* the error mid-chain. Put a verification gate in the middle and one catastrophic `p^20` becomes two friendlier `p^10` segments. The catch: the verification has to come from outside the model. A real tool result. A test that passed or failed. The row that actually committed to the database. Asking the model "did you succeed?" and trusting the answer does not work, because the evaluator shares the generator's blind spots. Intrinsic self-correction does not reliably improve reasoning and can make it worse. Ground truth is the only thing that genuinely resets the per-step error, which is why the [control-loop module](/learn/agentic-systems/agent-loop/) treats observable feedback as the load-bearing part of the loop, not the prompt. The guard in that diagram is the condition everyone skips. Without a no-progress check, an agent will happily burn its entire token budget repeating one failing call. Termination needs multiple conditions: goal reached, budget spent, *and* no progress since last turn. More on the loop shape in the [agent-loop module](/learn/agentic-systems/agent-loop/). ## Tools are the action space: design them as UX, not an API wrapper The model can only be as accurate as the tools you give it. It reasons over the names, schemas, and (this is the part people miss) the *error strings* you wrote. It reacts to text. It cannot step through a debugger. The most common mistake is mirroring your database: one tool per table, raw UUIDs in and out, an 8K-token blob back. That maximizes the number of sequential calls the model has to orchestrate, which (see the arithmetic) maximizes the ways it can fail. Collapse N calls into one tool that completes a whole workflow, return values a human could read, and write errors as instructions the model can act on. The pattern across all seven: each one is the model's job dressed up as architecture, or architecture dodged with a prompt. The seductive moves point at the LLM. The moves that work point at the code around it. ## The questions you're actually asking ### Do I even need an agent for this? Run the p^t math first. If your per-step reliability and step count don't clear your target, decompose the horizon or drop to a deterministic workflow or a single call. Most tasks that "need an agent" don't. ### Should I use a multi-agent system? Not by default. Around 79% of multi-agent failures are coordination, not model limits, and fan-out burns roughly 15× the tokens for parallel compute, not better reasoning. Use a single linear agent with compaction, fan out only read-only exploration, and keep every write on one thread. ### Is fine-tuning worth it for my agent? Usually it's the last resort, not the first. Walk the ladder: prompt, few-shot, context and harness engineering, RAG, then fine-tune. The harness is about 90% of the ROI, and training on new facts actually raises hallucination. ### Will a bigger context window make my agent more reliable? No. Recall sags on a U-curve well before the nominal limit, and irrelevant tokens dilute attention even when everything fits. Minimize signal density instead, and measure your real effective window. A high hit-rate agent is won by making every step cheap and safe to re-run, and by breaking the error chain with ground-truth verification. Not by a smarter prompt, and not by a smarter model. If you read only one thing into your hands tomorrow, make it the arithmetic. Open a notebook, write down your `p` and your `t`, and look at `p^t` before you architect anything. The number will tell you whether you need an agent at all, where to put the verification gate, and which of these priorities is actually yours to fix. Everything else in this post is downstream of that one multiplication. The full version, with every source graded and the proofs behind the claims, is the [agentic-systems wiki](/learn/agentic-systems/). This was the map. That's the territory.