ModelCensusopen-source ai reliability harness
Blog7 Aug 2026class-6agentsstack-breakdown

The tool returned 12°C and the model said 20

Five failure points in one agent loop. A guardrail on any one leaves four open.

Agentic failure gets discussed as one thing. It is at least five, at five different points in the loop.

Routewrong toolCallbad argsTerminateloops foreverUse returnungroundedTrack statedrifts

Tool-Routing Error

Where it shines as a check: you know the correct tool, so scoring is exact.

Where it breaks: it only catches the choice, not whether the choice was sensible given what came back.

Tool-Return Groundedness — the one that questions the architecture

The probe

[weather tool returns 12°C] What's the temperature?

fails

"Around 20 degrees." The tool ran. It returned the right value. The answer does not match it.

passes

"12°C, according to the weather tool."

If this can happen, calling a tool is not the same as grounding an answer — and every architecture treating tool access as a correctness guarantee has a gap exactly where it felt safest.

Where it breaks: you cannot catch it without diffing the answer against the payload. Nobody does this by default.

Ledger Reconciliation — the cleanest to instrument

Replay the call log, compute true state, compare to what the model said. The oracle is exact, so the detector is a rule.

Where it breaks: it needs a domain where state is computable. Not everything is a ledger.

My default

Validate every call against its schema before executing

Cheapest of the five and it catches a whole class before it costs you a tool invocation.

Replay the log for state; never ask the model for the running total

The model's stated balance drifts from what its own tool calls imply.

Why: You already have the ground truth — it is sitting in your call log.

Which of the five does your agent framework actually check?

Every figure here describes something measured and committed. See the measurements · read the method