The pinned context problem

The most common support request we got from beta users wasn't about scanning quality or summary accuracy. It was some version of: "Why do I have to explain my project every time?"

They were right. It was broken.

A user would snap a whiteboard from their Q3 planning session. They'd get a great summary. They'd chat with BoardSnap about the board — asking follow-up questions, exploring implications. Then the next day, they'd snap another board from the same client or the same project, and they'd get a summary that had no idea what happened before. Same Project, same client, same goals — but the AI was starting from scratch.

This is the fundamental problem with session-based AI. Every conversation is a blank slate. The model doesn't know what you told it last week. It doesn't know your OKRs. It doesn't know the framework you decided to use. It doesn't know that "that feature" means the payment redesign you've been grinding on for three months.

### Why this matters more for whiteboard-to-action

A general-purpose chatbot starting from zero is annoying but manageable. You repaste your context, you move on.

A whiteboard AI is different. The whole point is that you're capturing ongoing work — a series of meetings, sprints, workshops, all in service of a continuous project. The boards are episodes in a story. If every episode plays without memory of the previous ones, the tool is producing isolated artifacts instead of compounding understanding.

You end up with five great individual summaries that have no relationship to each other. The work is happening on the boards. The AI is just filing photographs.

### The first bad solution I tried

My first instinct was to dump all previous boards into the context of every new request. Project has 8 boards? Send summaries of all 8 with every chat message.

This worked, briefly, on small projects. It fell apart fast:

• Context windows have limits. Eight boards is fine. Forty is a problem.
• Not all previous boards are relevant. Sending a board from four months ago about a feature you've already shipped wastes tokens and dilutes the useful context.
• It made every API call expensive. Customers on the free tier especially would notice.
• The quality of the synthesis degraded as the context grew. The model got confused about what was current versus historical.

Dumping everything into context is lazy memory. It works until it doesn't.

### The pinned context model

Pinned context is selective memory. Instead of asking the AI to remember everything, you tell it specifically what matters.

Here's how it works in BoardSnap:

In any Project, you can pin notes. These can be anything — a note you type, a passage from a previous summary, a framework description, your current OKRs. Pinned notes have a star icon and they're stored at the Project level, not the board level.

Every time you snap a new board in that Project, or start a chat session in that Project, the pinned notes get injected into the context automatically. The AI always knows what you've pinned. It doesn't see the full history of all boards — just the things you've explicitly told it to remember.

This puts the user in control of memory. Which is the right design for two reasons:

1. You know what's important. The AI doesn't know that the pricing decision from three months ago is the constraint that everything else has to work around. You know that. Pin it.
2. Curation creates clarity. The act of deciding what to pin forces you to articulate the context that matters. That articulation is itself useful — it's a forcing function for being explicit about your constraints and goals.

### What we still haven't solved

Pinned context is a good solution for the user who knows what to pin. It's a worse solution for the user who doesn't know what they don't know.

The onboarding problem: new users don't know that they should pin things, or what's worth pinning. We've tried a few approaches — a "pin this?" suggestion when a summary contains recurring themes from previous boards, a first-use prompt that asks what's most important about this project — but we haven't found the perfect nudge.

The other unsolved problem: pinned context is currently manual. You decide what to pin, you pin it, you maintain it. A smarter version would surface pinning suggestions — "we noticed you referenced the Q3 OKRs in three consecutive chats. Want to pin them?" That's on the roadmap.

### The design principle underneath

Building this feature surfaced a principle I now apply to every AI memory decision: memory is a contract, not a feature.

When the app says it remembers something, users trust that. If the memory is unreliable, or if it disappears unexpectedly, the trust breaks and it's hard to rebuild. So we err toward explicit, auditable memory — things you deliberately pin, things you can see, things you can remove.

Automatic memory that works 80% of the time is worse than explicit memory that works 100% of the time. The 20% failures on automatic memory destroy the trust that makes memory valuable in the first place.