Can you trust your agents?

Can you trust your agents? No. Not the way the question is usually meant, as a property of the agent, something you establish once and then rely on. An agent is a stochastic system calling tools with real consequences. On any given run it can be confidently, fluently wrong. If your plan is to trust the agent itself, you do not have a plan. The useful version of this claim is not a mood. It is measurable, and the measurements are not close.

The evidence for "no"

Start with the most flattering possible setting for an agent: a benchmark, where the task is clean, the tools are already wired, and someone has decided in advance what counts as success. Even here, a single headline score overstates what you can rely on, in two distinct ways.

The first is the gap to a competent person on realistic tasks. On WebArena, a suite of real web tasks like booking and form-filling, the study's best GPT-4 agent finished 14.41% of tasks end to end, against 78.24% for humans. On GAIA, a set of assistant questions a person handles easily, GPT-4 with plugins scored 15% where human respondents scored 92%. Frontier scaffolds have since climbed well above those first numbers, and that is the point worth keeping: the score is a moving snapshot of a system under active optimization, not a fixed property of the agent you are about to deploy.

The second way is quieter and more damaging, because it survives even when the average score looks good. It is consistency. tau-bench, from Sierra, has an agent complete customer-service tasks against a rule set and a simulated user. The best agent tested, gpt-4o, resolved roughly 60% of retail tasks on a single attempt. Run it on the same tasks eight independent times and count how often it succeeds on every one, and the figure drops below 25%. The authors state it flatly in their own summary: agents "succeed on <50% of the tasks, and are quite inconsistent (pass^8 <25% in retail)." Same model, same tasks, and more than half of the single-run wins do not survive a repeat.

Run the same agent eight times on the same tasks, and ask how often it succeeds every time. On tau-bench retail that number falls below 25%, from around 60% on a single try. The unreliability is not between one agent and another. It is inside a single agent, on identical inputs, which is exactly the thing a track record has to account for and a one-shot score hides.

None of this means agents are weak. On SWE-bench Verified, a curated set the field has optimized hard against, frontier systems now resolve the large majority of issues, and several sit statistically tied near the top. But that saturation is why a harder, contamination-resistant sibling exists. On SWE-bench Pro, built from real pull requests that models are unlikely to have seen, the top public entry resolves 61.5% as of July 2026, and the gap runs the other way: the same model that clears roughly 80% on Verified drops into the 40s on Pro. The pattern is consistent across every benchmark that tries to resemble real work. The strongest agent available still fails a meaningful fraction, and the fraction it fails is not stable.

So the honest answer holds. You cannot trust the agent, because the agent is not reliable in the way trust requires, and the number that suggests otherwise was measured on a good day, on a task someone else defined. But notice you never trusted the humans that way either.

You did not hand a new hire the keys because you trusted them personally. You trusted a system: they had a named identity, defined permissions, a manager, an approval process for the big stuff, an audit trail, and a way to be corrected or removed. Trust was never in the person. It was in the structure around the person.

Trust is not a property of the actor. It is a property of the system the actor operates inside.

The category error

Most "trustworthy AI" work tries to make the model itself more trustworthy, with better alignment, better prompts, better evals on a fixed set. All worth doing, and none of it closes the gap, because the gap is not in the model. A perfectly calibrated model still needs to be prevented from doing the irreversible thing, still needs its actions attributed, still needs its work checked over time. You do not make a courier trustworthy by hiring a nicer courier. You make the delivery trustworthy with tracking, signatures, and insurance.

What a trust-producing system actually needs

Move the question from "is this agent trustworthy" to "what would make this agent's work trustworthy," and the answer stops being philosophy and becomes engineering:

• Attribution. Every action has one unambiguous author: an agent with its own identity, not a borrowed human token, so you can always say who did what.
• Least privilege. The agent can do exactly what its task requires and nothing more, and that boundary is enforced on every call, not written in a runbook.
• A dial, not a switch. Reversible, low-stakes work runs unattended; consequential work is proposed and a human commits it; genuinely contested calls stay advisory. Set per task, moved on evidence.
• A brake. A way to stop a running agent immediately, demote it to something harmless, see everything it touched, and undo it. The response path matters more than the gate.
• Proof over time. Not "it passed the eval at launch" but a track record: the same objective measured on a schedule. This is the pass^8 problem again, at deployment scale, so a system that quietly degrades is something you catch rather than something you discover.

None of those live inside the model. All of them are properties of the platform the model runs on. Assemble them and something interesting happens: you can extend trust to an agent the same incremental way you extend it to a person, start narrow, measure, open up where the evidence says you can. The trust becomes earned and visible, and it can be widened or pulled back on demand.

The uncomfortable part, and why it is freeing

Admitting you cannot trust the agent feels like a reason not to deploy. It is the opposite. Teams that pretend the model is trustworthy ship it into consequential work with nothing underneath, and the first serious incident sets the program back a year. Teams that assume the model is not trustworthy build the identity, the controls, the brake, and the measurement, and can then safely automate far more than the optimists, because their trust is load-bearing instead of hopeful.

How we think about it

We built Recursiv on the assumption that you cannot trust the agent, so we made the system around it the product. Agents are first-class actors with their own credentials and audit trail. Controls are per-agent and per-tool, with a hard stop and a reversible action ladder. Outcomes are measured over time against the actor that produced them, because a benchmark score from launch day is a snapshot and reliability is a trend. The point is not to make you believe the agent. It is to let you delegate to it the way you delegate to anyone: on a track record, inside a structure, with the ability to say no.