Launch HN: Screenpipe (YC S26) – Record how you work and turn that into agents

Congrats on the launch. The arc you describe — fine-tuning, then tool-calling, then MCP, each one still "too static" — tracks with what's happened across the whole PKM space, not just agent tooling. But I'd push on one thing: MCP didn't fail because the protocol is weak, it's that access to context and surfacing of context are two different problems. An agent with MCP still has to decide to ask, at the right moment, in the right words. That's the same gap that's plagued Obsidian/Notion-style PKM forever — the archive is complete, but retrieval is still pull-based, so it only helps you when you remember to go looking.

The systems that actually feel like a second brain flip that: they push relevant history, decisions, and prior context at you before you ask, and — this part matters more than people give it credit for — they show their work. Cite where a given answer came from (which note, which meeting, which thread), not just serve up a synthesized blob. Looking at the pushback in this thread (the harvesting claim, the "zero chance I trust cloud SaaS" comments), I don't think that's really an objection to always-on capture — it's an objection to opacity. People will tolerate a lot of passive collection if they can see the receipts on what it's doing with it and where an answer traces back to. Local-only storage helps with the trust problem, but provenance is what actually earns it over time.

How do you distinguish durable user preferences from transient screen context before an agent turns recorded activity into an automation? I'm especially curious whether each inferred memory keeps provenance and an expiry or confidence signal so stale behavior does not become a permanent rule.

correct

claude and gpt do record manually a workflow and turn it into a skill

screenpipe is more focused on 1. building a 24/7 living memory layer for your agents and your company 2. building a living list of automation opportunities without having to click a button or having to be technical

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.

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.

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.

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.