Wisp

Wisp cleans up your messy desktop. It shows you what you have, helps you organize it, and makes it easy to delete what you don’t need, built with privacy and safety in mind

Comment 2

Inspiration

We were tired of pretending our desktops were fine.

Everyone has that one folder. Downloads. Desktop. A random external drive. It starts clean. It ends up as digital entropy. Thousands of files, no structure, duplicates, installers, screenshots, resumes named resume_final_FINAL_v7.pdf.

We realized something simple. File systems have barely evolved. Search is primitive. Organization is manual. Cleanup is risky. And every “smart” tool either deletes too aggressively or sends your data to the cloud.

So we asked a different question.

What if your file system had memory?

What if it actually understood what your files were, could answer questions about them, suggest cleanup safely, and only ever acted with your permission?

That’s how Wisp started.

What it does

Wisp is an agentic file system manager with memory.

It scans and indexes your folders locally. It embeds your files into a vector database and stores structured metadata in SQLite. It can answer questions like:

  • “Where are my resume files?”
  • “Which DMG installers are safe to delete?”
  • “What was that PDF about cloud security?”

It does not blindly delete anything.

Instead:

  • It detects potentially deletable files.
  • It lets you review them.
  • It quarantines instead of deleting.
  • It supports undo.

There is an assistant that can converse about your PC. It retrieves relevant files from memory and shows sources. You can speak to it using voice. It responds with TTS.

There is a Tinder-style review flow for deletables. A debloater for Windows. A file visualizer. OCR and text extraction. Batch organization with preview and apply.

How we built it

The core spine is a scan and index pipeline.

  1. A Celery job system manages long-running tasks.
  2. A scanner walks the file system while skipping noise and artifacts.
  3. Each file goes through an embedding pipeline.
  4. Metadata is written into SQLite.
  5. Embeddings are stored in a vector database (LanceDB).
  6. OS-level tags are applied carefully and only in one place to avoid race conditions.
  7. The frontend polls job state and renders progress in real time.

We made file identity stable. Files are tied to a file_id, not their path. If you move or rename a file, embeddings stay valid. Only the path updates.

We built quarantine instead of delete. Quarantine moves files into a safe location and logs the action. Undo is a first-class citizen.

We wired Electron IPC to a FastAPI backend. We handled async pipelines inside Celery without event loop conflicts. We built retry logic for SQLite to handle database locks.

The assistant queries the vector store and renders sources. The voice layer wraps that with STT and TTS.

A lot of it was brute force iteration. Write tests. Break everything. Fix event loops. Fight SQLite. Refactor tagging. Remove double ownership. Build integration tests with realistic file trees.

Challenges we ran into

Concurrency was brutal.

Running async embedding pipelines inside Celery while also serving FastAPI forced us to rethink event loop boundaries. We had to isolate loops in separate threads to prevent runtime errors.

SQLite locking issues appeared under rapid writes. We implemented exponential backoff retries and extended timeouts.

We initially had double-tagging of files. The pipeline and the task layer both tried to apply OS tags. That created inconsistent state. We refactored to enforce single ownership.

UI cohesion was harder than backend logic. Features existed, but without progress bars, logs, and visible state, it felt fake. Wiring flows end-to-end took more effort than building them individually.

Cross-platform behavior was unpredictable. Windows and macOS tagging behave differently. Permissions complicate everything.

Most of all, scope control was a constant fight. Every new idea was exciting but we had to repeatedly return to the spine.

Accomplishments that we're proud of

We did not just build features, rather, we built a coherent system.

  • A full scan and index job spine with progress tracking.
  • A memory layer that can answer semantic questions about your files.
  • Stable file identity that survives renames and moves.
  • Safe quarantine with undo.
  • Agentic organization built on top of the same vector store.
  • Local-first architecture with explicit privacy boundaries.
  • 50+ backend tests including integration tests with realistic file trees.

We turned a messy folder into something navigable and understandable. Not by hardcoding rules, but by giving the system memory.

And it actually runs.

What we learned

Architecture matters more than features.

If your core job system is unstable, everything above it feels like a hack.

Observability matters. Without visible progress and logs, users assume nothing works.

Single ownership of responsibility is critical. Two parts of the system should never fight over the same side effect.

Safety is a feature. Undo builds trust. Quarantine builds trust. Transparency builds trust.

And building something agentic on top of a real operating system is harder than building something agentic in a sandbox.

What's next for Wisp

We want to go deeper into local-first AI.

  • Move toward local LLMs by default.
  • Stronger privacy guarantees with explicit data boundaries.
  • Smarter classification models tuned for file systems.
  • Better visual analytics for storage and file drift over time.
  • Real-time monitoring rather than manual scans.
  • A refined assistant that understands context across sessions.
  • Production-level UI polish with visible logs, progress, and safety disclosures.

Wisp has the foundation. Now it needs refinement.

The goal is simple.

Your computer should not feel like a landfill.

It should feel like it understands you.

Built With

Share this project:

Updates