Note: this post covers V1 of the project. It's a real, working assistant I use daily — not a finished product. There's a V2 in the works, and I'd genuinely love your ideas on it (more on that at the end).
Why I built this
I started learning agentic AI the way most people probably do — watching a course, working through LangChain and LangGraph fundamentals one concept at a time: state, nodes, edges, tools, memory, human-in-the-loop, guardrails. It's a lot of scaffolding before you get to build anything real, and at some point the tutorial-project itch wears off. I didn't want to build another "spec-to-API agent" demo that I'd never open again. I wanted something I'd actually use.
So I picked a problem I genuinely have: too many files, scattered across Downloads, Desktop, and Documents, and no memory of where anything is. The result is my-assistant — an always-on-top desktop widget where I can just ask, in plain English, "what did I write about TaskFlow's approval flow?" or "open my timesheet from last week," and it finds it.
What it actually does
Under the hood, it's one AI agent — not a swarm of them, more on that below — built with LangChain and LangGraph, backed by a local vector database (Qdrant) for semantic search, and a Groq-hosted model for the actual reasoning. It has six tools: search by content, search by filename, open a file or folder, count indexed files, list indexed folders, and index new files. A Flet-based UI wraps all of it into a small, always-on-top chat widget that sits on my desktop.
The part I'm most proud of isn't the search — it's that the index stays alive on its own. A background file-system watcher notices when I download something new, edit an existing document, or delete a file, and updates the index automatically, without me ever running a manual command. Ask it "index my new PDFs" and it'll do that too, or just let it work silently in the background.
One agent, not many — and why that took me a while to actually understand
Early on, I assumed a "long process with lots of steps" — scan folders, extract text, chunk it, embed it, store it — meant I needed multiple agents working together. It doesn't, and figuring out why it doesn't was one of the more useful lessons of this whole project.
The thing that actually determines whether you need an agent isn't how many steps a process has — it's whether any step requires judgment on ambiguous input. Extracting text from a PDF has exactly one correct way to do it, every time. So does chunking, embedding, and writing to a vector store. None of that needs an LLM's reasoning — it needs a deterministic pipeline. The only place genuine ambiguity shows up is right at the front: interpreting what I actually meant when I typed something into the chat box. That's the entire agentic surface area. Everything after it is plumbing.
That reframing changed how I think about when multi-agent design is actually worth it — not "this has many steps," but "does some sub-task need a genuinely different kind of judgment or persona than the rest." More on where that might actually apply in V2.
The debugging stories that taught me the most
A few things went wrong along the way that ended up teaching me more than the parts that worked first try.
The index that quietly ate my own virtual environments. My exclusion logic checked for folders literally named venv or .venv — until I found one named venv_rag, and hundreds of site-packages files from unrelated projects showed up in my search results. The fix wasn't adding more exact name checks; it was detecting virtual environments structurally, by the presence of pyvenv.cfg, so it doesn't matter what anyone names them.
"Storage folder is already accessed by another instance." Once I added a background watcher running independently of the chat agent, both started occasionally trying to open their own separate connections to the same local Qdrant database at the same moment — something that's fine for a single sequential agent, but breaks the instant you have two independent threads touching the same embedded database. The fix was a shared singleton connection instead of a fresh one per call.
The agent that wouldn't stop flailing. I asked about a table buried inside a Word document, and the agent, unsatisfied with its first search, started calling unrelated tools — trying to re-index files, trying to physically open the document in Word — cycling between them instead of just telling me it couldn't find something. The actual root cause, once I dug in with a raw database query, was almost funny: the content was there all along. It just wasn't ranking in the top 3 search results for that particular phrasing. The real fixes were tightening the system prompt so the agent stops and tells me instead of flailing, and widening how many results it pulls per search.
A spreadsheet answer that quietly wasn't stale, but the reasoning behind it was invented. Asking about a folder's contents, the agent gave me the right file count, but with a made-up explanation for why it couldn't show subfolders — a limitation that didn't actually exist. It's a good reminder that a technically correct answer can still come with confidently wrong reasoning attached, and it's worth checking both.
Windows Explorer creating a "deleted" file that was never indexed. Creating a new blank text file somehow triggered a "removed from index" message before the file even had content. Turned out Explorer's file-creation flow fires as a rename event under the hood, and my delete-handler was printing success messages unconditionally, regardless of whether anything was actually removed. A small bug, but the kind that erodes trust in a tool's logs if you don't catch it.
None of these were exotic problems. They were the ordinary friction of building something real instead of following a tutorial — and that's exactly why they were worth having.
What's next (and where I'd like your ideas)
This is V1. It works, and I use it daily, but it's not the end state. A few directions I'm considering for V2, specifically where I think multiple specialized agents would actually earn their keep rather than just be complexity for its own sake:
A writing agent that can draft summaries or emails from documents the file agent retrieves — a genuinely different skill and voice than "find and open files."
A vision agent for screenshots and scanned documents, if reasoning about images turns out to need real judgment rather than a single API call.
A proactive mode that notices clutter or duplicate files and suggests cleanup, instead of only reacting to what I ask.
Packaging it as a real standalone Windows app, so it doesn't need a terminal window open in the background.
If you've built something like this, or have a feature you'd genuinely want out of a personal file assistant, I'd like to hear it — drop a comment or reach out. Still very much a work in progress, and that's kind of the point.
GitHub :- https://github.com/IsaacNatarajan/My-Assistant/tree/main
Top comments (0)