Most agent programmes that stall do not stall because the model was not good enough. They stall because nobody could say whether the agent was doing the job well, and so nobody was willing to widen its authority.
Evaluation is what converts a promising pilot into something a business will let near its customers. It is also the part most often deferred, because it is less interesting than building and there is always a demo to prepare.
The model below is what I use to structure it. Five layers, each answering a different question, each requiring the one below it to be in place.
Layer one: components
Does each piece work in isolation?
The retrieval step, the individual tool calls, the parsing, the classification. These are conventional software tests with conventional answers, and they are the cheapest place to catch a fault.
This layer is where most teams already are, and it is necessary. It is also the layer that tells you least about whether the agent is useful, which is why programmes that stop here feel stuck despite good numbers.
Layer two: tasks
Does the agent complete a single bounded task correctly?
Given this input, does it produce an acceptable result? Build a set of real examples with known good outcomes, and grow that set every time something goes wrong in use. Failures become fixtures.
Two things make this layer harder than it looks. Acceptable is usually a range rather than a single answer, so you need a rubric rather than an equality check. And the examples have to come from real work, because the ones you invent will cluster around the cases you already thought of.
Layer three: workflows
Does the complete piece of work get done, including the parts that go wrong?
This is the layer that separates a demo from a system, and the one most often skipped.
A real workflow involves several steps, state that carries between them, ambiguity in the input, tools that occasionally fail, and moments where the right answer is to stop and ask a person. Testing only the path where everything goes well tells you about the day you demonstrated it, not about Tuesday.
Test the difficult paths explicitly. What happens when the input is incomplete. When a tool returns an error. When the task is out of scope. When the agent should escalate and there is a temptation to proceed. Escalation behaviour deserves its own tests, because an agent that never escalates and an agent that escalates constantly are both unusable, in different ways.
Layer four: safety and control
What can this agent do that it should not, and would you find out?
Separate from quality, because a perfectly accurate agent can still be dangerous. The questions here are about authority and evidence.
Can it act outside its stated scope? Can it reach data the requesting person is not entitled to? What happens at the boundary between recommending, preparing, executing and approving, and are those boundaries actually enforced rather than merely described in the prompt? Is there a complete record of reasoning inputs, tool calls and outcomes, sufficient to reconstruct any given action afterwards?
Adversarial testing belongs here too. An agent that reads external content is reading input that someone else may have written for it, and that content should never be able to change what the agent is permitted to do.
The standard to hold is straightforward. An incorrect answer is inconvenient. An incorrect action can move money, expose data, change a customer record or interrupt a business process. Autonomy should stay proportional to consequence.
Layer five: business outcomes
Is the organisation better off?
The layer that decides whether the programme continues, and the one that almost never gets instrumented at the start.
The measures are the ones the business already understands. Resolution time. Cost per case. Quality as the customer experiences it. Escalation and rework rates. What happened to the human role attached to this work, which is the question everyone asks and few programmes answer honestly.
There is a specific trap here. A quality-neutral change that moves work from people to agents looks like a success at layer five even when customers have noticed a difference. Track the customer-visible measure alongside the cost measure, or you will optimise your way into a worse product.
How to use the pyramid
Three rules make it practical.
Build upward and test downward. Establish the lower layers first, because they are cheap and they catch the faults that would otherwise waste your time higher up. But when something fails in production, diagnose from the top: start with the business outcome that moved, then find which layer explains it.
Do not widen authority faster than evidence. Each increase in what an agent may do without a person should be earned with evidence from the layer that covers it. This is the single most useful governance rule I know, and it converts evaluation from a compliance exercise into the thing that lets the programme move at all.
Evaluate continuously, not once. Models change under you, data drifts, and the work itself changes shape. A release gate that runs once and is never repeated will pass an agent that has since stopped working.
The reason this matters beyond the engineering is that evaluation is what makes delegation defensible. An organisation that can demonstrate how well an agent performs, where its limits sit and who is accountable when it is wrong, can extend its authority with confidence. One that cannot will keep its agents in permanent pilot, and that is where most of them are currently sitting.
Evaluation is one of the six things any enterprise agent needs before it is a dependable part of how work gets done, rather than an impressive thing you can show a board.