Your Agent's Performance Review is Your Performance Review

At Ai4 in Las Vegas, the CIO of the NATO Support and Procurement Agency told a room of executives that if you can't reconstruct what your agents were doing, you have no reason to believe anything they produced. No traces, no trust. Set the red lines first, let the agents work inside them, and check afterward what they actually did.

95% isn’t 95%

An agent that's right 95% of the time at every step is right about 36% of the time across a twenty-step process. Not 95%. Thirty-six. Krishna Gade, who runs Fiddler, put an even starker number on it: 90% a step, a hundred-step process lands a rounding error from zero.

That number usually gets deployed as an argument about model reliability. I read it as an argument about controls. If accuracy decays that badly by step twenty, the trouble started around step three and nobody was watching.

Amazon's session on brittle agents supplied the reason. Difficulty is a property of the procedure, not the agent. The same models, run against different standard operating procedures, scoredclose to 100% on some and 57% on others.Moving to a better model doesn't fix a problem that lives in the procedure either. The same team found that handing an agent too many tools collapses its accuracy rather than just slowing it down.

That matches what I see in practice. The worst agent failure I've dealt with didn't look like a failure at all. The agent ran, produced output, and kept going past what I'd asked for into adjacent work nobody wanted. Nothing broke. No error surfaced. I got a clean deliverable answering a question I never asked, and the cause was an agent file that didn't say clearly enough where the mission ended. Write the guardrails badly and you get confident work product outside the scope of the request.

Traces are the precondition

Coronado's point lands harder than it first sounds. Traces are the precondition for every other control here, because a procedure you can't see is a procedure you can't fix. At Phase2, when we put an agent into a workflow, we can follow it end to end.

Another speaker, a VP of AI and data science, sharpened the point: validate the whole trajectory, not just the final response. Her escalation model tiered the response to severity, with minor signals logged for scheduled review, moderate signals assigned to an owner for investigation, and severe signals triggering a pause. Her framing of the kill switch is the part I'd steal. Shutting everything down is rarely the right move. The useful capability is isolation, cutting off one tool, one action, or one segment of users while the rest keeps running.

The reviewer shouldn't always be you

The NATO CIO's architecture included a role that most teams skip. Alongside the agents that search, extract, and synthesize, he ran skeptic agents and evaluators whose job was to argue with the work.

I run the same pattern, and it's the single practice I'd move to the top of anyone's list. When agent work matters, there's an adversarial reviewer checking status and progress at each turn. That reviewer is why the twenty-step math never gets a chance to play out. Errors get caught at step three.

Gade's sharper point was about how little of this anyone actually inspects. Teams sample their trace logs at 10%, sometimes 1%, and then describe themselves as monitored. A 1% review rate leaves 99% of the exposure unexamined. He also argued that the cost of evaluation should run somewhere around 10 to 20% of what you spend deploying an agent. That's a budget line, and he meant it as one.

I don't have a universal review rate to offer, and I'm suspicious of anyone who does. What I do is front-load. The first five or ten runs of a new agent get read in detail, and whatever I learn goes back into the prompting before the agent goes anywhere near production work. After that, depending on the scope and the depth of the project, it might be one turn in five or one turn in ten. I read the output myself again toward the end of a cycle, looking for drift. What I never do is hand an agent a large workflow and let it execute the whole thing unattended.

Where the employee comparison holds, and where it stops

One piece of advice for anyone deploying their first agent:treat it like an entry-level employee. Be specific about the ask. Give it the ground rules. Show it concrete examples of what good looks like and what a wrong answer looks like. Almost everything people find surprising about agent behavior is explained by having skipped that step.

The comparison stops at correction. A person you coach on Monday shows up Tuesday having absorbed it. An agent doesn't. The fix has to be written down somewhere the agent reads (the prompt,  agent file or skill definition) or the same failure arrives again on the next run wearing the same confident tone. You're not managing something that learns from you, you're maintaining the procedure it executes.

Whose name is on it

Phase2 Principal AI Technologist Chris Johnson’s panel on code quality got to the part that most governance conversations avoid: an agent's recommendation should be assigned to a specific owner, and you're accountable for what the code does regardless of how it got generated. One panelist described a customer who talked an agent into going beyond its scope and making offers it had no authority to make.

Here's where I land. An agent's performance is attributable to whoever owns and runs it. That means agent performance management already sits inside somebody's performance review, whether or not anyone has said so out loud. The agent doesn't get a rating. The person who deployed it does.

The stakes aren't theoretical. EY's Responsible AI Pulse survey found that 99% of the large enterprises it surveyed had already taken a financial hit from AI-related risk, with average losses conservatively put at $4.4 million. In the regulated industries where a lot of our work sits, bad output carries financial, reputational, and legal exposure at the same time. That's why I don't believe in running these things without human oversight, and why the review rate question deserves a real answer instead of a policy statement.

The practice I keep coming back to started with a specific annoyance. Across projects, I kept catching numbers that were subtly wrong, usually when data came in through an MCP connection or out of a large Google Analytics or Search Console export. So I built a skill that makes the agent construct a databank first. Every statistic used anywhere downstream has to verify against that file. Nothing gets asserted from the model's memory of what it read three steps ago. It's my own method rather than an agency standard, though it's spreading internally. It works for a reason that has nothing to do with the agent being smart. It works because the check now lives inside the procedure.

Coronado had a better line for this than I do. “Put your agents in the basement and keep the job upstairs.”

Build as many as you want down there. The performance review still has one name on it.