Breadcrumb: Continuity for Unfinished Work

Breadcrumb preserves the state of unfinished work—not just its history. Return days later with partial context, and its agent reconstructs what you tried, what failed, and exactly where to continue.

Comment

Inspiration

Breadcrumb started with a simple frustration: after being interrupted, knowing what you did is often not enough to know how to continue.

Activity trackers can tell you which app was open. Notes can tell you what you wrote. AI summaries can compress what happened.

But when you return to meaningful work hours or days later, the questions are different:

  • What was I actually trying to achieve?
  • Which directions had I already explored?
  • What had I ruled out, and why?
  • Which direction was I currently pursuing?
  • What question was still unresolved?
  • What was I going to try next?

That led to the central idea behind this hackathon project:

History tells you what happened. Breadcrumb tells you what to continue.

Breadcrumb: Continuity for Unfinished Work extends the original Breadcrumb concept with persistent Work-State Memory: memory designed around the state required to resume unfinished creative or intellectual work.

What it does

Our demo follows a product designer working on a Mobile Checkout Redesign.

The designer is trying to simplify the checkout header while keeping progress through the flow clear.

Before an interruption, Breadcrumb turns the available work context into a structured Work State containing:

  • Intent — what the designer is trying to achieve
  • Explored directions — approaches already considered
  • Rejected directions — what did not work and why
  • Current direction — the active approach
  • Open question — the unresolved frontier
  • Next experiment — what the designer intended to try next

The Open Question is especially important. It represents the part of the work that was still in motion when the interruption happened.

In the demo, the designer has explored circular step indicators, text-only progress, and a thinner progress-bar treatment. Some approaches have already been rejected, while another remains in progress.

When the designer returns two days later, the new session intentionally contains only:

Continue simplifying the mobile checkout header while keeping progress clear.

It does not contain the previous design alternatives, rejection reasons, current direction, or next experiment.

Breadcrumb embeds this incomplete context, searches persistent Work-State Memory in CockroachDB, retrieves semantically relevant past states, and reconstructs where the work actually stopped.

The agent recovers information that was absent from the returning session: what had already been tried, why certain directions were rejected, which direction was currently promising, what remained unresolved, and what to try next.

That is the core experience:

Welcome back. I remember where you left off.

How we built it

The system has two main flows.

Capture

Work Context
→ Claude extracts a structured Work State
→ MiniLM generates a semantic embedding
→ Work State + embedding are persisted in CockroachDB

Recall

Partial new-session context
→ MiniLM generates a semantic query embedding
→ CockroachDB distributed vector search retrieves relevant Work States
→ Claude reconstructs the unfinished frontier
→ Breadcrumb recommends where to resume

The production backend runs on AWS Lambda and is exposed through a Lambda Function URL.

The public Web Demo is deployed on Vercel and communicates directly with this production backend over HTTPS.

Why CockroachDB

CockroachDB is not simply cloud storage for Breadcrumb.

It is the agent's persistent memory layer.

Each Work State is stored both as structured, inspectable state and as a semantic vector representation. CockroachDB Distributed Vector Indexing allows the Recall Agent to find relevant past states even when the user returns with incomplete or differently worded context.

We deliberately test this by removing historical design decisions from the returning session.

The production Recall successfully recovers information that exists only in persistent memory.

Our acceptance test ends with:

PASS: partial context retrieved the Mobile Checkout work frontier.

We also use CockroachDB Cloud Managed MCP Server as a read-only agent/developer inspection path into the same persistent memory, allowing stored Work States and unresolved frontiers to be inspected directly.

How we use AWS

AWS Lambda runs the production Recall backend.

Lambda handles the API requests that trigger Work-State extraction, embedding generation, CockroachDB persistence, semantic retrieval, and Recall reconstruction.

We initially implemented support for Amazon Bedrock Titan Text Embeddings V2. Because our newly created AWS account remained temporarily unauthorized for Bedrock inference during development, we kept the embedding layer provider-independent and switched the production path to a local quantized MiniLM model rather than mocking the integration or blocking the project.

AWS Lambda remains a real part of the production runtime.

The hardest part

The hardest problem was not storing data.

It was deciding what deserves to become memory.

A detailed activity history might remember:

"The designer changed the checkout progress indicator several times."

That is still history.

A resumable Work State remembers something different:

Circular step indicators were rejected because they consumed too much vertical space. Text-only progress did not provide enough progress awareness. A thin progress bar with a compact step label was the current direction, while the remaining question was how to preserve progress awareness without adding visual clutter.

The distinction became our core design principle:

Do not preserve more history. Preserve the minimum state required to continue.

Another challenge was making semantic retrieval visibly necessary rather than adding vector search as a technical checkbox.

To test that honestly, our returning-session prompt deliberately excludes the historical details we expect the agent to recover. If those details appear in Recall, they must have come from persistent memory.

What we learned

We learned that useful agent memory is not necessarily about remembering more.

It is about remembering the right abstraction.

For unfinished work, facts about the user are often less important than the state of the work itself: intent, decisions, failed directions, unresolved questions, and the next intended action.

We also learned that memory should be inspectable. Through Why this recall?, the demo exposes the real memories used during retrieval, including memory IDs, vector distances, and recovered information.

Demo integrity

The Mobile Checkout workspace and initial design scenario are intentionally pre-seeded so the hackathon demo is deterministic and easy to evaluate. It is a representative product-design workspace, not a real Figma integration.

The memory pipeline itself is real.

The following execute in production:

  • LLM Work-State extraction
  • semantic embedding generation
  • CockroachDB persistence
  • CockroachDB distributed vector retrieval
  • retrieved-memory selection
  • LLM Recall reconstruction
  • AWS Lambda backend execution

The returning session deliberately lacks the historical design decisions that the Recall Agent later recovers.

What's next

The hackathon demo focuses on one controlled product-design scenario, but Work-State Memory is intentionally broader.

For a designer, the unresolved frontier might be a design decision.

For a developer, it might be a hypothesis being tested.

For a writer, it might be an unresolved narrative decision.

For a researcher, it might be the question they were trying to answer.

The longer-term vision for Breadcrumb is a low-friction companion that captures these states across real desktop workflows and helps people resume meaningful work without reconstructing their mental context from scratch.

Not just what you did. Where you left off.

Built With

Share this project:

Updates