[FEATURE] Custom agent definitions can rot silently — no native way for a required verifier to detect its own anchor is stale before it stamps work as verified

The problem

A custom agent definition (a .claude/agents/*.md file used as a sub-agent's system prompt) often points at specific project state as its source of truth — an active plan document, a set of "read this every wake" reference files, a description of what the current live system actually is. That's normal and useful. The problem is what happens when the project moves on and the definition doesn't.

There is no native mechanism to detect that an agent's own reference material has gone stale. And because a custom agent definition gets reloaded as the system prompt on every fresh dispatch — including, functionally, every time work resumes after a compaction — a stale definition doesn't just cause one bad run. It re-injects the same stale mental model indefinitely, every time that agent is invoked, for as long as nobody notices.

This gets serious when the stale agent is a required verifier — something whose job is specifically to audit, gate, or stamp other work as complete/correct. In a real case I investigated: several agents whose entire job was independent verification had been anchored to reference documents describing an earlier version of the system, months out of date. Every gate and hook these agents were responsible for fired correctly, every time. All of it was aimed at a system that no longer existed. The verification signal was fully "green," with full authority, and completely disconnected from what was actually true. That's strictly worse than having no verifier at all — a missing check reads as unknown; a rotted required check reads as confirmed.

Why this matters beyond one project

Anyone maintaining custom agents over a long-lived project accumulates this risk by construction: agent definitions describe a snapshot, projects don't stay snapshots, and nothing currently tells you when the gap has become dangerous. The failure mode is specifically insidious because everything looks like it's working — stamps get written, gates pass, hooks fire — right up until someone manually compares what the agent thinks is true against what actually is.

Proposed solution

A first-class "freshness check" primitive for agent definitions: let an agent declare the file(s) its own authority depends on, and have the harness (or a documented convention the harness actively supports) verify those files have been touched within some bound before the agent is allowed to stamp/certify/gate anything. If the anchor is missing, or untouched past its staleness window, the agent should refuse to certify and say why — fail closed, not silently proceed on an assumption.

This is not theoretical — it's the exact fix that worked once implemented by hand in the case I investigated: every required verifier got an explicit freshness assert against its own reference docs, with a hard refusal (not a warning) when the anchor was stale. That one change was the single most effective fix across a whole cluster of related failures, because it converts "confidently wrong" into "explicitly refuses to answer" — which is the outcome you actually want from a verifier that's lost track of reality.

The general principle, if it helps frame the feature

An agent whose reference material is stale will confidently audit the wrong system and stamp it green. A required verifier should have to prove its own anchor is current before it's allowed to certify anything else — and must fail closed when it can't.