-
-
CueNexa Loop — From Conversations to Follow-Through
-
Ambient Awareness, Authoritative Follow-Through
Inspiration
A lot of work starts in conversations but never makes it into a task system.
Someone says, “I’ll send the pricing deck tomorrow.” Another person says, “Can you follow up with Finance?” A decision gets made, a deadline is mentioned, or responsibility is delegated — and then the conversation ends.
Bee already makes it possible to capture and process real-world conversations. I wanted to explore what could happen after that.
The idea behind CueNexa Loop is simple:
What if conversations could become a follow-through system?
Instead of stopping at transcription or summarization, CueNexa Loop looks for unfinished conversational loops — commitments, follow-ups, delegations, deadlines, unresolved items, and actions connected to decisions — and helps surface them again when they matter.
The goal is to make sure important promises and responsibilities do not disappear when the recording stops.
What it does
CueNexa Loop connects to conversation data processed through Bee and creates a local follow-through layer on top of it.
It can detect conversational signals such as commitments, follow-ups, delegations, open questions, decisions connected to actions, and due dates.
It can also correlate related items across different conversations.
For example, one conversation might contain:
“I’ll prepare the pricing deck.”
A later conversation might contain:
“I’ll send the pricing deck tomorrow.”
CueNexa Loop can recognize that these may belong to the same continuing piece of work and group them into a persistent LoopThread.
Once a Loop is confirmed through processed Bee history, CueNexa Loop can track what changes over time and surface things such as:
- work due soon or overdue
- reopened items
- new activity
- items waiting on someone
- recently resolved work
Users can also acknowledge, snooze, pin, dismiss, and restore Loops locally without modifying the original Bee conversation history.
CueNexa Loop also supports realtime awareness through Bee.
While a conversation is happening, it can surface possible commitments or follow-ups as PROVISIONAL signals. These realtime signals never directly change persistent state. Once Bee finishes processing the conversation, CueNexa Loop returns to processed history as the authoritative source and runs the normal detection, correlation, and persistence pipeline.
How we built it
CueNexa Loop is built as a Node.js and TypeScript monorepo with separate layers for Bee integration, conversation normalization, Loop detection, correlation, persistence, user actions, notifications, and realtime awareness.
The core architecture is:
Bee processed conversations
↓
Bee adapter
↓
Normalized conversation contracts
↓
Loop detection
↓
Deterministic correlation
↓
Persistent LoopThreads
↓
Attention + follow-through
For realtime awareness, the flow becomes:
Bee realtime stream
↓
Provisional awareness
↓
Possible commitment / follow-up / deadline
↓
Bee processed history
↓
Authoritative sync
↓
Existing Loop pipeline
Processed Bee history always remains authoritative.
CueNexa Loop uses SQLite for local persistent state. Raw realtime transcript data and provisional signals are not persisted.
The system is currently deterministic rather than LLM-driven. I wanted the first version to be explainable, testable, conservative, and reproducible before adding probabilistic AI.
The project currently includes commands for syncing, reviewing, tracking history, handling local follow-through actions, previewing notifications, delivering deduplicated notifications, and running the realtime foreground watcher.
Challenges we ran into
One of the biggest challenges was understanding the difference between Bee realtime data and Bee processed historical data.
Realtime events can identify conversations using UUIDs, while processed history uses a different conversation identifier. CueNexa Loop therefore needed a bounded in-memory identity bridge, but only when Bee explicitly provides both IDs. It never guesses identity based on text or timestamps.
Realtime delivery introduced another challenge. Connections can drop, processed-history refreshes can overlap with new events, and repeated refresh requests could easily become noisy or inefficient.
To handle this, CueNexa Loop uses a bounded refresh coordinator that rate-limits historical refreshes, coalesces repeated requests, preserves pending refreshes, and repairs realtime gaps by returning to authoritative processed history.
We also discovered a subtle long-running memory issue during testing. An early watcher implementation could accumulate promise reactions while the realtime stream remained silent. The final implementation uses one sequential realtime event consumer and one independent control loop, keeping long-running watch sessions bounded.
Privacy was another constant design constraint. CueNexa Loop needed enough persistent state to provide continuity without turning into another transcript database.
That led to a strict separation between ephemeral conversation content and durable structural follow-through data.
Accomplishments that we're proud of
CueNexa Loop evolved through four major phases.
Phase 1 — Detection and correlation
Detect unfinished work from processed Bee conversations and connect related items across multiple conversations.
Phase 2 — Persistent follow-through
Give Loops stable local identities, lifecycle history, change tracking, and deterministic attention ranking.
Phase 3 — Proactive follow-through
Add acknowledgement, snooze, pin, dismiss, review workflows, notification planning, and delivery deduplication.
Phase 4 — Ambient realtime awareness
Detect provisional signals while a conversation is happening and safely hand them off to the authoritative processed-history pipeline.
I am especially proud that realtime awareness did not require weakening the original privacy or reliability model.
CueNexa Loop currently has no cloud backend, no external LLM dependency, no telemetry, no analytics, and no Bee write-back.
The current implementation also includes 425 automated tests across 49 test files, covering detection, correlation, persistence, migrations, privacy behavior, realtime ingestion, identity reconciliation, follow-through actions, notification deduplication, and long-running watcher behavior.
What we learned
The biggest lesson was that conversation intelligence is not only about producing better summaries.
A summary tells you what happened.
A follow-through system helps make sure what people said they would do actually happens.
I also learned that realtime information should not automatically become permanent truth.
Separating provisional realtime awareness from authoritative processed history made the architecture much safer and easier to reason about.
Another important lesson was that privacy works better when it is designed as an architectural boundary instead of added as a feature later.
By keeping raw realtime content ephemeral and persisting only the structural information necessary for follow-through, CueNexa Loop can provide continuity without becoming a second transcript archive.
What's next for CueNexa Loop
The next step is to turn the proven local engine into a more complete everyday product experience.
Areas I want to explore include a desktop or tray interface for active Loops, native local notifications, richer visualization of a Loop's conversational history, and tighter integration with the broader CueNexa meeting-coach experience.
I also want to explore optional AI assistance for confirmed LoopThreads while keeping deterministic detection and processed Bee history as the trusted foundation.
The long-term vision is for CueNexa Loop to become a personal continuity layer for conversations.
Not another transcript.
Not another meeting summary.
A system that remembers what still needs to happen.
Built With
- bee
- bee-cli
- github-actions
- node.js
- npm
- sqlite
- typescript
- vitest
- workspaces
- zod
Log in or sign up for Devpost to join the conversation.