<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Caching on App Coding</title>
    <link>https://appcoding.com/tags/caching/</link>
    <description>Recent content in Caching on App Coding</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 05 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://appcoding.com/tags/caching/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Facts Should Expire: A Database That Tells an AI Agent When Its Knowledge Has Gone Stale</title>
      <link>https://appcoding.com/facts-should-expire-a-database-that-tells-an-ai-agent-when-its-knowledge-has-gone-stale/</link>
      <pubDate>Mon, 05 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://appcoding.com/facts-should-expire-a-database-that-tells-an-ai-agent-when-its-knowledge-has-gone-stale/</guid>
      <description>&lt;p&gt;An agent keeps a memory table, and two rows matter for today&amp;rsquo;s task: a supplier&amp;rsquo;s headquarters city, written eleven months ago, and a freight quote, written three hours ago. A &lt;code&gt;SELECT&lt;/code&gt; returns both in the same shape. The headquarters is probably still right. The quote may already be wrong. Nothing in either row says so, and the agent repeats both in the same flat tone.&lt;/p&gt;&#xA;&lt;p&gt;A row has no idea how old its truth is. It might carry a &lt;code&gt;created_at&lt;/code&gt;, and a careful person can compute an age from it, but the decay rate belongs to the kind of fact, not to the table. A three-week-old headquarters address is fine. A three-week-old shipping rate is fiction. Server health goes bad in half a minute. No timestamp column holds that knowledge, and nothing forces a query to read it anyway.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
