A folder that keeps itself in order: filing, indexing, and spotting near-duplicates

Every folder that receives files ends the same way. It starts as a sensible place to put things, and a few months later it is a few hundred files whose names say little about what they are. Nothing went wrong. Files kept arriving, and dealing with each one at the moment it arrived was nobody's job.

Why folders rot

Tidying is real work: open the file, work out what it is, decide where it belongs, move it. It is never urgent, so it loses to whatever is. The usual fixes share a weakness. A cleanup afternoon fixes the folder for a day. A naming convention works for the files you name yourself, and most of the mess comes from files other people named. A rule that matches on filenames handles invoice-march.pdf and has nothing useful to say about scan0032.pdf.

What is missing is not a better convention. It is someone who is there when the file lands, and who opens it.

A folder with standing instructions

Filer is a file explorer with an AI agent you can attach to a folder. You describe once, in plain language, what should happen in that folder — the instructions live in a small text file inside it — and from then on the agent acts when the folder gives it a reason: a file is added or changed, or a scheduled time comes round. It does not need the window in front of you, and it does not need you to ask. How those triggers work is covered in an earlier post.

Two things make this fit upkeep in particular. The agent reads what is in a file, not just what it is called, so a badly named file is not a problem. And the scope is narrow: the agent belongs to one folder, its instructions are about that folder, and it can only write inside that folder's tree — the rule described in the post on folder boundaries. An agent that tidies your downloads has no business rearranging your tax records, and it cannot write there either.

The three pages below each show one upkeep job end to end.

Filing what arrives

The first job is the one people mean by "organize my files": getting each arrival into the right folder. In the walkthrough, a folder already has three destinations — one for finance, one for legal, and a catch-all inbox — and this instruction, quoted in full:

When a new file appears in this folder, read it, decide what kind of document it is, and move it into exactly one of these existing folders:

- An invoice, receipt, or bill  ->  `Finance/2026/`
- A contract or legal agreement ->  `Legal/`
- Anything else, or anything you are not sure about -> `_Inbox/`

Use only the three folder paths listed above. Do not create new folders.
Move the file. Do not copy it, and do not rewrite its contents.
Move each file exactly once, then stop.

Three documents arrive: an invoice, a services agreement, and a set of meeting notes that is neither. The agent opens each one, says what it is, and moves it. The meeting notes go to the inbox rather than being forced into a category. The files are moved, not copied, and nothing is renamed.

Two details matter more than the rest. The agent files into folders you already keep and does not invent new ones, so the structure stays yours. And the catch-all is what makes a wrong call recoverable: an agent that decides can decide wrongly, and an uncertain document should wait for you in one known place.

See the auto-sort usecase: a folder that files its own arrivals

An index that matches the folder

Filing answers "where does this go." The second job answers "what is in here." A hand-written index is a good idea for about a week; then it is one file behind, and soon after nobody trusts it.

In the walkthrough, the folder's instruction tells the agent to look at the folder's current contents whenever a file shows up and write a short description of each file into INDEX.md, overwriting it each time rather than appending. A new note is added, and the index is rewritten to cover every file that is actually there. Because it is rebuilt from the folder rather than edited by hand, it describes the folder as it is now, not as it was when someone last remembered to update it.

See the folder-index usecase: an index that never goes stale

Near-duplicates: found, not deleted

The third job is the one where caution matters most. In the walkthrough, a folder holds two planning memos that say the same thing in different words, and one unrelated file. The agent reads the files together, compares their content, and reports that the two memos are near-duplicates — pointing at the phrases that were reworded — while leaving the unrelated file out of it. It creates nothing, changes nothing and deletes nothing.

That is deliberate. The copies that pile up are rarely identical files; they are the reworded draft and the report exported twice, and spotting those takes reading. Deciding which one to keep takes knowing which one you sent. The agent does the first part and hands you the second. The same comparison is also available without a standing agent — as a right-click action on selected files or a whole folder, or by asking in the folder's chat.

See the duplicate-file-cleanup usecase: find the near-duplicates before you do

Where to start

You do not need all three. Pick the folder that bothers you most:

• Things arrive here and should leave — a downloads folder, a place where attachments get saved. Filing is the job.
• Things accumulate here and stay — a project archive, a shared drop folder. An index is the job.
• Drafts and exports pile up here — a near-duplicate report is the job.

The index and the duplicate report are the gentle ones: one writes a single file, the other writes nothing. Filing moves files, so the folder needs a trust level that lets the agent move them — that level is chosen per folder. Each of the three pages also notes that the same instruction can run on a schedule instead of on each arrival: a sweep once a day or once a week for a folder that changes too often to react to every file.

What stays on your machine

The files stay on your disk. Filer runs on your PC, the agent works on the folder on your disk, and organizing a folder does not involve uploading it anywhere. What does travel depends on the model you chose, because reading a file means showing its text to a model. With a local model that happens on your machine, and nothing about the content goes out over the network. With your own cloud API key, or your company's LLM serving infrastructure, the text the agent reads goes to that endpoint — the one you picked. The post on searching your own documents sets out the three options in more detail.

What it does not do

• It does not design your folder tree while filing. The filing agent uses the destinations you name.
• The walkthroughs are small and textual. Each uses a handful of text documents. They do not show scanned pages or dozens of files arriving at once.
• It can be wrong. Keep the catch-all folder, and leave deleting to yourself — the duplicate report is read-only for that reason.
• Quality follows the model. A stronger model gives more reliable results than a small one.

What it needs

• A Windows PC with Filer installed and a model source configured (local, your own API key, or a company server)
• A folder with an agent added to it and a few lines of instruction — for filing, with the destination folders already made
• For the near-duplicate report: the plugin that reads several files at once, installed from Filer's Connect tab

All usecases · How it works, step by step · More from the blog