# The chat window is a dead end > Source: > Published: 2026-08-18 19:21:52+00:00 # The Chat Window is a Dead End *By Diego Guridi* TL;DR: The chat window is good at one thing: a question you will never ask again. Everything worth keeping drifts toward files. The file tree is not a replacement for the conversation, it is what the conversation should be pointed at, and almost nobody has designed a surface around that idea yet. ## The problem you have already felt You open a new chat with your AI and describe the project: what you are building, the constraints, the decisions you have already made. The model catches up, you get something useful, and by the end of the session some of that thinking has become code. That is where the reasoning disappears. The code captures what you built, not why you built it that way or what you decided against. Come back three days later and you explain it all again, slightly differently, and get a slightly different answer. A week in you have six conversations in your history and no idea which one holds the decision that matters. The code keeps accumulating, and the gap between what is built and why grows with every session. Coding harnesses keep memory files, and conventions like AGENTS.md carry context between sessions automatically. That genuinely helps. But those files are written for the agent to read, not for you to work in. You rarely see them, you rarely edit them, and when the context in them is wrong there is no obvious place to go and fix it. This is not a failure of the model. It is a failure of the surface. You have been doing serious, cumulative work in a tool designed for questions you ask once and forget. Everything worth keeping ends up in files. The file tree is not a replacement for the conversation. It is what the conversation should be pointed at, and it is the thing that keeps the reasoning from vanishing into the code. ## The file tree is the answer The file tree is not a new idea. It is one of the oldest interfaces in computing, and it has outlasted every generation of tooling built on top of it. Databases, applications, frameworks, paradigms: all of them have come and gone, and the file tree is still there underneath, organising everything. There is a reason for that. Files and folders are a primitive: they presuppose almost nothing about what you are doing, which means they bend to any kind of work rather than constraining it to a shape someone else decided in advance. The answer to losing your reasoning into a chat window is not a smarter chat window. It is the oldest solution in computing: write it down, put it somewhere, give it a name. The file tree is that somewhere, and it turns out to be exactly the right shape for this problem. **You can see what you have built.** In a chat window your context is invisible, somewhere above the input box. A file tree is a diagram of it: what exists, how it is grouped, what is missing. You cannot improve something you cannot see. **Text in a file is an artifact.** Every good sentence you write in a chat window is gone the moment the session ends. A file survives the session, and it is better each time because you edit it rather than retype it. **A file has an address.** You can point at it, hand it to someone else, tell an agent to go and read exactly that. A paragraph twenty turns up in a chat has no address at all. **You improve context by editing it, not re-explaining it.** In a chat, every correction piles more text on top of the old text. In a file, you change the sentence and the wrong version is gone. Over weeks, that difference adds up. ## Markdown is the right format for this Markdown is what these files should be written in, and there are a few good reasons for that. Plain text is what the model actually reads. Nothing is converted or extracted on the way in, so what you see is what the agent sees. Headings, lists and links mean the same thing to a person and to a model, in the same characters. There are no fonts to pick and no layout to fiddle with. The only thing left to work on is what the words say. And a decent renderer turns the same file into something genuinely pleasant to read, with proper headings, tables and diagrams, so you are not staring at markup unless you want to. Underneath it is still just a text file, which means it outlives whatever tool you opened it in. ## What a plain file system cannot do The trouble is that a file system gives you files and folders and nothing else. It does not know when something changed. It does not tell you that a collaborator, human or agent, just edited the file you are looking at. There is no way to leave a comment anchored to a specific sentence, no way to say "this paragraph needs rethinking" without either editing the file itself or sending a message somewhere else entirely. There is no presence: you cannot see who is in the document with you, or whether anyone is. And an agent is not a first-class participant. It is a process that reads files and writes files, but it has no name in the tree, no place of its own, no way to be mentioned, no inbox. You cannot ask it a question by writing directly in the document. You cannot see what it has read or what it is working on. ## Git is close, but it overshoots The obvious answer to this is Git. A repository gives you a shared file tree that multiple people can work in, a full history of every change, and a structured way to propose and review edits. For code, that structure earns its cost. A pull request, a review, a merge: these are the right ceremonies when what you are changing is software that runs in production. But for the kind of work this post is about, Git overshoots. Editing a sentence in your project brief should not require a branch. Leaving a note on a paragraph should not require a commit message. And a spec that is still being argued out is not ready for a repository: it will change ten times before anyone implements it, and forcing that into commits and reviews makes you formalise a decision you have not made yet. The overhead that makes Git trustworthy for code makes it friction for thinking. By the time you have opened a pull request to update a decision document, the moment has passed. The file tree is the right foundation. But a plain file system is just storage, not a workspace, and a repository is a deployment pipeline, not a thinking environment. What is missing is the live layer: presence, comments anchored to text, agents as named participants, a mention that lands somewhere. Collaboration without the ceremony. ## My answer to this is [markdown-den](https://markdown-den.com) This is the problem I have been building for, and [markdown-den](https://markdown-den.com) is what I built to solve it. [markdown-den](https://markdown-den.com) is a collaborative workspace for markdown files, where both people and AI agents are participants. You get a file tree in the browser, you write in markdown, and your agents connect to the same workspace over MCP and read and write the same files you do. The idea was to take the file tree, which already works, and add only what is missing: **Live, multiplayer editing**, with cursors and presence, so you can see who is in a document and watch a change land as it happens, whether the thing writing is a person or an agent. You can work in the raw markdown or in a rendered view that is easy to read, whichever suits what you are doing.**Comment threads anchored to a specific sentence**, so a note lands on the thing it is about.** Agents as named participants with their own folders**, so an agent is a collaborator rather than a process running somewhere off to the side.** Mentions and notifications**, so you can ask an agent something by writing it into the document. No branches, no commits, no pull requests. Just markdown files you and your agents both write in, reachable from anywhere: a browser on your desktop, your phone on the train, an agent running on a machine somewhere else entirely. No clone, no checkout, no local copy to keep in sync. This post is an example of it. I wrote it by talking to Claude through an earpiece, phone in my pocket, wandering in and out of the room: sometimes reading the file change live on my desktop screen, sometimes on the phone, sometimes not looking at anything at all. I did not type any of it. I pointed at a paragraph, said what was wrong with it, and watched it change. It was written in [markdown-den](https://markdown-den.com), and it is shared from there too: the page you are reading is the file itself. ## It quietly replaces a shelf of tools Once this is in place, the workspace stops being just somewhere to keep documents and starts doing the job of a whole shelf of tools. This is true with a single agent, and it gets better as you add more agents and more people to the workspace. It becomes a context engineering workbench. Deciding what an agent knows stops being a prompt you rewrite and becomes a question of which folder a file sits in. It becomes an orchestration layer. Numbered folders are pipeline stages, a to-do file is a queue, and an agent picks up work and strikes it off as it goes. No framework, no wiring, no configuration: the structure of the tree is the structure of the workflow. And it absorbs a surprising amount of the rest. Issue tracking, task assignment, review, project status. For a solo developer or a small team, a file tree and a few conventions cover most of what those tools were doing. Not because it is a clever replacement for them, but because their footprint was always larger than the problem. I know this because it is how [markdown-den](https://markdown-den.com) got built. As soon as the thing was usable at all, I moved its own development into it: specs, assessments, a to-do file, agents working from them. Spec-driven development, in the workspace it was building. ## Where this leads Chat is the right tool for a question you will never ask again. For everything else, for the decisions that compound, the constraints that need to be remembered, the context that has to survive Tuesday and still make sense on Friday, the file is the thing. The tree is not a replacement for the conversation. It is where the conversation gets pointed at. ## Further reading If this argument lands, you are not alone in making it. A few things worth reading: [Interpretable Context Methodology: Folder Structure as Agentic Architecture](https://arxiv.org/abs/2603.16021)(arxiv, March 2026). Replaces framework-level agent orchestration with plain filesystem structure: numbered folders as pipeline stages, markdown files as prompts and context.[Everything is Context: Agentic File System Abstraction for Context Engineering](https://arxiv.org/abs/2512.05470)(arxiv, December 2025). A file-system abstraction for context engineering, built on the Unix idea that everything is a file.[Files Are All You Need](https://www.llamaindex.ai/blog/files-are-all-you-need)(LlamaIndex). Argues files are the core interface for agents managing context and skills, and that filesystems can replace complex orchestration setups.[Why File Systems Are Here to Stay](https://archil.com/post/why-file-systems-are-here-to-stay)(Archil). On the industry rediscovering the file system as an interface for giving AI access to data.[File Systems for Agents](https://www.amplifypartners.com/blog-posts/file-systems-for-agents)(Amplify Partners). Models are trained on enormous quantities of file I/O code, which makes them natively competent with folders, paths and markdown.[AGENTS.md](https://agents.md). The markdown file at the root of a repo that tells agents how to behave, now stewarded by the Agentic AI Foundation under the Linux Foundation.[tick-md](https://purplehorizons.io/blog/tick-md-multi-agent-coordination-markdown). A single markdown file as a multi-agent task coordination system. The closest direct tool parallel, though it is a task runner rather than a writing environment.[In Agentic AI, It's All About the Markdown](https://visualstudiomagazine.com/articles/2026/02/24/in-agentic-ai-its-all-about-the-markdown.aspx)(Visual Studio Magazine, February 2026). Markdown as a version-controlled instruction layer governing agents in mainstream developer tooling.