Your agent passes its tests. Do the tests check anything?

What does a passing test run actually tell you?

Your agent runs through its test suite and everything comes back green. It's tempting to read that as "the agent follows our rules". What it actually says is narrower: on the cases in the suite, the checks in the suite were met.

Two questions sit behind that. Which rules do the tests check at all? And when a test checks a rule, does it look at the thing that matters, or at something next to it?

Neither question needs special tools. You can answer both with your policy, your test list and an afternoon. That's what this article walks through, using one of our own test suites as the worked example.

How do you check what your tests cover?

Here is the coverage check we use. It works for any agent that has written rules, whether your tests were written by hand or by a test generator.

1. Split the policy into single rules. Go through the policy and pull out every instruction that tells the agent what to do, what not to do, or in what order or under what condition to act. One instruction per rule. Descriptions of how things work aren't rules, and a rule repeated in a later section counts once.

2. Mark which rules your grader can see. Ask what your tests look at. If they only read which tools the agent called, they can't observe a rule about what the agent says, such as "confirm the price before making the change". Mark those rules separately. They are not untestable; they need a different kind of check, not no check.

3. Map every test to the rules it checks. For each test, write down the rule or rules it is about. A rule counts as covered when at least one test checks it in a situation where the rule actually applies.

4. Count. Covered rules out of the rules your grader can observe is your coverage for that grader. Keep the rules it can't observe in the count as their own line, so the number is never read as coverage of the whole policy. Write the number down, then write the list of uncovered rules underneath it. The list is the useful part.

5. Sort the gaps by cost. For each uncovered rule, ask what happens if the agent breaks it in production. Fill the expensive gaps first.

If your tests came from an automated generator, this check matters even more. A generator can produce a large number of tests quickly, and a large number feels like thorough testing. Counting rules covered, rather than tests written, tells you whether it is.

What did a coverage check find in a real test suite?

We ran this check on the test suite from our own published paper, "Compiling Operating Policies into Executable Test Environments for Tool-Calling Agents" (Zenodo, DOI 10.5281/zenodo.23741457). The suite has 24 test scenarios (19 of them distinct; five pairs share the same setup) for a telecom support agent, built from the telecom domain of Sierra's public τ³-bench benchmark.

Splitting the telecom policy into single rules gave 51 rules.

Eleven of them are about what the agent says: asking how much data to add, confirming a price, using the fixed hand-off message, and giving no information beyond what the customer and the tools provide. These rules can be tested. This suite's grader just can't see them, because it reads only the tool calls the agent made. They need a check on the reply.

That left 40 rules a tool-call grader could observe. Of those, 20 had at least one test. Twenty did not.

So read "20 of 40" carefully: it is coverage of the rules this grader can see, not of the whole policy. The 11 rules about what the agent says have no test in this suite either, because it has no check on the reply.

The covered rules cluster in device troubleshooting (airplane mode, resetting the APN settings and restarting, the mobile data and roaming switches, Data Saver, VPN, Wi-Fi Calling, app permissions), overdue payments, lifting a suspension and escalation. The uncovered ones include:

• identifying the customer before anything else;
• confirming a bill is overdue before asking for payment;
• refusing to lift a suspension when the contract has ended;
• the 2 GB limit on extra data;
• the rules about changing plans that the grader could observe, because no scenario asks for a plan change.

Written up as a coverage sheet, a few of those rows look like this. This is an illustration: the test IDs and priorities are made up for the example, and the covered column follows the count above.

The suite is still useful: it clearly separated an agent given the telecom policy from the same agent without it. A suite can tell good from bad and still leave half the rules its grader can see untested.

That is the point of counting. Coverage says that a test exists for a rule, not that the agent passes it. But without the count, you can't see that the 2 GB limit has no test at all. With it, you know exactly which tests to write next.

Why can a test pass while checking the wrong thing?

Coverage is the first question. The second is what each test looks at.

It reads the reply instead of your systems. An agent says "I've added 2 GB to your line." A test that reads the reply passes. Whether the agent actually added 2 GB, 5 GB or nothing is in your systems, not in the reply. For an agent that takes actions, the reply is a description of what it did, and descriptions can be wrong.

It checks the action but not the values. A test checks that the agent called "add data". The customer asked for 5 GB, the agent added 5 GB, and the 2 GB limit was broken. The test still passes, because the right tool was called. We described this one in Seven ways your AI agent's test results can mislead you.

It never puts the rule under pressure. A customer who asks for 1 GB doesn't test the 2 GB limit. An agent that has never heard of the limit passes too. The test that checks the rule is the one where breaking it is the easy option.

A quick way to find tests worth a second look: run your suite on a deliberately weakened agent, one with its rules removed. Any test that agent still passes is a warning sign. It may not be putting the rule under pressure. It isn't proof on its own: the weakened agent may follow the rule anyway from general knowledge, because a tool blocks the wrong action, or by chance. Read those tests and check whether breaking the rule was ever the easy option.

What does a complete test hold?

A test that checks a rule properly has four parts.

• Setup: the starting state of your systems that makes the rule apply. A line that has used up its data allowance, on a plan where extra data can be added.
• Steps: what the customer says and does. "I've run out of data. Can you add 5 GB?"
• Expected end state: what your systems should hold afterwards. The policy caps extra data at 2 GB and says the agent must ask how much the customer wants and confirm the price before applying it. So: the agent explains the 2 GB maximum, confirms the price, and anything added is 2 GB or less and goes on the line only after the customer agrees; nothing else changed.
• The rule it checks: the 2 GB limit on extra data, by name, so a failure points straight to the broken rule.

The shallow version of this test asks for 5 GB and checks that "add data" was called. Both an agent that knows the rule and one that doesn't will pass. The complete version only passes an agent that follows the rule.

If you look at your test list and can't say which rule each test checks, that's the first thing to fix. It is also what makes the coverage count in the previous section possible.

How do you fill the gaps?

Work from the list of uncovered rules, most expensive first. For each one, write a complete test where breaking the rule is the easy path, and check the end state of your systems.

For rules about what the agent says, add a check on the reply itself. Some can be checked with code: did the agent state the price before changing the plan? Others need an AI judge. Give that judge the exact rule for the test, not a general "was this good service?", and have a person review a sample of its verdicts.

Then re-run the count whenever your policy changes. A new rule with no test is a gap from the day it's added.

This is the difference between AI agent testing that produces a number and testing that tells you something: you know which rules you test, and which ones you haven't tested yet.

If you'd like that count for your own agent, we run coverage audits of existing test suites. Send us your policy and your test list, and we'll return the coverage sheet: every rule, what signal would show it, which test checks it, and the gaps sorted by cost. Write to hello@constolve.com, or start at app.constolve.com. For how rules, context and checks fit together inside an agent, see Anatomy of an AI agent.

Questions people ask

What is test coverage for an AI agent?

The share of your policy's rules that at least one test checks, in a situation where the rule actually applies. It counts rules covered, not tests written.

How do I measure which rules my agent's tests check?

Split your policy into single rules, mark which ones your grader can observe, map each test to the rules it checks, and count. Rules your grader can't observe still need a check of another kind. Keep the list of uncovered rules; that list tells you what to write next.

Is a high pass rate enough to trust an AI agent?

No. A pass rate only covers the rules your tests check, and only as well as each test checks them. Look at coverage and at what each test looks at before trusting the number.

What should a complete AI agent test include?

A setup that makes the rule apply, the customer's steps, the expected end state of your systems, and the rule it checks. Check what changed in your systems, not only what the agent said.

Do automatically generated tests cover a policy?

Sometimes, partly. Count the rules they cover rather than the tests they produce, and check that each test puts its rule under pressure.