Proof over promises.

When I established Onlineworkflow, I faced the same problem my clients face: every AI task, from drafting marketing copy to debugging infrastructure, was being routed to the most expensive option by default. The result was predictable, token costs climbing with no correlation to task complexity. A 200-word email rewrite was consuming the same budget as a multi-step architecture decision.

I implemented a task routing strategy that matched each subtask to the least capable AI tool that could handle it reliably. Simple formatting, file edits, and boilerplate generation went to lightweight, low-cost options. Complex reasoning, code architecture, and content strategy stayed on the primary tool. The routing rules were tuned over a week of real usage, with a human reviewing outputs before they shipped. Nothing left the door unchecked.

The impact was immediate. Token spend dropped significantly without any loss in output quality, because the expensive tools were only being asked to do what they do best: think hard about hard problems. Everything else, the mechanical 80% of the work, got pushed downstream to cheaper alternatives. This is the core principle I bring to every client engagement: you don't need the most expensive AI tool for every task, you need the right one.

1. The Problem

Agent memory has tight caps (2,200 / 1,375 chars). When they fill up, the agent loses context. New facts push out old ones, duplicates waste space, and stale entries misdirect. Most users don't notice until the agent forgets things mid-session. In this case, the stores hadn't broken yet, but they were close enough that the next session could tip them over.

I set up a script that triggers an audit once either file reaches 90% full, but I realized a better system needed to be implemented beyond just regular pruning.

I had previously implemented two .md files that help keep my agents sharp and make sure no context is lost when starting a new session or switching models. I applied that same logic here, having the user and memory files point to formatted markdown files for additional context, and in doing so freed up headroom.

2. The Audit

I had my agent cross-reference both stores line by line, where it found:

• Duplicates (environment facts in both USER.md and MEMORY.md)
• A stale model name from a provider switch
• A Portainer config living in the user profile instead of memory
• A vague ICP consuming real estate better spent on session-critical facts
• A gap: the user profile was missing details around the services I provide and my ICP

3. The Back-and-Forth

This is where most audits stop. You run a query or a skill and just implement what it suggests. When people copy skills from others, most will do just that. They shouldn't. Pushback is always necessary, even when what the LLM suggests is technically right. In my instance, three pushbacks changed the outcome.

"Can you confirm if offloading these will result in the same quality for recall across sessions?"

This forced a distinction between session-critical facts (must stay in memory) and reference material (safe to offload). The PENDING list, whose purpose is to scan active items waiting to be dealt with, or items that have stalled, stayed inline because it serves a different purpose than the Kanban, which gives both me and my agent a high level understanding of everything in play. This includes items that are outstanding, blocked, complete, or archived, in addition to sub-tasks, priorities, completion dates, and historical context.

"Confirm if we can revert any of these in the future"

This surfaced that the pointer pattern is a valve, not a commitment. Given that I'm modifying a critical aspect of Hermes, I wanted to make sure these changes could be easily reverted if necessary. When my newsletter frequency intensifies, the relevant details go back into memory in 30 seconds.

"Based on the work in my Obsidian, what would you say my job title is?"

If you're using agents within your business, it's always good to test how well they understand what you're doing overall. Never assume that because it's obvious to you, it's obvious to who you're working with. This goes for robot and human alike. Based on the nature of my work, which touches on several operational aspects, a simple title doesn't do it justice. This led to a positioning exercise that turned into 03.Brand/01.Positioning-and-ICP.md, which then absorbed the bloated ICP details from memory. One question cascaded into the biggest space savings of the entire audit.

4. The Pattern

Instead of cramming everything into capped files, I applied a pointer architecture: compact memory entries with explicit paths to detailed .md files within my Obsidian vault. As mentioned above, I had already proven this architecture with MISTAKE_LEDGER.md and SESSION_HANDOFF.md. This way the agent doesn't need to scan my entire vault and burn tokens unnecessarily. Instead, this architecture points the agent to the exact relevant file to get the full information it needs on demand.

5. The Results

Taking time to set this all up pays dividends in a short period of time. Given how small the character count is for both of these critical files, they can easily fill up and throw off long sessions with your agent. This shows up as context drift and hallucinations. The setup above is designed to hedge against that so you don't experience any quality drop. By implementing this, my MEMORY.md dropped from 88.9% to 71.8%. And USER.md tightened to 88.2% plus it included relevant ICP details. After these changes were implemented, three new .md files were created within Obsidian that the USER and MEMORY files can now offload and reference. The real win in the end is the repeatable method.

The audit found waste. The pushback found the pattern. The first pass is always wrong in some direction. The job isn't to get it right, it's to ask the question that exposes which direction.

Metrics

Before	After
MEMORY.md: 88.9% of cap	MEMORY.md: 71.8% of cap
USER.md: 91.5% of cap, no professional identity	USER.md: 88.2% of cap, identity added
2 stores, 0 vault refs	2 stores, 3 vault ref docs
320 chars total headroom	742 chars total headroom

Pushback Questions (reusable)

When the agent suggests...	Ask...
Offloading memory to a file	"Will recall quality degrade if this isn't auto-injected every session?"
A structural change	"Can I revert this if circumstances change?"
That something is "done"	"What's missing that I haven't thought to ask about?"
A tidy summary	"Is there a distinction here that matters but got flattened out?"

1. The Problem

Memory and agents have a fraught relationship. You'll be deep in a session and at some point you'll likely experience it forgetting something you mentioned not that long ago, or hallucinating answers that it presents to you confidently. It's a common enough problem that people associate AI agents with this kind of frustrating limitation without understanding why. However depending on your set up, it more or less comes down to two technical reasons why your experience degrades like this.

The Technical Reasons You're Likely Experiencing A Degraded Agent Experience 🤓

1. All models have a context window that is measured in tokens. When it hits the end of this window, a new session needs to be started. Without handoff instructions, that new session will not remember anything you previously discussed. This is why you've had to repeat yourself without knowing why.

2. Most high end models now have a 1M token context window. That sounds like a lot, but it really depends on what you're doing. You can easily be burning through tens of thousands of tokens in a single query if your set up is not optimized. In addition to this, every model has a token consumption sweet spot. After it passes this threshold, hallucinations increase. There's no concrete number as to where this fall off begins, but the general consensus is that once you pass the 70% mark of your window you should consider starting a new one. Ergo, your 1M token context window is really 700k.

Here's How I Get Around These Issues & How You Can Too

1. Hermes is my main AI Agent. What sets it apart from others is that it has a small memory file that stores any instructions you give it, in addition to any preferences it notices you have naturally made within a session. This mostly solves the handoff issue, so when you do start a new session, it passes that information to the model, and you can continue on without noticing any major memory or context lapses. While immensely helpful, the optimal set up still requires an INDEX.md for an agent to work with so it can find and retrieve things efficiently.

An agent and a database is really all you need 99% of the time.
Aron Korenblit

2. My main AI environment/database is an Obsidian vault. This is where I write, store and organize relevant information related to my work and business. It's endlessly customizable and you can connect an AI agent to it. In addition to its customization, I chose Obsidian because it's fully local, and doesn't need a subscription to run.

This is how I use Hermes and Obsidian to keep my token consumption down, responses fast and sessions from drifting & hallucinating.

The Setup & How To Solve For Its Blind Spots

At the root of my Obsidian vault is an INDEX.md file. This simple text file acts as a directory map that tells the agent what every folder contains. As the vault/database grows so does the sheer amount of tokens spent for every search you make. The more tokens you spend, the higher your bill. That's a hefty price to unnecessarily pay just to simply look for a file in your database. The INDEX.md approach prevents that from happening by forcing it to read the INDEX.md directory first.

Solving for one problem in this space usually surfaces another.

When we integrate AI aspects into our workflows it's easy to forget what manual aspects we might be overlooking, creating blindspots in the process. While my set up was now properly optimized to account for the token and search problem, the new issue was that the INDEX.md was drifting out of sync as the vault/data grew.

Now that I had a better understanding of the gap between expectation and reality, here's how I solved to close the gap and make it run as intended.

2. The Audit Implementation

Before I consider adding an agent into the mix, I remind myself of the mantra:

Don't get an agent to do something a script can do for free.

The goal is to only give the Agent tasks that it can uniquely handle, and offset anything else to a script that doesn't cost any tokens. The agent can trigger the script, but the script can do a job independently. This isn't just a cost related measure, but a context window one as well. Every request made to the agent chips away at that window, so effectively finding a way to offset it is good practice.

Here's what this looked like in this instance:

I made a script to set up a cron job where every few hours it scans the vault folder structure, compares it against what INDEX.md claims, and patches any discrepancies. If a subfolder exists on disk but isn't in the index, it gets added. If a folder name in the index has a typo (proven by comparing against the actual directory name), it gets corrected. If a file sits loose in a folder root where it doesn't belong, the audit flags it.

The job isn't complicated. It walks directories, reads the existing index, diffs the two, and writes patches. To clarify, the script does the initial comparison work, then hands it off to the agent who runs it, because at this stage it can make judgment calls a regex can't. "Is this a new folder or just a temp directory?" "Does this file belong here or is it misplaced?" A script would need rules for every edge case. The agent just needs the instruction and specific permissions. Two aspects working in tandem.

3. The Back-and-Forth

Here are 3 examples of what this looks like in action.

Run 1: The invisible subfolder

The audit found a subfolder in my main articles folder that wasn't reflected in the INDEX.md. Inside were two drafted posts, but I forgot I had placed them there. The agent had no idea they existed either. The folder wasn't new, it just wasn't reflected in the INDEX. The audit made the content discoverable.

Run 2: The typo that broke the path

This one is something that can easily be overlooked because it's not as obvious. I'm going to get into the weeds on this one, so bear with me.

The audit noticed that INDEX.md referenced 06. Social Posts/ (with two spaces after the period and before "Social") but the actual folder on disk was 06.Social Posts/ (one space). This is the kind of drift that causes silent failures. The agent reads the index, constructs a path, tries to open a file, and gets nothing. Then it tries a search and runs up the token count. All because of one extra space. The audit caught it because it compared the index text against what ls actually returned.

Run 3: The brand-new folder and the loose draft

This was the richest run, as it picked up on two things that had slipped through the cracks.

A new 06.Documentation/ subfolder had appeared under 04.Research/ with two articles I'd saved. This was fresh research material the agent couldn't see, and therefore couldn't reference. Then the same audit pass found a file sitting loose in the case studies root. It wasn't in any subfolder. It wasn't tracked in my dashboard, nor my production Kanban. I had created it, saved it, and completely forgotten about it, but the audit surfaced it anyway.

Three runs. Three different failure modes: undocumented content, a corrupted path reference, and orphaned work. None of them would have surfaced without the scheduled check.

4. The Pattern

The INDEX audit is an instance of a broader pattern: scheduled integrity checking for shared human-agent artifacts.

INDEX.md is a living document that both myself and the agent rely on. I add folders. The agent navigates by the index. Both of us can edit it, but neither of us reliably maintains it.

The audit closes that gap by making verification automatic and periodic, not manual and forgotten.

This pattern applies beyond vault indexes. Any document that serves as a shared map between a person and an agent can, and will drift, because you're only human and keeping up on every small change as it grows is unrealistic. Account for the blindspot and offset the pressure by setting up a scheduled job that compares what the map says against what the filesystem actually contains, and reports the difference.

The pushback questions matter here too. Not every discrepancy means the index is wrong. When the audit suggested adding the 06. Social Posts/ folder, the right question was: "Was this intentionally excluded, or just never documented?" When the typo surfaced, the question was: "Which is the correct name, the folder or the index?" The audit proposes changes. The human (or the agent, with context) decides which direction to correct. This is why having a "human in the loop" will always be critical IMO. These kinds of nuances need peer review.

5. The Results

After that one-week window, INDEX.md was accurate across all 7 top-level folders and every subfolder. The agent never hit a dead path reference. The social posts folder became visible. The documentation subfolder entered the navigation map. The loose case study draft got tracked.

The system now self-corrects and notifies me of the changes should I need to review at the end of every day. I can add folders, rename things, create drafts in the wrong place, and the index stays in sync.

6. Parting Thoughts

Any set up, agentic or otherwise is going to need tweaking as it grows to meet your workflow demands. Keep track of where either you or your agent forgot something, or you assumed something would work but didn't.

Send me a weekly report that surfaces anything that didn't work, or led to additional issues in my database. Rank each issue by severity and offer suggestions on how to fix them. Don't do anything until I give approval.

Addressing them this way helps plug any unwanted holes and makes your workspace more robust in the process.

Here are some additional questions to consider to patch issues and surface the Agent's thinking:

Pushback Questions (reusable)

When the audit suggests...	Ask...
Adding a folder to the index	"Was this intentionally excluded, or just never documented?"
Fixing a path mismatch	"Which side is correct, the index or the folder name?"
Flagging a loose file	"Does it belong in an existing folder, or does it need a new home?"
That everything is clean	"What did the audit NOT check that might have drifted?"