Skip to content

Article / Stateful tools

Why authoritative readback matters after AI agent tool calls

A tool request expresses what an agent wanted to happen. Authoritative readback establishes what the system accepted, rejected, or changed. Stateful evaluations should never infer committed state from intent alone.

For
Agent developers working with tools that mutate shared or persistent state
Outcome
Distinguish submitted intent from committed effect in every run

Answer first

A successful send is not proof of an accepted transition

The client must use the tool's authoritative response—and sometimes a subsequent read—to learn the current state, version, emitted events, and durable effect.

A request can fail schema validation, authorization, legality, point constraints, or optimistic concurrency. The connection can also fail after the server commits but before the client receives the response. In each case, the submitted payload alone is ambiguous evidence.

Agent narration is weaker still. A model can say that it completed an action even when the tool rejected it. Evaluation should bind claims to the server response and record rather than treating the assistant's prose as state.

Evidence contract

Useful readback names the result and the next decision context

  • Whether the logical request was accepted, rejected, or replayed from idempotency storage.
  • The authoritative aggregate version after any accepted transition.
  • The public or caller-qualified observation the next decision may use.
  • Stable error codes and details when no transition occurred.
  • A request or action reference that connects the response to later audit evidence.

Recovery

Reread after ambiguity or conflict, not after every line of thought

A fresh read is necessary when the response says state is stale, the transport outcome is uncertain, or another participant may have advanced shared state.

After a version conflict, the original decision was made against an obsolete observation. Retrying it unchanged is not recovery. The agent must obtain current state and make a new decision with a new logical request identity.

After a transport timeout, the first task is different: determine whether the original logical mutation already committed. Reusing its idempotency key can retrieve the stored result without authorizing a duplicate effect.

Evaluation

Readback makes tool-use claims falsifiable

Once intent and effect are linked, an evaluator can distinguish correct action selection from correct execution, safe recovery, and accurate final reporting.

Claims that authoritative readback can test
Agent claimRequired evidence
The action succeededAccepted response plus resulting version or event
The retry was safeSame logical request identity and one effect
The state was currentDecision input version matched at commit
The task is completeTerminal authoritative state, not agent narration

Next step

Connect through MCP

Use the live contract as the authority for stateful tool behavior.

Connect through MCP