ThreadKeeper

ThreadKeeper is an Alexa+ continuity agent that captures your working context before interruptions and reconstructs goals, decisions, blockers, changes, and next steps when you return

Comment

Inspiration

Modern developer tools are excellent at remembering files, commits, and conversations — but surprisingly bad at remembering what you were thinking when you stopped working.

After an interruption, finding the code is usually easy. The expensive part is reconstructing the mental state around it: what you were trying to achieve, what you believed was true, why you made a decision, what was still uncertain, and what you planned to do next.

ThreadKeeper started with one simple idea:

What if you could say “Alexa, park this” before stepping away, and later ask “Alexa, where was I?”

That became ThreadKeeper: a continuity layer for developer attention.

What it does

ThreadKeeper captures a structured checkpoint of active work, including:

  • current goal
  • decisions
  • assumptions
  • Git workspace evidence
  • relevant artifacts
  • blockers
  • unfinished work
  • next actions

When the developer returns, ThreadKeeper does more than replay an old checkpoint.

It compares the saved context with the current Git workspace and produces a Continuity Diff:

What was true then? What changed while I was away? What needs to be reconsidered now?

For example, our demo begins while investigating multi-currency payment validation.

The developer says:

“Alexa, park this.”

ThreadKeeper captures the working context and persists it in Amazon Bedrock AgentCore Memory.

While the developer is away, src/payment.ts changes.

Later, from a fresh process, the developer asks:

“Alexa, where was I?”

ThreadKeeper retrieves the previous checkpoint, inspects the current Git state, detects that the supporting evidence changed, marks the previous assumption as Needs Review, preserves anything it cannot prove as Unknown, and recommends a grounded next action.

It never claims the bug was fixed or guesses who changed the file without evidence.

How we built it

ThreadKeeper is built around a self-hosted Model Context Protocol (MCP) server using Streamable HTTP.

It exposes six working MCP tools for continuity workflows:

  • capture_checkpoint
  • resume_thread
  • compare_current_state
  • find_decision
  • find_unfinished_work
  • create_handoff

The core architecture combines three sources with intentionally different responsibilities.

Git Workspace — Authoritative Truth

Git provides deterministic evidence about the current workspace, including branches, commits, file changes, diffs, artifact hashes, and repository state.

Amazon Bedrock AgentCore Memory — Persistent Memory

AgentCore Memory stores ThreadKeeper checkpoints across sessions and process restarts. We verified persistence by saving a checkpoint in one process, terminating it, and retrieving and resuming that work from a completely separate process.

Amazon Nova Lite — Grounded Interpretation

Nova Lite helps explain the impact of changed evidence while remaining subordinate to deterministic Git facts.

ThreadKeeper separates information into four epistemic categories:

Observed → Derived → Inferred → Unknown

This prevents the model from turning plausible explanations into unsupported facts.

For the Alexa+ track, we built an Alexa-style conversational experience around the self-hosted MCP workflow, allowing the complete “park this” and “where was I?” interaction to be demonstrated naturally.

The Continuity Diff

The key idea behind ThreadKeeper is that memory alone is not enough.

Old context can become stale.

ThreadKeeper therefore compares the checkpoint from THEN with workspace evidence from NOW.

If an artifact supporting an earlier assumption changes, ThreadKeeper does not automatically declare that assumption false or fixed.

Instead, it marks the assumption as requiring review and grounds the next action in the evidence that actually changed.

This creates a safer form of AI-assisted continuity than simply asking a model to remember previous conversations.

Challenges

One of the hardest problems was defining the boundary between memory and truth.

A persistent memory system can accurately remember what a developer believed yesterday, while that belief may no longer be valid today.

We therefore designed ThreadKeeper so Git remains authoritative, AgentCore preserves historical context, and model reasoning is advisory.

Other challenges included:

  • detecting stale assumptions without inventing causes
  • preserving structured checkpoints across process death
  • implementing MCP Streamable HTTP correctly
  • querying AgentCore Memory across sessions
  • preventing model-generated observations without supporting evidence
  • handling Git porcelain output safely
  • building a voice-oriented workflow without reducing the product to a simple chatbot

We documented technical friction throughout development so that the integration experience can also provide useful feedback for the underlying developer ecosystem.

Accomplishments that we're proud of

ThreadKeeper now completes the entire continuity loop:

Park → Capture → Persist → Interrupt → Detect Change → Reconstruct → Resume

The final system includes:

  • a working self-hosted MCP server
  • six verified MCP tools
  • real Git workspace inspection
  • persistent Amazon Bedrock AgentCore Memory
  • grounded Amazon Nova Lite reasoning
  • cross-process checkpoint recovery
  • Continuity Diff
  • stale-assumption detection
  • a working Alexa-style conversational interface
  • a dynamic visual continuity console
  • 87 automated tests passing

Most importantly, the final demo uses the real application and real backend behavior rather than pre-rendered or hardcoded product results.

What we learned

Building ThreadKeeper changed how we think about AI memory.

Remembering more is not necessarily the answer.

A useful agent needs to distinguish between:

what happened, what was believed, what can be derived, and what is still unknown.

Persistent memory becomes substantially more useful when combined with fresh deterministic evidence.

We also found MCP to be a strong boundary for this architecture because the continuity engine remains independent of the conversational interface. The same tools could eventually be used by IDE assistants, coding agents, research agents, or other AI clients.

What's next

ThreadKeeper currently focuses on developer continuity, but the underlying model can extend much further.

Next we want to explore:

  • continuity across multiple repositories and devices
  • handoffs between different AI agents
  • richer long-term memory strategies
  • IDE integrations
  • team continuity and shared handoffs
  • evaluation benchmarks for context reconstruction
  • portable cognitive checkpoints between tools

The long-term idea is simple:

Your code already has version control. Your train of thought should too.

ThreadKeeper — Never lose your train of thought.

Built With

Share this project:

Updates

Submission history