Your Agentic AI Passes All Its Tests. But Do You Know How It Got There?

Traditional software testing has a clear success condition: the output matches the specification. A passing test suite means the function returned the right value, the API responded correctly, the data transformed as expected.

Agentic AI fails this paradigm. Two identical outputs can result from fundamentally different processes — one where the agent completed the task autonomously, and one where the agent failed midway and a human intervened to fix it. A passing test doesn’t capture the difference. Graham Clay’s framework does.

The Framework

Testing an agentic AI tool requires separating three types of evidence that a standard pass/fail test collapses into one:

Activity Records

What tool calls did the agent make? In what order? What data did it read, write, or modify to produce the output?

Activity records expose what actually happened during task execution, not just whether the final state looks correct. An agent that completed an endpoint update by querying the current configuration before modifying it is behaving differently from an agent that wrote a new configuration without reading the existing one — even if both produce a working endpoint.

Clay’s framing: did the agent consult current information before acting, or did it work from stale context? Activity records answer that question. Pass/fail output checks do not.

Permission Histories

What approvals occurred? Were they the planned human checkpoints in the workflow, or were they corrective interventions in response to agent errors?

This distinction matters for assessing actual autonomy. A workflow designed with a human review step before a database write is operating as intended when a human approves that step. A workflow where a human had to intervene because the agent was about to delete the wrong records is operating differently — even if the final state is identical.

Permission histories document whether human involvement was deliberate governance or emergency correction. An agent with a clean permission history of only planned reviews is more autonomous than one requiring repeated unplanned intervention, even if both produce the same deliverable.

Deliverables

What was actually saved, committed, or sent? Not just what the agent reported producing — what was verifiably written to the output destination?

This is the evidence type closest to traditional testing, but it still requires verification that the output was saved, not just generated. An agent that produces the right text but fails to commit it to the repository has a different failure mode than one that committed the wrong content.

Where It Doesn’t Apply

For simple, deterministic agentic tasks — a tool that fetches a URL and returns the content, or one that queries a database and formats the result — the overhead of this three-part framework doesn’t add value proportional to its complexity. The framework is designed for evaluation of multi-step agents operating in environments where the path to the output matters: code generation, document editing, data pipeline management, customer interaction handling.

It’s also incomplete for agents operating in fully automated pipelines with no human intervention point. If there are no planned review steps, permission histories are vacuous — the framework’s value in that context comes entirely from activity records and deliverable verification.

Source: AutomatED

Content created with AI assistance and reviewed for accuracy.