Agent Platform: "optimally derived" instead of "no duplicates"

Store-enriched extraction does more than just dedupe — it refines
existing facts against new evidence. "Optimally derived" captures
that fuller meaning.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: rmdevpro

open-source/agent-platform.html

@@ -89,7 +89,7 @@ <h2>The memory layer for AI agents.</h2>
       <p>Every conversation — every message, every turn, every participant — is stored completely and indefinitely. This is the <em>infinite conversation</em>: not a log or an audit trail, but the medium through which agents think and accumulate knowledge over time.</p>
       <p>A context window is not the conversation truncated to fit. It is a <b>recipe</b> — a purpose-built combination of context engineering techniques that assembles one agent's view of the conversation. We call these recipes <em>build types</em>. A build type can mix any form of compression, compaction, summarization, enrichment, RAG, CAG, or GraphRAG the engineer cares to assemble, to fit any token budget. Every agent gets its own optimized view of an infinite conversation — between one or many participants, human or agent — tuned to what that agent needs to reason well. <b>This recipe-driven approach is the defining feature of the Broker.</b></p>
       <p>Among the ingredients a recipe can draw on are two distinct memory layers. <b>Episodic memory</b> is the conversation record itself, progressively compressed as it ages. <b>Semantic memory</b> is a knowledge graph extracted from conversations in the background — entities, relationships, preferences, and decisions — answering <em>what do I know about X</em> rather than <em>what was said about X</em>. An engineering agent might be weighted toward semantic-dominant context; a persona agent maintaining continuity with a user, toward episodic; a strategy agent, toward injected reference material.</p>
-      <p>Two agents handle the knowledge workflow — collectively, the <b>Context Engineering Agent</b>, or <b>CEA</b>. <b>CEAs</b> (server-side) runs at compaction time, extracting durable facts and graph triples from the full conversational context — not from isolated messages — and checking what is already stored before writing, so the knowledge layer does not accumulate duplicates. <b>CEAc</b> (client-side) runs at reasoning time as an agentic ReAct loop: decide what to search, search, rank, iterate if the first pass is thin, assemble the enrichment into the context window.</p>
+      <p>Two agents handle the knowledge workflow — collectively, the <b>Context Engineering Agent</b>, or <b>CEA</b>. <b>CEAs</b> (server-side) runs at compaction time, extracting durable facts and graph triples from the full conversational context — not from isolated messages — and checking what is already stored before writing, so the knowledge layer is optimally derived. <b>CEAc</b> (client-side) runs at reasoning time as an agentic ReAct loop: decide what to search, search, rank, iterate if the first pass is thin, assemble the enrichment into the context window.</p>
       <p>Every retrieval is logged as a feedback event, feeding a four-dimension quality model: <b>durability</b> (how inherently stable this kind of fact is), <b>confidence</b> (how reliable the source was), <b>usefulness</b> (how often this fact has actually helped when retrieved), and an optional <b>expiration</b> gate. The final ranking multiplies relevance, trustworthiness, and memory quality — so the knowledge store gets sharper the more it is used, not noisier.</p>
       <p>Assembly is <b>proactive</b>. Context is rebuilt for each participant in the background after every message, during idle time. When an agent reaches for its context, the assembled view is already waiting — no summarization latency at reasoning time. The complexity of compression, graph retrieval, and recipe evaluation is hidden from the agent entirely.</p>