Conduit For Alexa+

Conduit makes Alexa remember what matters

Comment

Inspiration

The idea behind Conduit started with a simple question:

If an assistant can remember more about a person over time, how does it decide which part of that memory actually belongs in the current conversation?

Remembering everything is not the same as using memory well.

Old information can become wrong. Several memories can fit the same question. Personal information may be relevant to one task and completely unnecessary to another. And as persistent history grows, storing and searching every memory as another independent top-level record can make the problem increasingly noisy and expensive.

That became the central idea behind Conduit for Alexa+:

Remember generously. Store efficiently. Retrieve selectively. Disclose minimally. Keep the user in control.

What Conduit does

Conduit is a context-selection and memory-governance layer designed around durable personal records.

The demonstration begins with ordinary household memories. In one session, the user tells Conduit where several holiday items are stored. In a later session, the user asks where the "holiday decorations" are.

Instead of silently choosing one memory, Conduit recognizes that Christmas, Easter, and Halloween all fit and asks for clarification.

The user can also correct an existing memory. The new information becomes current while the old location remains preserved as superseded history rather than competing with the correction.

When Alexa+ needs personal context for a Christmas decorating task, Conduit supplies only the memories relevant to that task and leaves unrelated memories out.

The principle is simple:

The existence of a memory does not automatically make it appropriate context.

Conduit treats persistent memory as something that must be governed, not simply accumulated.

Chronological Context

While building the first demo, I found another problem: some questions cannot be resolved by subject alone.

Time changes meaning.

Conduit's Chronological Context experiment uses a frozen set of 36 personal records and combines the meaning of the question with the current date.

"Where are my holiday decorations?" can look forward to the next relevant holiday.

"When is my upcoming Florida trip?" looks forward.

"What was my most recent Florida trip?" looks backward.

The underlying memories do not have to change. Time and intent simply help Conduit determine which existing information is relevant now.

This extends the same principle as selective disclosure: the system should not bring forward a memory merely because it matches some words in the question.

Making persistent memory practical as it grows

Selective retrieval solves only part of the problem.

If a personal assistant remembers more and more over months or years, the underlying memory representation also matters.

A flat history can contain many related records repeating the same context. Corrections can compete with older values. Repeated events can create ties. And every additional top-level record potentially expands the set of candidates that must be considered during retrieval.

That is why I built the Database Lab.

The Database Lab explores whether related history can be organized around durable records while still preserving the original information needed to reconstruct and retrieve it.

On Conduit's frozen 36-record personal-memory fixture, the tested representation reduced:

  • 36 top-level records to 9
  • 4,204 compact bytes to 2,093
  • 48 retrieval candidates to 14
  • 32 top-result ties to 9

The goal was not merely compression. The point was to see whether persistent context could become smaller and easier to search without throwing information away.

I also did not want the idea to work only on a fixture I created myself, so I tested the general approach against recognizable external database structures including Chinook, Microsoft Northwind, and Sakila.

I then tested it against UCI Online Retail II, containing 1,067,371 sanitized transaction records.

In that test:

  • the flat representation was 268,656,307 bytes
  • the final tested representation was 142,843,530 bytes
  • representation size fell by 46.830%, removing 125,812,777 bytes
  • the schema-blind first pass reduced the top-level candidate space by 94.874%
  • exact reconstruction was preserved
  • and a 20-run local benchmark using 100 deterministic queries per run averaged 54.724 ms for the final representation versus 931.666 ms for the original flat representation — roughly a 17× improvement on that tested access path

That matters to the Alexa+ idea because Conduit's role does not have to stop at deciding which memory is relevant.

The same approach can potentially make the persistent memory underneath that decision more storage-efficient, less noisy, and cheaper to search as history grows.

Locally, that could mean retaining more useful personal context within the same device-storage constraints. At cloud scale, the same principle could allow substantially more persistent context within a given storage footprint while still narrowing retrieval to the information needed for the current interaction.

So the Database Lab and the selective-memory demo are really testing two sides of the same problem:

How do we keep more useful history without forcing the assistant to search, expose, or repeatedly store all of it every time?

Failure, correction, and derived indexes

The Database Lab also exposed an important weakness.

The durable representation made its natural access path much faster, but some reverse-access paths became worse than the original structure.

Rather than hide that result, I treated it as the next design problem.

The solution was a small, disposable derived index. The durable records remained authoritative; the index simply provided another efficient way to reach them and could be rebuilt from the source data.

The Database Lab then reruns correctness and reconstruction checks after adding that index.

That failure-and-repair cycle became one of the most useful lessons from the project:

Durable records hold the truth. Derived structures help find it.

That same separation is important for a personal assistant. Search structures can be optimized, rebuilt, or replaced without allowing them to become the source of truth about the user.

How I built it

Conduit is implemented as a local Node.js application with an MCP interface and a browser-based demonstration environment.

The contest demo contains three connected pieces:

  1. Live MCP Demo — cross-session memory, ambiguity handling, correction and supersession, and selective disclosure.
  2. Chronological Context — using question direction and the current date to narrow which personal context is relevant.
  3. Database Lab — testing whether persistent history can be represented more compactly and searched more efficiently while preserving reconstruction and correctness.

Together they explore a single memory pipeline:

retain durable history → organize it efficiently → identify the relevant context → disclose only what the current interaction needs

The repository also includes automated acceptance and regression tests so the important behavior can be reproduced rather than relying only on the video demonstration.

Challenges and what I learned

The most important lesson from Conduit was that personal memory is not just a storage problem and not just a retrieval problem.

A useful assistant needs to distinguish between:

  • remembered and relevant
  • historical and current
  • available and appropriate to disclose
  • ambiguous and safe to infer

It also needs to remain practical as the amount of persistent context grows.

The Database Lab reinforced that a clean-looking architecture can still fail from another direction. Improving one access path can make another worse. The answer was not to make the durable records more complicated, but to add a rebuildable access structure beside them.

That principle now runs through the entire project:

Durable memory preserves what happened. Derived structures make it useful. Context selection decides what matters now. Disclosure rules decide what should actually leave the memory system.

Where Conduit is going

Conduit is ultimately an experiment in making persistent personal context more useful without making it indiscriminate.

The goal is not for an assistant to remember everything it possibly can and dump that history into every conversation.

The goal is to let persistent context become richer over time while keeping it manageable:

store it efficiently, preserve its history, retrieve the right part, recognize uncertainty, and bring forward only what the current interaction actually needs.

For Alexa+, that could mean memory that is not only longer-lived, but also more selective, more efficient, and more trustworthy across sessions.

Built With

Share this project:

Updates

Submission history