---
title: I Made My Hermes Agent 10x Faster Without Changing the Model
summary: >-
  An agent doesn't navigate folders the way you do. This flow shows how a single
  INDEX.md map at the root of each major folder, one-concern-per-folder, and
  numbered names cut slow vault searches from two minutes to under thirty
  seconds — no model change required.
author: wandermist
authorUrl: 'https://x.com/wandermist'
category: Memory & Context
difficulty: Intermediate
readingTime: 5
date: '2026-06-30'
tags:
  - context
  - obsidian
  - file-structure
  - vault
  - productivity
integrations:
  - Obsidian
  - Hermes Agent
---

## The core idea

There's a gap between what an AI *can* do and what your *setup* lets it do — and that gap is usually where your productivity dies. The same agent that can reason across an entire genetic family of a virus will happily spend two minutes opening the wrong files in your vault just to surface a brief from three months ago.

The culprit is rarely the model. It's the invisible scaffolding around the agent:

> Folder structure is a cage you build that constrains how your agent *moves* without constraining what your agent can *do*.

This flow is an autopsy of a real Obsidian vault that grew messy by accident, folder by folder, until the agent lost its way. The fix is almost embarrassingly small: one index file and a few numbers in front of folder names. But it's the difference between an agent that wanders and an agent that works.

## The structure your agent can't see

Most people organize a vault by **content type**: articles, research, assets, strategy docs, each in their own folder. That feels clean because humans think in categories — your brain does the cross-referencing automatically and you never think about where to look.

An agent doesn't think in categories. When you ask Hermes to plan a product launch, the task pulls from strategy notes, brand guidelines, and previous launches — context scattered across different content-type folders. The agent has to search everywhere, every time, with no idea which draft is current versus archived, or which note is from this month versus six months ago.

> The structure around your agent does more work than the agent's own capability.

You built the vault for a human brain that remembers where things live, then handed it to a searcher that starts from scratch on every task. A searcher needs a map — without one, it treats every file like it might be the answer.

## Diagnose before you reorganize

Don't touch a single folder until you've measured. Run this five-minute test on the three tasks your agent handles most often:

1. **Time each task** end to end.
2. **Count how many files** it opens before finding the right one.
3. **Note how often** it picks the wrong file or stops to ask you which one to use.

Any task that takes more than thirty seconds, or opens three or more wrong files, points to a broken folder behind it. Here's what five common tasks looked like in the original content-type vault:

| Task | Files opened | Time |
| --- | ---: | ---: |
| Find the current article brief | 7 | 2:00 |
| Find brand color definitions | 5 | 1:12 |
| Look up the article queue for planning | 4 | 0:48 |
| Find previous articles on the same topic | 6 | 1:36 |
| Pull promotion strategy for a launch | 3 | 0:34 |

*(Rough experiment — treat the exact numbers as directional.)* Every task crossed multiple folders, and most opened archived versions before finding the active ones. The agent was burning its capability on **navigation** instead of the actual work.

## The fix: the smallest cage that works

One folder per concern, numbered for order, with an `INDEX.md` at the root that maps everything. That's the whole fix, and it lives in three rules that work together.

### Rule 1 — INDEX.md as a map (and a soft approval gate)

Put an `INDEX.md` at the root of each major folder. It lists every subfolder and canonical file, plus where the agent should start. The agent reads this **first** and knows what's inside before touching anything else — think of it as a soft gate where the agent isn't allowed to start work until it knows what it's working with.

```markdown
# Brand Index

This folder holds the current brand system.

## Folder Map

| Folder | Purpose | Updated |
|---|---|---:|
| `01.Brand System/`      | Visual identity, topic scope, voice | 2026-06-11 |
| `02.Editorial Strategy/`| Article direction, title rules, queue | 2026-06-11 |
| `03.Promotion/`         | Launch, distribution, tool strategy | 2026-06-11 |

## Canonical Files

| File | Purpose |
|---|---|
| `01.Brand System/01. Brand System.md`   | Visual identity, colors, typography |
| `02.Editorial Strategy/01. Articles.md` | Article queue, title rules |

## Where To Go

- Start with `01.Brand System/04. Direction.md` for mission
- Use `02.Editorial Strategy/01. Articles.md` for article selection
```

The `INDEX.md` went through three versions to land here. The first listed *every* file and ran to forty lines — complete, but the length was its own overhead. The second was too short at ~15 lines, and the agent still asked questions. This third version lists only subfolders and canonical files, plus a short "Where To Go" section that names the starting points.

### Rule 2 — One concern per folder

Organize by **concern**, not content type. Each concern gets its own folder, so brand work stays with brand work and strategy stays with strategy. The agent doesn't cross boundaries hunting for something that doesn't belong there.

```text
05.Brand/
├── INDEX.md
├── 01.Brand System/
├── 02.Editorial Strategy/
├── 03.Promotion/
├── 04.Public Deliverables/
├── 05.Operating Plan/
└── 06.Archived/
```

Archived material lives in `06.Archived/`, where old briefs and retired plans wait. The agent knows not to look there unless you specifically ask for historical context — and you note that rule in the `INDEX.md` so it knows where historical material lives. That separation keeps the active folders clean and the searches fast.

### Rule 3 — Number folders and files for reading order

Numbers make reading order explicit instead of relying on alphabetical sorting. `01.Brand System` gets read before `02.Editorial Strategy`; the agent doesn't guess. Numbers inside folders do the same for files, so the agent knows `01. Articles` is the starting point before `02. Previous Articles`. A bonus: leading numbers make the structure easier for *you* to remember too.

## The payoff

After the reorganization, the same five tasks — with no change to the model:

| Task | Files opened | Time |
| --- | ---: | ---: |
| Find the current article brief | 1 | 0:10 |
| Find brand color definitions | 3 | 0:22 |
| Look up the article queue for planning | 1 | 0:10 |
| Find previous articles on the same topic | 2 | 0:18 |
| Pull promotion strategy for a launch | 1 | 0:12 |

The slowest task dropped from **two minutes to twenty-six seconds**, and the fastest runs landed around ten. The agent opens `INDEX.md`, follows the starting point it needs, and gets to work without wandering. No capability changed — the folder structure simply stopped wasting most of it before the task even started.

## Mistakes that cost time

- **INDEX.md in every subfolder.** Too many maps means the agent reads indexes instead of working. Keep `INDEX.md` only at the root of *major* folders with enough subfolders to need a map. A small subfolder of four or five files needs no map at all.
- **Building structure before the agent shows confusion.** Most people over-engineer their setup. Add structure only when the agent gets lost, and only enough to fix that specific problem — the smallest interface that gets the job done.
- **Nesting structure inside structure.** Subfolders inside subfolders turn a two-level hierarchy into a five-level one, forcing the agent to parse multiple INDEX files and numbering sequences for a single file. Collapse extra levels back into flat subfolders. *Depth is the enemy of fast file lookup.*
- **Chasing perfect numbering.** Appending a new folder at the end instead of renumbering everything is fine — numbers only need to be directional. Treating perfect order as the goal turns a practical fix into a cosmetic project.

## Where it still bends

- **Archived content** still gets referenced for context, so the `INDEX.md` must tell the agent where historical material lives — otherwise it assumes archived content doesn't exist.
- **Obsidian Sync** can serve a stale copy: edit a file on your laptop while an older version sits on your VPS, and Hermes may load the VPS copy as the source of truth. That's a sync problem, but it surfaces inside the folder system because the agent only sees the files in front of it.
- **Numbering breaks down past ~10–12 items** at one level, where the sequence becomes arbitrary. Keep top-level categories below that threshold and nest deeper instead.
- **Renaming breaks references.** Any `INDEX.md` pointer to an old folder name breaks until you update it, so set folder names once and leave them alone — a slightly awkward name is cheaper than a broken reference.
- This pattern fits **content-heavy and planning-heavy** workflows best. Pure code or data-heavy setups may need different organization principles entirely.

## Why it matters

Everything here traces back to one instinct: **own the layer that matters.** Build your stack so no company controls your tools; build your vault so no mess controls your agent. Same principle from providers to folders.

Capability is cheap when the scaffolding around it is broken. Build the scaffolding, and the capability takes care of itself. One index file and a few numbers in front of your folder names is the difference between an agent that wanders and an agent that works.