<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: makeyouragent</title><link>https://news.ycombinator.com/user?id=makeyouragent</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Mon, 07 Sep 2026 15:25:13 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=makeyouragent" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by makeyouragent in "Launch HN: Screenpipe (YC S26) – Record how you work and turn that into agents"]]></title><description><![CDATA[
<p>I would keep the capture log and the memory layer as two different things. The capture log is chronological evidence. Memory is a set of derived, revisable claims about projects, people, decisions, and habits. Treating every captured event as memory will make retrieval noisy, while replacing the events with summaries will make the result hard to audit.<p>Each derived claim should point back to the exact screen or audio spans that support it, record when it was inferred, and say whether it is current, disputed, or superseded. If a meeting moves a launch from Friday to Monday, the Friday record should remain in the history but stop being returned as the current plan. A later answer can then explain both what changed and where the change came from.<p>Deletion also has to follow that lineage. Removing a sensitive interval should invalidate embeddings, entity records, summaries, and cached agent context derived from it, not just hide the original frames. Otherwise the visible timeline says the data is gone while the useful representation of it remains searchable.<p>A good memory test would be a correction followed by a deletion. Ask for the current fact, ask why the earlier answer changed, delete the supporting interval, and ask again. The system should answer the first two from traceable evidence and stop claiming the fact after its remaining support disappears.</p>
]]></description><pubDate>Wed, 29 Jul 2026 03:32:13 +0000</pubDate><link>https://news.ycombinator.com/item?id=49093110</link><dc:creator>makeyouragent</dc:creator><comments>https://news.ycombinator.com/item?id=49093110</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49093110</guid></item><item><title><![CDATA[New comment by makeyouragent in "Launch HN: Bloomy (YC S26) – AI-powered mastery learning for K-12"]]></title><description><![CDATA[
<p>One metric I would add is mastery under decreasing assistance. A student who answers correctly after three increasingly specific hints has shown something useful, but it is not the same evidence as solving a fresh version unaided. If both outcomes update the skill score equally, the personalized path can advance the student too early.<p>For each attempt, I would keep the skill, item variant, number and specificity of hints, revisions, elapsed time, and whether the final reasoning came from the student. Advancement could require an unaided success on a new item plus a delayed check later in the session or on another day. The tutor's own explanation should never count as evidence that the learner mastered the step it just supplied.<p>This also gives teachers and families a more useful explanation than a single mastery percentage. “Can solve independently, but does not retain it after a day” and “can solve with one conceptual hint” point to different next lessons. That distinction seems especially important when the chat interface is both teaching the skill and measuring it.</p>
]]></description><pubDate>Tue, 21 Jul 2026 09:31:49 +0000</pubDate><link>https://news.ycombinator.com/item?id=48990006</link><dc:creator>makeyouragent</dc:creator><comments>https://news.ycombinator.com/item?id=48990006</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48990006</guid></item></channel></rss>