# I Built Verto > Source: > Published: 2026-10-25 22:34:21+00:00 # Why I built “Verto” tl;dr - this week I built and open sourced [Verto](https://github.com/jdamon96/verto), a utility library that watches folders and automatically converts documents to Markdown for AI agents. ## 1. The broader problem - enterprise knowledge context - Since January, I've been working on applied AI at Spectrum Equity. - One of my focuses has been making the firm's internal knowledge and context accessible to AI agents. - This isn't a novel problem: everyone recognizes the opportunity, but solving it “well” is hard. ## 2. What I think a good solution looks like (what “solving it well” means) - [Andrej Karpathy's *LLM Wiki*](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) is a seminal post in the emerging “enterprise knowledge management for AI” space. It describes something close to my ideal end state: continuously transforming an organization's raw information into a useful, AI-native knowledge base. - I've spent much of this year looking for a startup or managed solution that could implement this vision in an enterprise setting. - I have a few strong preferences about how this should work: - **Portability:** Outputs should be standard, portable files rather than proprietary representations. - **Transparency:** The transformation process should be understandable, with explicit logs. - **Configurability:** The entire pipeline should be configurable, ideally through explicit, stateful configuration files. - **Minimal vendor lock-in:** I should be able to change providers or tools without rebuilding everything. - Despite the number of startups pursuing enterprise knowledge management, I haven't yet found a solution that nails things on all these fronts & I'm comfortable fully committing to. ## 3. The pragmatic, 80/20 approach - In the meantime, we still need our agents to leverage the firm's internal knowledge. I don't want perfect to be the enemy of good. - Our approach has been to identify the 20% of documents that contain roughly 80% of the relevant institutional context and co-locate them in a shared drive. - I've written agent skills that explain where these documents live and when they're relevant. - Rather than building or purchasing an elaborate knowledge infrastructure, this gives us much of the utility with a fraction of the complexity. - This approach has also been reinforced by a broader shift this year (2026) in how agents retrieve information: - Agents have become increasingly capable of navigating files and using basic tools like `grep` ,`find` , and`cat` . - [Cursor moved away from semantic codebase indexing in favor of grep-based retrieval](https://forum.cursor.com/t/what-do-you-think-about-cursor-removing-the-codebase-indexing-settings/165899/10) . - [Mintlify adopted a filesystem-style interface](https://www.mintlify.com/blog/how-we-built-a-virtual-filesystem-for-our-assistant) that lets agents search and explore documentation, rather than relying solely on traditional top-K retrieval. - Agents have become increasingly capable of navigating files and using basic tools like - These developments make me increasingly comfortable with the idea that a well-organized collection of files, plus competent agents, can deliver much of the value of a more elaborate RAG system. ## 4. The remaining gap - Many of our most valuable internal documents are PDFs (unsurprisingly, given that we're an investment firm). - Models are increasingly capable of reading PDFs directly, but it's more efficient to have the content available as Markdown rather than requiring repeated parsing. - We'd already centralized the documents and built the agent skills. What was missing was a lightweight utility that would continuously convert new PDFs into Markdown. - Solutions like [Reducto](https://reducto.ai/) and[Extend](https://www.extend.ai/) already do excellent document parsing. I wanted a lightweight utility that would continuously orchestrate them. - I found an open-source project called [drop2md](https://github.com/docdyhr/drop2md) that came close, but I wanted two things it didn't offer: - **Multiple explicitly configured directories** to watch and process independently. - **Integration with commercial parsing APIs** like Reducto and Extend, rather than being limited to local conversion. - I couldn't find anything that combined these capabilities with the simplicity, transparency, and configurability I wanted. ## 5. So I built Verto - I spent a couple of days creating Verto, a lightweight utility that scratches this exact itch. - Verto continuously converts documents to Markdown across multiple specified directories, using interchangeable parsing providers. - A few deliberate design choices: - **Configuration:** Everything is configured through JSON files that live alongside the source documents. - **Directory selection:** Users can explicitly configure multiple directories to watch and process continuously. - **Adjacent outputs:** Converted Markdown is stored in`_markdown` folders next to the source documents. - **Logging:** Processing activity is explicitly logged in JSONL files. - **Provider flexibility:** Parsing providers are interchangeable, with current support for Reducto and Extend and the ability to add tools like Docling. - It's deliberately simple, configurable, and transparent. - Verto isn't an attempt to solve the entire enterprise knowledge problem. It's a small piece of infrastructure that solves an immediate need without locking us into a particular vision for the rest of the stack. See Verto here: [https://github.com/jdamon96/verto](https://github.com/jdamon96/verto).