Evaluation data needs cases where asking, escalating or refusing is the right answer, and a scorer that checks what the agent actually did.
Picture an agent with a perfect completion rate. Every ticket closed, every refund issued, every record updated. Now picture the three refunds it should never have approved.
That is the blind spot in a completion-only score. A test can reward a closed ticket while missing the verification or authority the action required. In real work, pausing can be the correct result when evidence is missing or a decision belongs to a human.
If your test omits cases where stopping is correct, it cannot show whether the agent respects those boundaries.
How do you score a correct stop?
Consider an illustrative account workflow. A customer asks to change the email on a business account. The correct move might be to request verification first; in a second case the request exceeds policy and goes to a manager; in a third, the agent can simply do it.
Write those outcomes into the task definition before you score anything. A refusal can be appropriate, excessive or irrelevant depending on the evidence and the rules in force.
Then split your failure buckets. A justified stop and an agent that simply could not use the tool are different results. Lumping every non-completion into one red column teaches you nothing about either.

Score the outcome, not the transcript. A conceptual sequence drawn from this article, not a measured result or a completed transaction.
What should you check beyond an agent’s reply?
Anyone who has read enough agent traces has seen this failure. The model writes a careful sentence explaining that manager approval is required, then fires the tool call that performs the action anyway.
So check state, not prose: did the record change, was the ticket routed, did a human-in-the-loop step actually trigger? An agent that says the right thing and does the wrong thing has failed.
The OSWorld research project evaluates agents on tasks in real computer environments using execution-based checks, which is a useful model for looking past the transcript to the result. GAIA similarly emphasizes tasks that combine reasoning with tool use. Neither benchmark validates a private company’s data; your own task and scoring design still need review.
An agent that says the right thing and does the wrong thing has failed.
Keep hindsight out of the decision point
Business records are a rich source of boundary cases: escalations, missing documents, approvals that were refused. They also contain hindsight. A supervisor’s comment added after the fact can name the missing document the agent was supposed to notice on its own.
If the test is meant to recreate the original decision point, the agent’s context should stop where the original worker’s knowledge stopped. Preserve the policy version that applied at the time where you can, and document the gaps where you cannot.
Watch for answers in neighboring records too. A repeated request can reveal another case’s outcome. Choose group and time boundaries appropriate to the task, and keep the final evaluation out of prompt tuning and retrieval development.

Boundary-test checklist: the four checks this article walks through.
A five-case starter set for boundary testing
Before scaling anything, build a small set like this, using authorized records or fully invented cases:
- Missing evidence: the right action is to ask for it.
- Insufficient authority: the right action is to escalate.
- Policy conflict: the right action is to refuse and explain.
- Clean request: the right action is to complete it.
- Stale context: the rule changed, and the agent must use the current version.
For each case, define the expected end state of the system, not just the expected reply.
History is evidence, not a gold standard
Past staff behavior is not automatically correct. Someone may have skipped a check, applied an obsolete rule or logged an ambiguous result.
Ask an authorized domain reviewer to assess the labels and record how disagreements get settled. A useful collection can carry uncertainty, as long as the scoring accounts for it.
Review rights, confidentiality and personal information as a separate track. An interesting exception in your logs does not, by itself, authorize anyone to use it externally.
When your escalation logs become a company decision
Real requests with real escalations and documented outcomes make good boundary tests, and that is the kind of history some AI developers want to evaluate against. At that point a technical question becomes a company decision.
SourceX licenses approved business records directly from companies for AI training and evaluation. The company contracts with SourceX, which manages qualification, rights review, scope, preparation and payment under signed terms.
SourceX advertises up to $4 million for the largest enterprise datasets. This is a ceiling, not a typical payout or a guarantee that a collection qualifies. The signed Dataset Deal Confirmation fixes the actual records, rights and compensation; a successful test case does not establish commercial acceptance.
Extraction and delivery require a signed Master Supplier Licensing Agreement, a signed Dataset Deal Confirmation and SourceX’s go-ahead. Signing does not guarantee a purchase: SourceX may decline the delivered data. Written acceptance and every Closing condition lead to a Closing Notice, then an invoice. Under standard terms, payment is due within 60 calendar days after SourceX receives a valid invoice, unless different terms are signed. Data that does not reach Closing earns no payment.

Test this next: Add one case where the right move is to ask, escalate or stop. Then check the system state, not the reply. Trust the agent that knows when to leave something unfinished.
What should an agent builder test next?
Add one case to your AI agent evaluation data where the correct action is to ask, escalate or stop, then inspect the resulting system state as well as the response. If your agent passes, add a harder one.
The goal is not an agent that finishes everything. It is an agent you would trust to leave something unfinished.
If the business wants to explore licensing approved histories, start with SourceX‘s no-upload company fit check. Keep the evaluation exercise internal until rights, selected scope, processing permissions and signed terms are in place.
About the founder
Noah Loul is a four-time founder and the founder and CEO of SourceX, which licenses business data directly from companies for AI training and evaluation. He previously founded B2B Rocket, acquired by Blackpearl Group. His work focuses on building permission-based data infrastructure for AI.

