The Hard Part Isn't Saving or Searching, It's Resurfacing
Most of what I write about this product covers the two easy halves. Capture is solved with one click. Retrieval is solved with meaning-based search. The half nobody has really solved is the one where the tool tells you about something you saved, at the moment it's relevant, without being asked.
Why the third half is different
Capture and retrieval are both user-initiated. You know you want to save; you know you want to find. The system only has to be fast and not lose anything.
Resurfacing requires the system to have an opinion about timing. It has to decide that right now, unprompted, this specific thing is worth interrupting you for. Get that wrong and you have built a notification you will turn off within a week, which is strictly worse than silence because it also cost you trust.
What the current attempt actually is
Markwise's current answer is a weekly digest for Pro users: a summary of what you saved, sent on a cadence.
It is genuinely useful and it is also the weakest idea in the product, because it is time-triggered rather than context-triggered. Tuesday is not a signal. A digest does not know that you just opened a doc about the exact thing you researched in March, and that this is the one moment all year when the March links would have been worth surfacing.
Scheduled resurfacing is a proxy for relevance, and it is a poor one. It works well enough that people keep it on, which is a low bar disguised as validation.
The version I keep not building
Every design I sketch for the good version runs into the same wall. Knowing what you are currently working on means watching what you are doing.
Not "watching" in a vague sense. It means reading the pages you have open, or the document you are writing, continuously, to compare against your library. That is a much bigger ask of a user than "save this page", and it changes what the product is. A bookmark tool that reads your screen is not a bookmark tool anymore.
There are partial answers, and none of them are free. Do the matching entirely on-device. Scope it to a project you explicitly declare. Make it pull-only, so it surfaces when you ask rather than when it decides. Each of those trades away most of the magic to keep the boundary intact.
I would rather ship nothing than quietly turn a bookmark tool into a surveillance tool. That is not a positioning statement, it is why the feature does not exist yet.
So, an open question, asked sincerely rather than rhetorically: what would make proactive resurfacing feel helpful instead of creepy to you? Or is scheduled and manual actually where this should stay?
If you have a version that would work, I would like to hear it. Markwise is free to start if you want to argue from the inside.