[Question] Reliability patterns under noisy conditions

[infomonkmoder-sketch]

Hi all,

I’m testing mcp-agent patterns under noisy conditions and would value production tips on:

• idempotency strategies
• evaluator-optimizer stop conditions
• replay/recovery after partial failure

If there are canonical examples, please point me there.
I’ll return findings as a short reliability guide.

[artiehinz]

We have now tested this boundary directly. The highest-value fixture was not a normal retry; it was ambiguous success: the destination commits a mutation, then the result is lost.

The safe pattern was:

1. assign one stable opaque operation key before the attempt;
2. record external_attempt_started before the outbound mutation;
3. on a lost/failed response, record external_result_uncertain and do not replay;
4. reconcile with provider status, read-after-write, or a stable destination marker;
5. report caller_verified only when that read-back proves the outcome, otherwise stop for review.

We published the state/reporting contract as Reliability Sidecar Contract v1, demonstrated the workflow in Agno #9178, and applied the replay fence directly to a gated write MCP in mcp-odoo #61. The important limitation is explicit: this is duplicate-resistant, not exactly once, unless the destination itself supplies transactional idempotency.

I can contribute the same deterministic synthetic destination as a small mcp-agent example: unguarded retry duplicates the write; guarded orchestration reads the marker and completes with one mutation. Is there a preferred examples area for reliability/recovery patterns?