Stale Plan Protection in an AI Agent: How FreshCtx Catches Context Drift Before Dispatch

A developer built FreshCtx, a Python library that fingerprints the relevant fields of a context record at planning time and revalidates that fingerprint immediately before an AI agent dispatches an action, blocking the dispatch if the fields have changed. In a three-fixture test, a status change from available to unavailable altered the fingerprint and blocked dispatch, while an unrelated last_modified_by change produced an identical fingerprint and passed. The library is integrated into the StareBrain calendar agent, where it sits before the Intent.ACTION_INSERT dispatch and returns a StalePlan result to surface to the user.

An AI agent builds a plan from the context it sees at planning time. By the time the user confirms and the action dispatches, that context may have changed. A slot that was available is now taken. A contact that existed has been removed. A setting that was on is now off. If the agent doesn’t revalidate before dispatch, it executes a plan built on stale information — and the user confirmed something that no longer reflects reality. FreshCtx is a Python library built to catch this. The core idea: fingerprint the relevant fields of a context record before planning, then revalidate that fingerprint immediately before invocation. If the fingerprint has changed, block the dispatch. python import hashlib import json from pathlib import Path def fingerprint slot path: str - str: record = json.loads Path slot path .read text Only fingerprint fields that matter for this action relevant = {"slot id": record "slot id" , "status": record "status" } return hashlib.sha256 json.dumps relevant, sort keys=True .encode .hexdigest :16 The key design decision: field-level fingerprinting, not record-level. You don’t want a dispatch blocked because an unrelated field changed — a scheduler tag updated, a last-modified timestamp rotated. You want it blocked when the fields your action depends on have changed. We ran a fixture with three evidence files against the same base: v1 — base state v1 = { "slot id": "slot-42", "time": "2026-10-23T10:00:00Z", "status": "available", "last modified by": "scheduler-v1" } v2 — status changed available → unavailable v2 = { "slot id": "slot-42", "time": "2026-10-23T10:00:00Z", "status": "unavailable", "last modified by": "scheduler-v1" } v3 — unrelated field changed scheduler-v1 → scheduler-v2 v3 = { "slot id": "slot-42", "time": "2026-10-23T10:00:00Z", "status": "available", "last modified by": "scheduler-v2" } Results: Comparison | Fingerprint match | Outcome v1 → v2 | ed3a5680 vs 94c87157 | BLOCKS v1 → v3 | ed3a5680 vs ed3a5680 | PASSES Unprotected | — | EXECUTES regardless v1 and v3 produce identical fingerprints because last modified by is not in the relevant field set. The dispatch only blocks when status changes — exactly the field the booking action depends on. In StareBrain, the calendar action uses Intent.ACTION INSERT — the system calendar opens pre-filled and the user saves manually. FreshCtx’s boundary sits before the intent is dispatched, not before a write, because StareBrain never makes the calendar write itself. // Before dispatching the intent val currentFingerprint = freshCtx.fingerprint slotPath if currentFingerprint = plan.capturedFingerprint { return DispatchResult.StalePlan reason = "slot status changed since plan was built", capturedAt = plan.capturedAt, detectedAt = Instant.now } // Fingerprint matches — safe to dispatch dispatchCalendarIntent plan The capturedFingerprint is stored on the plan at planning time. At dispatch time, FreshCtx recomputes it and compares. If they match, proceed. If they don’t, return StalePlan — the agent surfaces this to the user before anything is dispatched. Without stale plan protection, the agent is confident about information it has no business being confident about. The user confirmed a plan. The plan was built on a snapshot. The snapshot is now wrong. FreshCtx makes the boundary explicit: the plan is valid as of the moment it was built, and that validity is checked again at the last possible moment before dispatch. Everything between planning and dispatch is treated as a window where the world could have moved. Series so far: