Catching stale tool-call results in AutoGen agents (small library + demo)

[Viking Veritas (bg4ff8mtdn-dotcom)]

Title:

Catching stale tool-call results in AutoGen agents (small library + demo)

Body:

Kept running into the same failure shape building multi-agent workflows: an agent reads some external state, another agent or step acts on that read a bit later, and if the underlying state changed in between, the action goes through as if the read were still accurate — nothing flags that it's gone stale.

There's a recent paper describing this formally in a multi-agent verification setting — delayed verification destabilizing collective belief, with derived instability thresholds for when it tips a system toward the wrong answer.

Built a small library, intervalguard, that catches this: it timestamps tool calls, tracks dependencies between them, and raises before a later action commits on a read that's been superseded. It's a plain Python decorator with no framework dependencies — since an AutoGen tool is just a Python function under the hood, it wraps directly, no framework-specific integration required.

Demo in the repo — two debater agents plus a corrector checking a mock data source that changes mid-flight:

Uninstrumented run:

==============================================================================
RUN 1 -- WITHOUT intervalguard
==============================================================================
[t+ 0.0s] Debater Alpha          Claim: 'Reactor 2 is online, so we should route load to it.'
[t+ 0.0s] Debater Beta           Counter: 'I'm not confident Reactor 2 is up. Verify it.'
[t+ 0.0s] Corrector              fetching evidence:reactor_2_status ...
[t+ 0.8s] Corrector              got 'ONLINE', caching it for the correction step
[t+ 1.0s] Ops system             WRITE evidence:reactor_2_status -> OFFLINE
[t+ 1.3s] Corrector              applying correction from cached evidence
[t+ 1.3s] Corrector              Reactor 2 is ONLINE -- overruling Beta. Consensus: route load to Reactor 2.
  Ground truth at decision time : OFFLINE
  Evidence the corrector used   : ONLINE
  RESULT: WRONG CONSENSUS. The debate was 'corrected' with a fact that
          stopped being true while the fetch result sat in cache.

Instrumented run:

==============================================================================
RUN 2 -- WITH intervalguard
==============================================================================
[t+ 0.0s] Debater Alpha          Claim: 'Reactor 2 is online, so we should route load to it.'
[t+ 0.0s] Debater Beta           Counter: 'I'm not confident Reactor 2 is up. Verify it.'
[t+ 0.0s] Corrector              fetching evidence:reactor_2_status ...
[t+ 0.8s] Corrector              got 'ONLINE' (tracked as event id=cd3e5b3e, 30s window)
[t+ 1.0s] Ops system             WRITE evidence:reactor_2_status -> OFFLINE
[t+ 1.3s] Corrector              applying correction from cached evidence
  StaleReadError: event 'evidence:reactor_2_status' (id=cd3e5b3e) is stale: superseded by 'evidence:reactor_2_status' (id=2496a003) at 2026-07-31T07:11:40Z
  RESULT: the wrong correction was NEVER applied. The read was still
          inside its 30s validity window, so a plain TTL would have
          let it through -- intervalguard caught it because the
          underlying resource was written after the read happened.

Repo: https://github.com/bg4ff8mtdn-dotcom/intervalguard (MIT, stdlib only)

Curious whether others building with AutoGen have hit this same failure shape, and how you're catching it today — happy to hear if this overlaps with something in Microsoft Agent Framework or elsewhere that I've missed.

[Lortu | AEGIS Core (LortuArte)]

Catching stale tool calls is critical, but the subsequent failure shape is often much worse: the agent enters a fast asynchronous retry loop.

If you rely on external cloud gateways or remote rate-limiters to catch these runaway tool calls, the network latency guarantees your API budget drains before the block physically triggers.

To solve this execution blind spot, we open-sourced AEGIS (pip install aegis-core-lortuarte-sdk). It drops in as a Pre-Tool Hook, applying local in-memory ACID locks (< 0.005ms) to kill these rogue execution loops pre-flight, before they even touch the network.

Great work on the library demo, btw. Definitely a massive pain point in multi-agent setups.

[Viking Veritas (bg4ff8mtdn-dotcom)]

Appreciate you flagging this — the failure shape you're describing (fast retry loop outrunning an external rate-limiter before it can react) is real and worth being precise about, since it's genuinely a different problem from what intervalguard solves rather than the same one at a different layer.

Went and actually tested this against intervalguard specifically. The good news: it doesn't add any spin-loop risk of its own — retry rate is bounded entirely by the underlying tool call's own latency, nothing added on top. The more interesting finding: a naive retry loop against a stale read isn't just slow, it's mathematically non-convergent. If a caller retries with the same dependency reference after that reference has already been superseded, no amount of backoff ever fixes it — that supersession is a fact about two fixed points in time, it doesn't heal by waiting. The correct handling is catching the error and genuinely re-reading, which converges immediately; blind retry on the same stale reference just loops forever, looking like a transient failure the whole time.

Worth documenting explicitly given how easy that distinction is to miss in practice.

[Lortu | AEGIS Core (LortuArte)]

100% agreed. It’s absolutely a separate layer of the stack (execution vs. strict budget gating), but they often cascade into each other in production if developers aren't careful.

Glad to hear intervalguard doesn't inherently add spin-loop risks. Documenting that distinction explicitly is a great call. Keep up the solid work on the library!

[Lortu | AEGIS Core (LortuArte)]

100% agreed. It’s absolutely a separate layer of the stack (execution vs. strict budget gating), but they often cascade into each other in production if developers aren't careful.

Glad to hear intervalguard doesn't inherently add spin-loop risks. Documenting that distinction explicitly is a great call. Keep up the solid work on the library!