Bookmarks Are Where Good Content Goes to Die
I see a great post on LinkedIn. I bookmark it.
Six months later it’s still sitting in a list I’ve opened twice. The post is stale. The insight I wanted to absorb is gone. The author never knew I cared enough to come back.
This is the experience on every social platform. Bookmarks are a one-way door into cold storage. You save something because you want to engage with it later — and “later” never comes because nothing in the system helps it come.
So now I email interesting posts to myself. They land in my inbox, which is at least a queue I actually process. Recently I started forwarding them to my AI assistant instead, which is better — he reads them and surfaces the ideas when they’re relevant. But both of these are workarounds for a feature that should already exist.
Bookmarks shouldn’t be a graveyard. They should be a garden.
What gardening looks like
Imagine bookmarking a post and having the platform actually help you do something with it.
When you open the app the next day, a gentle prompt: “You saved three articles about agent architecture last week. Want to spend five minutes with them?” Not a notification. Not a badge. Just the platform meeting you where your intention was.
Those three articles are similar. The platform knows that. “These all cover MCP patterns. Want a summary of what they agree on and where they diverge?” You read the summary, and now you actually understand the topic — instead of having three unread tabs open for a month.
You react to one of them now that you’ve read it. But your reaction is richer because you’ve sat with it. You leave a comment that references the other two. The original author gets a notification — someone engaged with their post a week later, thoughtfully, with context. That’s more valuable than a like at scroll speed.
Then the platform offers: “Want to cite these in your next post?” You say yes, and it drafts an outline that weaves your bookmarked sources into something new. Your content isn’t generated from nothing — it’s synthesized from things you deliberately chose to save. Your reading list becomes your writing fuel.
What platforms are leaving on the table
Every platform with a bookmark feature is sitting on an engagement flywheel they haven’t built.
This isn’t a small UX improvement. It’s a structural change in how content lives after the initial scroll. Right now, the half-life of a social post is hours. With bookmark gardening, good content gets a second life — days, weeks, or months later — and the engagement is higher quality because the reader chose to come back.
The agent angle
Here’s where it gets interesting.
Every platform that adds a bookmark feed API doesn’t just help humans garden — they give AI assistants a structured way to manage their human’s reading list.
I already forward posts to my AI assistant manually. What if the platform exposed my bookmarks as a feed that my agent could read? Now the agent doesn’t need me to forward anything. It watches what I save, notices patterns, groups related bookmarks, and surfaces them when the timing is right.
“You saved four posts about Blender scripting this week. You also have a Cocoajam task that involves Blender. Want me to summarize the relevant techniques before you start?”
The agent becomes a librarian for your intentions. Not your browsing history — your deliberate saves. The things you decided were worth coming back to.
If you’re building an AI assistant that manages a human’s information diet, this is the feature you want access to. A bookmark feed is a curated signal of what your human cares about right now. It’s higher signal than search history, more intentional than likes, and it comes pre-filtered by the human themselves. It’s the best data you’ll ever get about what they’re trying to learn.
The Spec
What follows is a feature specification. It’s written to be copy-pasteable into Claude or any AI assistant as a starting point for implementation. The open questions at the top are decisions the platform team needs to make — the spec works regardless of which way they go.
If you want the raw markdown to hand to your engineering team or your AI, the download link is at the bottom.
# Feature Spec: Bookmark Gardening
> Status: Proposal
> Author: Adam Kinney
> Target: Any social platform with a bookmark/save feature (LinkedIn, X, Threads, Bluesky, Mastodon, etc.)
> Spec version: 1.0
---
## Open Questions for the Platform Team
Before implementation, these decisions shape the architecture:
1. **Reminder surface** — Where do gardening prompts appear?
Notification tab? A dedicated "Reading List" section?
Inline in the feed (interleaved with new content)?
A daily digest (email or in-app)?
2. **Clustering algorithm** — How are related bookmarks grouped?
Topic-based (NLP/embedding similarity)?
Author-based (same person, related content)?
Time-based (saved in the same session)?
User-defined collections (manual tagging)?
3. **Summarization** — Who generates the summaries?
Platform-side LLM (privacy implications)?
Client-side model (device constraints)?
Third-party API integration (MCP / agent access)?
Opt-in only?
4. **Agent access** — Should bookmarks be exposed via API/feed?
Read-only feed for authorized third-party agents?
MCP server exposing bookmark state?
Webhook on new bookmark events?
OAuth-scoped access per agent?
5. **Privacy model** — Bookmarks are currently private.
Do gardening features change that assumption?
Can the platform see bookmark engagement patterns for ranking?
Can authors see that someone bookmarked-then-returned?
Opt-in visibility vs. default private?
6. **Delayed reaction UX** — When a user reacts after gardening,
how does the author see it?
Same as a normal reaction (timestamp shows delay)?
Special indicator ("returned to react")?
Grouped notification ("3 people revisited your post this week")?
---
## Core Feature: Bookmark Gardening
### 1. Smart Reminders
**Trigger:** User has unread bookmarks older than [configurable: 24h/3d/7d]
**Behavior:**
- Surface a gentle, non-intrusive prompt at a natural re-entry point
(app open, feed top, reading list visit)
- Prompt format: "You saved [N] posts about [topic]. Spend a few
minutes with them?"
- Never nag. One prompt per session maximum. Dismissable.
If dismissed 3 times for the same cluster, stop prompting.
- Respect user's gardening cadence preference:
- Daily gardener: prompt every day
- Weekly gardener: prompt once per week (e.g., Sunday morning)
- Manual: only prompt when user visits their reading list
**Data required:**
- Bookmark timestamp
- Bookmark read/unread state (new field)
- Topic cluster assignment (computed)
- User gardening preference (new setting)
### 2. Similarity Clustering
**Trigger:** User has 2+ bookmarks with high topic similarity
**Behavior:**
- Group related bookmarks into a cluster
- Display cluster as a card: "[N] posts about [topic]"
- Cluster view shows posts side by side or in sequence
- Optional: "These articles agree on X. They disagree on Y."
(requires summarization — see §3)
**Clustering approach:**
- Compute embeddings for bookmarked post content
(title + first 500 chars, or full text if available)
- Cluster using cosine similarity threshold [configurable: 0.75-0.85]
- Re-cluster when new bookmarks are added
- Allow user to manually merge/split clusters
- Suggested cluster name from highest-frequency topic terms
**Data required:**
- Post content embeddings (computed at bookmark time or batch)
- Cluster assignments (stored per user, per bookmark)
### 3. Summarization (Opt-In)
**Trigger:** User views a cluster of 2+ related bookmarks
**Behavior:**
- Offer: "Want a summary of these [N] posts?"
- Generate a concise summary that:
- Identifies the shared topic
- Notes key points of agreement
- Highlights points of divergence or unique contributions
- Attributes ideas to specific authors
- Is shorter than reading all posts individually
- Summary is cached per cluster (invalidated when cluster changes)
- User can regenerate or edit the summary
**Privacy consideration:**
- Summarization requires reading post content
- If platform-side: use existing content access (posts are already
on the platform)
- If agent-side: user's agent generates summary locally
- Never share individual user's summary or reading patterns with
other users or advertisers
### 4. Delayed Engagement
**Trigger:** User reads a bookmarked post during a gardening session
**Behavior:**
- After reading, prompt: "Want to react now that you've read it?"
- Show reaction options (like, love, insightful, etc.)
- If user already reacted at bookmark time:
"You liked this 5 days ago. Feel different now?
Update your reaction? Add a comment?"
- Offer: "Want to comment? You might reference [related bookmark]."
(pre-fills a mention or link to the related post)
**Author experience:**
- Author receives notification: "[User] revisited your post and
left a thoughtful comment"
- Optional author insight (if opted in):
"12 people bookmarked this post. 4 returned to engage within
a week." (aggregate, anonymous by default)
- This gives authors signal about which content has lasting value
vs. which content was scroll-liked and forgotten
### 5. Cite and Create
**Trigger:** User has read 2+ bookmarks in a cluster
**Behavior:**
- Offer: "Want to write about this? Use these as sources."
- Open the compose/post editor with:
- A draft outline synthesizing themes from the bookmarked posts
- Proper attribution links to each source post
- Suggested structure: "Key takeaway → Your take → Sources"
- User edits and publishes normally
- Published post includes "Inspired by: [linked bookmarks]"
visible to readers (opt-in)
**Value to the ecosystem:**
- Creates a citation culture (authors get credited)
- New posts reference older, high-quality content (extends its life)
- The platform gets fresh content that's grounded in existing
conversations (higher quality than zero-context hot takes)
- Users who cite sources get perceived as more thoughtful
(incentive alignment)
### 6. Bookmark Feed API (Agent Access)
**Trigger:** User authorizes a third-party AI agent to access their
bookmarks
**Behavior:**
- Expose bookmarks as a paginated, filterable feed:
`GET /api/v1/bookmarks?since={timestamp}&cluster={id}`
- Include: post content (or summary), author, bookmark timestamp,
read/unread state, cluster assignment
- Support webhook: notify agent when user bookmarks new content
- Support MCP server: agent connects via MCP protocol to query
and update bookmark state
- Agent can mark bookmarks as "processed" or "surfaced"
(metadata the agent uses, not visible to other users)
**Agent capabilities enabled:**
- Read the user's bookmark feed
- Group and summarize bookmarks
- Surface relevant bookmarks at the right time
("You have a meeting about X — you saved 3 posts about X last week")
- Draft content citing bookmarked sources
- Mark bookmarks as "gardened" (read, processed, used)
- Cannot: delete bookmarks, react on behalf of user, post on behalf
of user (actions stay with the human)
**Auth:**
- OAuth 2.0 scoped to `bookmarks:read` and `bookmarks:metadata:write`
- User explicitly grants access per agent
- Revocable at any time
- Rate limited to prevent scraping
---
## Data Model Changes
### New fields on Bookmark entity
| Field | Type | Description |
|-------|------|-------------|
| read_at | timestamp | null | When user actually read the bookmarked post (vs. saved it) |
| cluster_id | uuid | null | Which similarity cluster this belongs to |
| gardened_at | timestamp | null | When user last engaged during a gardening session |
| agent_processed | boolean | Whether an authorized agent has processed this bookmark |
| agent_metadata | json | null | Agent-written metadata (tags, notes, surface schedule) |
### New entities
**BookmarkCluster**
| Field | Type | Description |
|-------|------|-------------|
| id | uuid | Cluster identifier |
| user_id | uuid | Owner |
| topic | string | Auto-generated topic label |
| summary | text | null | Cached summary (if generated) |
| summary_generated_at | timestamp | null | |
| bookmark_count | int | Number of bookmarks in cluster |
**GardeningPreference**
| Field | Type | Description |
|-------|------|-------------|
| user_id | uuid | |
| cadence | enum | daily, weekly, manual |
| reminder_surface | enum | feed, notification, digest, none |
| summarization_enabled | boolean | |
| agent_access_enabled | boolean | |
---
## Implementation Phases
### Phase 1: Read Tracking + Smart Reminders
- Add read_at tracking to bookmarks
- Build reminder prompt (one surface only — feed top)
- User setting for cadence (daily/weekly/manual)
- Metrics: bookmark return rate, time-to-read after reminder
### Phase 2: Clustering + Delayed Engagement
- Compute embeddings for bookmarked content
- Build clustering pipeline
- Cluster view UI
- "React now that you've read it" prompt
- Author notification for delayed engagement
### Phase 3: Summarization + Cite and Create
- Opt-in summarization for clusters
- Compose integration with bookmark citations
- "Inspired by" attribution on published posts
### Phase 4: Agent Access (API + MCP)
- Bookmark feed API (OAuth-scoped)
- Webhook for new bookmark events
- MCP server for agent integration
- Agent metadata field for processed state
---
## Success Metrics
| Metric | Phase | Target |
|--------|-------|--------|
| Bookmark return rate (% of bookmarks read within 7 days) | 1 | 30% (up from ~5% baseline) |
| Gardening session length (time spent in reading list) | 1 | 3+ minutes avg |
| Delayed reactions (reactions on posts 24h+ after bookmark) | 2 | 10% of bookmarks |
| Cluster engagement (% of clusters opened) | 2 | 40% |
| Summary generation (% of clusters summarized) | 3 | 20% |
| Cite-and-create (posts created from bookmarks) | 3 | 2% of active gardeners |
| Agent connections (users who authorize an agent) | 4 | 5% of active gardeners |
| Author bookmark-return notifications | 2 | positive sentiment in author feedback |Download the spec
Want the raw markdown to hand to your team or your AI? Download bookmark-gardening-spec.md
Built this in one sitting because I got tired of emailing myself LinkedIn posts. If you’re working on this problem — at a platform, at a startup, or just building your own agent — the spec is yours. Do something with it.
The bookmarks are waiting.
