<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Control-Plane on Stack Research</title><link>https://stackresearch.org/tags/control-plane/</link><description>Recent content in Control-Plane on Stack Research</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 23 Mar 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://stackresearch.org/tags/control-plane/index.xml" rel="self" type="application/rss+xml"/><item><title>Why Agent Memory Needs a Control Plane</title><link>https://stackresearch.org/research/why-agent-memory-needs-a-control-plane/</link><pubDate>Mon, 23 Mar 2026 00:00:00 +0000</pubDate><guid>https://stackresearch.org/research/why-agent-memory-needs-a-control-plane/</guid><description>&lt;p&gt;In an end-to-end memory governance scenario, a migrated record was present in the store but denied by default retrieval. The data existed, but policy correctly kept it out of the agent&amp;rsquo;s active context. That behavior sounds strict until a real system shows how quickly &amp;ldquo;just store it&amp;rdquo; turns into stale, unsafe memory that is hard to audit.&lt;/p&gt;
&lt;p&gt;That gap is why &lt;a href="https://github.com/stack-research/agentic-memory-fabric"&gt;Agentic Memory Fabric&lt;/a&gt; is a control plane for memory, not another retrieval wrapper. The point is simple: memory used by agents should be treated like governed infrastructure, with clear lineage and retrieval policy enforced at runtime.&lt;/p&gt;</description></item></channel></rss>