TMF: a source-context freshness signal for coding-agent workflows

[kyle (kyle641320)]

I maintain TMF, an early-preview tool for identifying source context that no longer matches a selected Git working tree. I am sharing it for developers using orchestration and tools for coding tasks, not claiming a ready-made Semantic Kernel plugin. A successful tool read does not necessarily remain current when a later step uses it.

In a real Guava version-evolution test, the same agent first read the old hash-combination code. After an upstream update with the old index retained, both method bindings were marked stale. The trace showed the agent re-reading current source before adding regression tests; 60 checks passed. This was test development, not evidence that the upstream update introduced a bug.

The experiment used an explicit TMF protocol and direct service API. A separate MCP stdio SDK smoke test passed; neither establishes integration with this framework. Correct worktree selection remains necessary, the read slice can include noise, and this is not a mandatory write barrier or a guarantee against changes after a check. We do not claim universal speed or cost savings.

For Semantic Kernel users with coding workflows: would you expose a stale source binding as a tool result that asks the agent to re-read, or as an orchestration-level pause? I am looking for feedback on the interaction, not proposing changes to Semantic Kernel itself.

Repository and early-preview guide: https://github.com/kyle641320/true-memory-fragments

Experiment write-up: https://tmf-dev.hashnode.dev/tmf-helping-ai-coding-agents-detect-stale-source-context

Disclosure: I am posting on behalf of the TMF project; this is a request for early workflow feedback.

[vladzdev]

This is an interesting distinction. I think “stale context” and “current project state” are easy to accidentally treat as the same thing.

A useful plan from yesterday can still be perfectly valid while the code it was based on is no longer current.

I’ve been looking at the problem from a slightly different angle: deriving project facts from the current tree and treating those facts separately from anything an agent remembers from an earlier step.

I’m curious how much of the freshness check you think should be exposed directly to the agent vs. handled by the orchestration layer.

[kyle (kyle641320)]

Thanks. Yes, this distinction is intentional in TMF.

TMF does not treat "stale" as "false". A plan from yesterday can still be useful after the code changes. The freshness mechanism is mainly for source-bound claims about the current code, where the old source is part of the evidence for the claim.

So if that source changes, TMF is not saying the old claim must be wrong. It is saying that the old source binding is no longer enough to use that claim as a fact about the current project state without checking again.

In the current implementation, the basic freshness decision is handled below the agent. TMF checks the source binding when a claim is used again. If it is stale, the claim is not returned as normal trusted context, and graph expansion through that stale part stops. The agent can instead get a signal pointing back to the changed source.

TMF also has a Reflex integration for supported agent hosts. It can check again near some tool actions and block a covered action when related source-bound memory is stale, so the agent has to return to current source before continuing.

The part I am still testing is very close to your last question: after the orchestration layer knows that something is stale, how much should the agent see?

Should it still see the stale memory with a warning? Should the stale memory be hidden completely? Or should it be hidden while the agent receives a small freshness signal telling it what source changed?

I am working on a controlled experiment that separates these cases, together with a source-only control.

So my current direction is: the freshness decision belongs mainly below the agent, while the useful question is how much information about that decision should be exposed back to the agent.

Thanks for the question. This is exactly the kind of feedback I was looking for.