Suresh B

Thanks for the comment, Mihai_LeanZero. That’s a useful distinction. A transcript can tell you what the agent said happened, but the system of record tells you whether it actually happened. For actions like cancellations or reschedules, I’d much rather compare the agent’s closing claim with the backend state and flag any mismatch for review. I also like your point about intents without a clear ending. If an intent doesn’t have an explicit success or completion condition, the agent can keep talking even after the useful part of the interaction is over. Defining that end state before the intent ships seems better than trying to diagnose it later from the hangup curve. Repeat contact is still a useful slower signal too, because it catches cases where the backend action succeeded but the caller still didn’t get the outcome they expected.

Good catch Mihai_LeanZero . I went back through the MRTR spec, and it doesn't give you a built-in idempotency key for this. The spec does give you replay protection around requestState: bind it to the authenticated principal, give it a short TTL, and tie it to the originating request. But it explicitly says that still doesn't guarantee single use. If you need exactly-once behavior, the server has to enforce that itself. There's another edge case too: the client isn't required to retry after input_required. So if the first pass already reserves something or calls a paid API, you can end up with either a duplicate on retry or an orphan if the retry never happens. I'd keep the first pass side-effect free where possible. If that's not possible, create a short-lived reservation/idempotency ID, carry it through requestState, and have the retry reconcile against that reservation instead of performing the action again. And yeah, idempotentHint doesn't solve this. It's useful metadata, but it's still only a hint, not an enforcement mechanism.

Thanks for reading, Mateo Ruiz . I think you may be thinking of a different article, this one is about business chatbots answering from approved sources rather than coding agents, but your point about concrete examples beating vague rules holds there too. A handful of real example phrasings per intent does more for classification than any amount of instruction text.