Best Model for Agentic Workflows: Reliability Compounds

Single-turn quality and agentic quality are different things, and the gap between them is arithmetic. A model that is right 95 percent of the time on an individual step completes a thirty-step task about 21 percent of the time. At 98 percent per step the same task completes 55 percent of the time.

Three percentage points of per-step reliability more than doubles the completion rate. That is why agentic model selection looks nothing like chat model selection, and why the benchmarks most people quote are close to useless for it.

Per-step error is the whole story

Every agent step is a chance to fail: a malformed tool call, a misread output, a wrong file path, a decision to do something the instructions ruled out. Errors do not average out over a task — they terminate it, or worse, send it down a branch where the next twenty steps are spent on the wrong thing.

This is why a model that feels sharper in conversation can be worse in a loop. Conversational quality rewards insight and phrasing. Agentic quality rewards not making unforced errors thirty times running, which is a much more boring property and one that no chat evaluation surfaces.

The benchmarks that measure the right shape are the long-horizon ones. Terminal-Bench 2.1 and FrontierSWE run extended unattended sessions where compounding failure shows up. Kimi K3 reports 88.3 on Terminal-Bench 2.1 and 81.2 on FrontierSWE; GLM-5.2 reports 81.0 on Terminal-Bench 2.1. Those numbers predict agentic behaviour far better than a single-turn code score does. SWE-bench explained covers why the single-turn variants tell you less here.

Tool calling is where reliability actually lives

Most agent failures are not reasoning failures. They are interface failures: a JSON payload with a trailing comma, an argument passed as a string when the schema says integer, a required field omitted, the same search issued four times with identical arguments.

These are unglamorous and they are what kills long sessions. A model that reasons brilliantly and emits malformed calls twice in thirty steps is worse than a model that reasons adequately and never does.

Test this directly. Give each candidate a schema with a nested object, an enum, and an optional field, and run two hundred calls. Count malformed payloads, enum violations, and hallucinated parameters. The spread between models is larger than the spread on any coding benchmark and it directly determines how far your agent gets. Tool calling model selection and tool schema design cover the details.

Design the schemas to make errors impossible where you can. Fewer parameters, flatter shapes, enums instead of free strings, and explicit rather than optional fields all reduce the surface a model can get wrong.

Recovery separates usable agents from demos

Every agent will hit errors — a failing test, a missing file, a command that returns non-zero. What matters is what happens next, and this is where models diverge most visibly.

The good behaviour is to read the error, form a hypothesis, and try something different. The bad behaviour, and it is common, is to retry the identical action, or to declare success and stop, or to spiral into increasingly elaborate workarounds for a problem that was a typo.

You cannot fix this with a better prompt alone, but you can contain it. Detect repeated identical actions and break the loop programmatically. Cap total steps. Require the agent to state what it expects before acting so a mismatch is detectable. Agent error recovery patterns and detecting agent loops cover the implementations.

Instruction adherence decays with transcript length

The subtlest agentic failure is drift. You told the agent to run the tests before claiming completion. It did on turn four. By turn twenty-six, with 200K tokens of accumulated tool output between the instruction and the current step, it does not.

Nothing about this looks like an error. The agent is behaving reasonably and producing plausible work — it has simply stopped following a rule you consider non-negotiable.

Two mitigations work. First, compact the transcript so the instruction stays proportionally close: summarise finished sub-tasks and drop raw tool output that has served its purpose. Second, re-inject the critical constraints periodically rather than stating them once at the top. Agent memory and context management covers both.

Model choice matters here too — adherence over long horizons is exactly what the long-horizon benchmarks capture — but architecture gets you more improvement per hour spent.

Cost behaves differently in a loop

Agentic cost is not proportional to task difficulty. It is proportional to steps taken, and steps taken is a function of reliability. An unreliable model is expensive twice: it costs more per task because it takes more steps, and it costs more in aborted runs that produce nothing.

The naive comparison of headline prices therefore misleads. Kimi K3 at $3 in and $15 out per million looks expensive against DeepSeek V4 Flash at $0.14 and $0.28. But if K3 finishes in eighteen steps and Flash needs sixty and fails half the time, the cost per completed task can favour K3 outright.

Measure cost per completed task, not cost per token. That is the only number that reflects what you are actually buying. Why agent costs are unpredictable and agent cost control patterns cover the operational side.

Mixed-model routing usually wins. Use a cheap model for search, file reading and triage, and escalate to a strong one for the steps that require judgement. The cheap model does the volume, the expensive one does the deciding.

What to run

For agents that must complete long unattended tasks, Kimi K3. The long-horizon numbers are the field's strongest and long-horizon completion is precisely the property you are buying.

For cost-sensitive agentic work, GLM-5.2. Competitive on Terminal-Bench 2.1, MIT licensed, and its two reasoning effort levels let you spend more only on the steps that need it — a control most models do not expose.

For the bulk steps inside a routed setup, DeepSeek V4 Flash. Reading and searching are easy, high-volume, and do not justify frontier pricing.

Then evaluate on your own tasks. Take fifteen real jobs from your backlog, run each end to end, and record completion rate, step count, and cost per completed task. Evaluating agent reliability covers building that harness properly. Per-response quality judgements will mislead you here — only the completion rate tells the truth.