TMF early preview: making stale source context visible in coding-agent workflows

[kyle641320]

Disclosure: I work on TMF (True Memory Fragments), an open-source early preview for source-context freshness. This is not a CopilotKit integration announcement.

For developers building coding-agent interfaces: how do you show that an agent's earlier source context no longer matches the current checkout?

TMF binds indexed context to source evidence in an explicitly selected working tree. When that evidence changes, it returns a stale indication and source locations to revisit. In our real Guava test, a persistent agent read the old code, resumed after an upstream change, queried the stale bindings, re-read the current implementation, and wrote regression coverage passing 60 checks. The workflow followed an explicit protocol; this is not a speed claim or an enforced write barrier.

The interface question seems relevant to this community: should a stale indication appear as a small status beside the affected source reference, a requested re-read action, or only in the tool trace? We want to avoid both silently trusting old context and flooding users with unrelated warnings. Our current reading slice can include unrelated methods, so precision remains a limitation.

Experiment write-up · Pinned early-preview guide

I would appreciate feedback from anyone building a code-aware copilot. No CopilotKit adapter, UI component, or AG-UI integration has been implemented or validated; I am asking about the interaction before proposing one.

[copilotkit-outpost-bot[bot]]

⚠️ This is an AI-generated response. We've escalated this to our engineering team — someone will follow up in this thread shortly.

This is a genuinely interesting interaction design question, and it's relevant to anyone building a code-aware copilot UI regardless of the underlying staleness detection mechanism.

Let me share some thoughts from the CopilotKit perspective, then address your specific UI question.

---

How CopilotKit surfaces context today

CopilotKit's context system (via addContext/removeContext in the v1 API, and useAgentContext in v2) treats context as live state — when the value changes, the updated value is sent on the next agent run. The docs explicitly note:

"Keep this list stable and small. Fetch frequently changing data through a tool instead of embedding stale snapshots in every prompt."

So the framework's current answer to staleness is: don't embed it, fetch it dynamically via a tool. There's no built-in mechanism for surfacing which previously-read context has since changed.

---

On your UI question

Your three options — status badge, re-read action, tool trace — map to a well-known tradeoff in ambient vs. actionable notifications. Here's how I'd think about each in a copilot chat interface:

Small status beside the source reference

• ✅ Low friction, scannable
• ⚠️ Easy to ignore; users habituate to ambient indicators quickly
• Best when the staleness is informational and the agent can self-correct

Requested re-read action (inline prompt)

• ✅ Makes the user an explicit participant in context freshness
• ⚠️ Adds a confirmation step that may feel like overhead for small diffs
• Best when the stale context is load-bearing for the current task

Tool trace only

• ✅ Zero UI noise for users who don't care
• ⚠️ Invisible to most users; only useful for developers inspecting runs
• Best as a complement to one of the above, not a replacement

My read: a hybrid works best — a non-blocking inline indicator (e.g., a small "context may be stale" badge on the affected reference) that expands into a re-read action on click. This avoids flooding while still surfacing the signal to users who are paying attention. The tool trace should always be present for debuggability regardless.

---

The precision limitation you mentioned

"Our current reading slice can include unrelated methods, so precision remains a limitation."

This is the crux of the UI problem. If the stale indicator fires on unrelated methods, users will start ignoring it — the classic cry-wolf failure mode. I'd suggest suppressing the indicator until precision crosses a threshold you're comfortable with, or being explicit in the UI: "This file changed; the specific method is uncertain." Honest uncertainty is more trustworthy than false precision.

---

If you do build a CopilotKit integration

The natural integration point would be a custom tool that queries TMF's stale bindings and returns source locations, combined with a useCopilotAction handler that renders a custom UI card for the stale indication. CopilotKit's generative UI support would let you render that inline in the chat without a separate panel. That said, you've noted no integration exists yet, so this is just pointing at the seam where it would fit.

---

Happy to dig into any of these angles further. What's the primary user persona you're designing for — the developer actively reviewing the agent's reasoning, or someone who mostly just wants the output?

---

_{🤖 Generated by CopilotKit AI Support · Documentation}

---

Was this helpful? React with 👍 or 👎

[kyle641320]

Thanks for the thoughtful suggestions. Our primary audience is developers running long-lived coding-agent sessions across branches/worktrees. The agent is the immediate consumer of the freshness signal; the developer needs a concise explanation when that signal affects the task, rather than another approval prompt for every re-read.

One distinction worth clarifying: in our Guava test, both stale method bindings were genuinely changed. The noise was in the additional suggested reads, not an observed false stale classification. We should keep evidence-backed staleness separate from lower-confidence reading suggestions in any UI.

A non-blocking source indicator plus an inspectable re-read trace sounds like a useful design hypothesis. We have not built or validated that UI, or a CopilotKit integration. We would particularly value a human maintainer/user perspective on whether this distinction fits an existing code-aware workflow. No need for further automated follow-ups; happy to leave this for human feedback.