{"slug": "i-built-verto", "title": "I Built Verto", "summary": "J. Damon built and open-sourced Verto, a utility library that watches folders and automatically converts documents to Markdown for AI agents, publishing the code on GitHub. The tool was created to fill a gap in Spectrum Equity's internal knowledge pipeline, where valuable documents are largely PDFs and existing parsers such as Reducto and Extend handle extraction but not continuous orchestration. Verto reflects a broader 2026 shift toward file-based agent retrieval, cited by the author through Cursor's move away from semantic codebase indexing in favor of grep-based retrieval and Mintlify's filesystem-style documentation interface.", "body_md": "# Why I built “Verto”\n\ntl;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.\n\n## 1. The broader problem - enterprise knowledge context\n\n- Since January, I've been working on applied AI at Spectrum Equity.\n- One of my focuses has been making the firm's internal knowledge and context accessible to AI agents.\n- This isn't a novel problem: everyone recognizes the opportunity, but solving it “well” is hard.\n\n## 2. What I think a good solution looks like (what “solving it well” means)\n\n- [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.\n- I've spent much of this year looking for a startup or managed solution that could implement this vision in an enterprise setting.\n- I have a few strong preferences about how this should work:\n  - **Portability:** Outputs should be standard, portable files rather than proprietary representations.\n  - **Transparency:** The transformation process should be understandable, with explicit logs.\n  - **Configurability:** The entire pipeline should be configurable, ideally through explicit, stateful configuration files.\n  - **Minimal vendor lock-in:** I should be able to change providers or tools without rebuilding everything.\n- 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.\n\n## 3. The pragmatic, 80/20 approach\n\n- 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.\n- 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.\n- I've written agent skills that explain where these documents live and when they're relevant.\n- Rather than building or purchasing an elaborate knowledge infrastructure, this gives us much of the utility with a fraction of the complexity.\n- This approach has also been reinforced by a broader shift this year (2026) in how agents retrieve information:\n  - Agents have become increasingly capable of navigating files and using basic tools like `grep` ,`find` , and`cat` .\n  - [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) .\n  - [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.\n- Agents have become increasingly capable of navigating files and using basic tools like \n- 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.\n\n## 4. The remaining gap\n\n- Many of our most valuable internal documents are PDFs (unsurprisingly, given that we're an investment firm).\n- 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.\n- 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.\n- 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.\n- 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:\n  - **Multiple explicitly configured directories** to watch and process independently.\n  - **Integration with commercial parsing APIs** like Reducto and Extend, rather than being limited to local conversion.\n- I couldn't find anything that combined these capabilities with the simplicity, transparency, and configurability I wanted.\n\n## 5. So I built Verto\n\n- I spent a couple of days creating Verto, a lightweight utility that scratches this exact itch.\n- Verto continuously converts documents to Markdown across multiple specified directories, using interchangeable parsing providers.\n- A few deliberate design choices:\n  - **Configuration:** Everything is configured through JSON files that live alongside the source documents.\n  - **Directory selection:** Users can explicitly configure multiple directories to watch and process continuously.\n  - **Adjacent outputs:** Converted Markdown is stored in`_markdown` folders next to the source documents.\n  - **Logging:** Processing activity is explicitly logged in JSONL files.\n  - **Provider flexibility:** Parsing providers are interchangeable, with current support for Reducto and Extend and the ability to add tools like Docling.\n- It's deliberately simple, configurable, and transparent.\n- 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.\n\nSee Verto here: [https://github.com/jdamon96/verto](https://github.com/jdamon96/verto).", "url": "https://wpnews.pro/news/i-built-verto", "canonical_source": "https://jackdamon.org/blog/why-i-built-verto/", "published_at": "2026-10-25 22:34:21+00:00", "updated_at": "2026-10-25 22:42:07.224928+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "large-language-models"], "entities": ["Verto", "J. Damon", "Spectrum Equity", "GitHub", "Andrej Karpathy", "Cursor", "Mintlify", "Reducto"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/i-built-verto", "markdown": "https://wpnews.pro/news/i-built-verto.md", "text": "https://wpnews.pro/news/i-built-verto.txt", "jsonld": "https://wpnews.pro/news/i-built-verto.jsonld"}}