# Assert the tool. Not the prose.

> Model wording changes every run.

- **Format:** short video, 9 steps, ~51 seconds
- **Topic:** Testing and running a Microsoft Foundry agent in production: assert on tool calls with a recording executor instead of on model prose, trace every turn, and watch token cost per tool call.
- **Author:** Suthahar Jegatheesan (MSDEVBUILD)
- **Category:** Azure · Azure
- **Published:** 2026-06-21
- **Tags:** microsoftfoundry, azureai, aiagents, dotnet, flutter, azure, aicoding, msdevbuild
- **Canonical URL:** https://blog.msdevbuild.com/shorts/foundry-assert-the-tool-not-the-prose/

---
## What you'll learn

- Why prose assertions flake
- What a recording executor checks
- Where agent cost really goes

## Understand it one step at a time

### 1. A test on the wording

Assert the reply contains "Sambal". It passes, then fails, then passes.

### 2. Assert the tool call

A recording executor captures which tool ran, with which arguments.

### 3. Fast tests, no model

Role and ownership tests on the executor need no model at all.

### 4. Trace every turn

Which tools ran, in what order, how long each took.

### 5. Three calls for one

Drifted descriptions made the model call three tools where one would do.

### 6. Every tool is a model call

One tool call means at least two model calls. Two tools, three.

### 7. Cache the boring answers

"Where is my delivery" with one active order needs no model at all.

### 8. Green for the right reason

Stable tests on tool calls, traces per turn, cost per tool.

### 9. Assert the tool, not the prose

Stable tests, traces per turn, and cost per tool call.

---

## The takeaway

**Assert the tool. Not the prose.**

A test that checks wording is a flaky test. Check the tool and its arguments.