What If AI Could Recall Its Own Advice?

By Henry Chimanzi

Research proposal · 29 October 2026

Imagine asking an AI assistant how to connect a payment service to your website. It gives you instructions, links to the documentation and helps you get everything working.

You move on.

A fortnight later, the provider changes a requirement. Part of that advice now needs updating. If you ask the assistant again, it might spot the change. But you have no reason to ask: as far as you know, the job is finished.

Who tells you?

That is the question behind an idea I’m calling AI Answer Recall. With your permission, an assistant would keep track of the evidence behind a particular recommendation and let you know when a change means you should revisit it.

The full monitoring system described here has not been built or validated. I have published a small rule-based demonstration using fictional documentation. You can try it through the “Try the prototype” link in Sources & further reading below. It illustrates a narrow workflow; it does not establish novelty or prove that a general AI monitoring service works. What follows is the wider proposal and how it could be tested.

The answer you saved last month

We often judge an AI answer at the moment it appears. Does it make sense? Are the sources credible? Can we check what it says?

Those questions matter. But an answer can be sound when it is written and become unsuitable later. The documentation changes. A service is withdrawn. A condition that the advice depended on no longer applies.

Adding a date to an answer helps, but the reader still has to remember to check it again. I’d like to explore whether an assistant could take on a small, clearly defined part of that checking.

For example, after helping with an integration, it could offer: “Would you like me to watch the documentation behind this recommendation for the next 30 days?”

The user would choose what to monitor and for how long. They could stop it at any time.

What a useful correction would look like

A notification saying “something changed” would be easy to ignore. It would need to point to the earlier recommendation and explain the consequence.

In our hypothetical example, it might say:

The provider has changed the authentication requirement used in step three of your setup. That step needs reviewing. I haven’t checked your live configuration or changed anything on your website.

That gives the user somewhere to start. It also makes clear what the assistant knows and what it has not verified.

A spelling correction in the documentation should not produce the same alert. Nor should a webpage disappearing automatically mean that every answer citing it was wrong. The hard part would be deciding which changes matter to which recommendations.

Keeping track without rewriting history

Each monitored recommendation would need a short record: what was advised, the assumptions behind it, the supporting source versions and when monitoring ends. I think of this as a recommendation receipt.

The system would connect specific pieces of advice to specific evidence. If one requirement changed, it could flag the affected step while leaving the rest alone.

Uncertain cases would need review rather than an immediate declaration that the old advice was false. Confirmed changes could produce a correction notice, with a link back to the original answer. The original should remain visible, alongside the correction, so people can understand what happened.

There is another distinction worth preserving: sending a notice is not the same as solving the problem. The system could record delivery and acknowledgement, but it could not assume that someone had changed their software or stopped using the old instructions.

And permission to monitor would not be permission to act. An assistant should still need the appropriate authorisation before making changes to a live system.

What researchers have already explored

There is relevant work here already. The STALE preprint examines whether agents can recognise that later information has made an earlier memory outdated, including changes that do not explicitly contradict the old information.[1] TRACE looks at which memories an agent should still be able to use after the shared situation has changed.[2]

My interest is in what happens after advice has reached a person: can a system trace a relevant change back to that advice and contact the right reader with a useful correction?

That is a possible product direction, not evidence that I have invented something unprecedented. A proper novelty review would also need to cover older work on truth-maintenance systems, data provenance, dependency alerts, subscriptions and correction services, as well as patents. Some of the necessary parts may already exist in other forms.

Start with a small test

Software documentation would be a sensible place to begin because versions and changes can be recorded. A prototype could use archived documents and deliberately introduced changes, with experienced developers judging which recommendations genuinely need updating.

It should be compared with straightforward alternatives: doing no monitoring, periodically generating the answer again, and subscribing to ordinary page-change alerts. Each approach should get comparable access to sources and a similar checking budget.

The test would need to count missed corrections and false alarms, measure how quickly useful notices arrive, and calculate what monitoring costs. It should also check whether people understand the notices and can choose the right next step.

I’d want the awkward cases included: unavailable sources, conflicting updates and malicious text inserted into a document. Otherwise, a convincing demonstration could hide the very problems that would make the service unreliable.

If a simple page-change alert works just as well, that would be a useful result too.

An invitation to build and test

There are plenty of reasons this might not work well enough. Constant checking costs money. Too many alerts would teach people to ignore them. Monitoring could expose private information unless access and retention were carefully limited. A source could change without the system noticing, and tracking a recommendation would never guarantee that the recommendation was correct in the first place.

Still, I think the question deserves a practical test. For AI companies building assistants that support ongoing projects, it could offer a way to help users maintain work after the original conversation has ended.

I’d welcome a small prototype and an honest comparison with existing approaches. Before claiming a breakthrough, I’d want to see whether the system can tell someone, accurately and at a useful time: “The advice you relied on has changed. Here is the part you need to check.”