The Tool-Agnostic Directory: Why Your AI Project Folder Should Outlive Any Single Tool
OpenClaw, Hermes, Codeex, and Claude Code can all run on the same folder. Here's why building tool-agnostic directories is the key principle.
Four Different AI Agents, One Project Folder
OpenClaw, Hermes, Codeex, and Claude Code have all run inside the same directory — a folder called herk2 — without any of them caring which of the others was there first. That’s not a coincidence or a lucky compatibility quirk. It’s the organizing principle that Nate Herk, an AI builder with a YouTube channel documenting his production stack, says should govern how you think about AI tooling in 2025.
The tool-agnostic directory principle is simple: your project folder — with its CLAUDE.md file, your agent scripts, your skills, your knowledge base — should be built to outlive any single tool. OpenClaw, Hermes, Codeex, and Claude Code can all operate on that same herk2 directory because they’re all just harnesses. Different surfaces, different model backends, different UX — but underneath, they’re all AI working inside a directory.
If you’ve been treating your Claude Code setup as a Claude Code setup rather than as a project directory that Claude Code happens to be running inside, you’ve been building with the wrong mental model.
Why This Isn’t Obvious
The default framing for most AI builders is tool-first. You pick Claude Code, or you pick Cursor, or you pick Codeex, and then you build your workflow around that tool. The tool becomes the unit of organization. Your prompts live in that tool’s format. Your memory files are structured for that tool’s conventions. Your automation scripts assume that tool’s runtime.
Seven tools to build an app. Or just Remy.
Editor, preview, AI agents, deploy — all in one tab. Nothing to install.
This feels natural because tools have good onboarding. They want you to build inside them. And for a while, it works fine.
The problem surfaces when the tool changes — or when a better one appears. If your workflow is organized around Claude Code specifically, switching to Codeex isn’t just a matter of opening a different app. You’ve got context scattered across Claude Code’s memory system, scripts that assume its CLI interface, habits built around its specific commands. The switching cost is high enough that you probably won’t switch even when you should.
Herk describes this as the 20% productivity dip problem. Every tool switch comes with a dip — you lose efficiency during the transition. The question isn’t whether the dip happens; it’s whether the ceiling on the other side is higher than your current trajectory. If your workflow is deeply coupled to one tool, the dip gets steeper and the ceiling question gets harder to answer honestly.
The directory-first approach inverts this. Your project is the unit of organization. The tool is just what’s currently running against it.
What the herk2 Directory Actually Looks Like
Herk’s main operating project is called herk2. It contains a CLAUDE.md file — the memory and instruction layer that Claude Code reads on startup — along with agent scripts, skills, and whatever knowledge base he’s built up over time. This is his “main operating system,” as he calls it.
Here’s what makes it tool-agnostic: every agent harness he uses can point at that same directory. When he was using OpenClaw, it ran against herk2. When he switched to Hermes Agent — a Telegram-based agent with instant cron scheduling and on-demand wake — Hermes ran against the same directory. Codeex, which he’s been using more heavily because its strengths complement Claude Code’s weaknesses, also runs against herk2. Claude Code itself, his current S-tier daily driver, runs there too.
None of these tools required him to restructure his project when he adopted them. The directory was already there. The context was already there. The switching cost dropped to near zero.
This is the concrete version of what “tool-agnostic” means. It’s not a philosophy about staying flexible or not getting attached to tools. It’s a specific architectural decision: keep your project structure clean, keep your memory files in standard formats, and don’t let any single tool’s conventions bleed into your core project organization.
For builders thinking about how to structure multi-agent workflows, this connects directly to how Claude Code handles parallel workstreams with Git worktrees — the same directory-first thinking applies when you’re running multiple agents on separate branches simultaneously.
The Jeff Bezos Framing
Herk applies a specific mental model here that he attributes to Jeff Bezos: think about what will never change, not what will change. In the context of AI tooling, the question becomes: what is stable enough to build on?
One coffee. One working app.
You bring the idea. Remy manages the project.
The answer isn’t Claude Code. It might not be king in six months. It isn’t Codeex. It isn’t Hermes. The answer is the directory — the project structure, the memory files, the accumulated context and skills that represent your actual work. Those are stable. The harnesses that run against them are not.
This reframes the entire question of which tool to use. The right question isn’t “which AI coding agent is best?” The right question is “for this specific task in this specific context, which tool is best?” And because your project lives in a tool-agnostic directory, you can actually answer that question honestly each time without the switching cost distorting your judgment.
Herk gives a concrete example: making a YouTube video. Perplexity for research. Claude Code with a skill for structuring the video. Claude Chat for writing the script. GPT Image 2 for the thumbnail. Nano Banana 2 for post-processing — adding glow effects, making elements stand out. DaVinci Resolve for the final edit. Not every step uses AI. Not every step uses the same AI. Each tool is chosen for the specific output that step requires.
The directory principle is what makes this kind of fluid, multi-tool workflow possible. If your project lived inside any one of those tools, the others would feel like interruptions.
The Graduated Tools Problem
Herk maintains a “graduated” category for tools he no longer uses: ChatGPT chat, OpenClaw, Cursor, NotebookLM, Whisper Flow, Poppy AI. He’s explicit that graduated doesn’t mean bad. It means he’s moved past them, usually because he’s extracted the functionality he needed and built it into his own ecosystem.
NotebookLM is a good example. It’s a capable tool. But Herk realized he could replicate the features he actually used — structured knowledge querying, document synthesis — inside Claude Code, with more customization and lower cost. So he built that into herk2 and stopped paying for NotebookLM.
Poppy AI went the same way. The functionality was real, but it was also available through Claude Code if you were willing to build it yourself. For someone who’s already living inside a well-structured project directory, the case for a separate tool that does a subset of what your main setup can do gets weaker over time.
OpenClaw is the most interesting graduation. Herk says Hermes Agent has effectively replaced it — citing Hermes’s on-demand Telegram wake, instant cron scheduling, and easier setup as the deciding factors. If you want the full comparison, the OpenClaw vs. Hermes breakdown covers the framework-level differences in detail. The key point here is that the graduation was painless precisely because neither OpenClaw nor Hermes owned Herk’s project structure. herk2 stayed intact. He just pointed a different harness at it.
Whisper Flow’s graduation is simpler: Glido replaced it. Glido is a speech-to-text startup that Herk describes as the fastest on the market, with Windows support imminent. It’s now S-tier in his daily stack alongside Claude Code and VS Code. The replacement happened cleanly because Glido doesn’t need to integrate with his project directory — it’s an input layer, not a project layer.
The Decision Framework, Applied
Coding agents automate the 5%. Remy runs the 95%.
The bottleneck was never typing the code. It was knowing what to build.
The directory principle doesn’t mean you should adopt every new tool that can point at your project folder. Herk uses a specific decision framework that filters most new tools out before they ever get tested.
When a new tool or feature appears: does it solve a current pain point? If no, save the link. Don’t test it, don’t spend a week learning it, don’t let it interrupt your current trajectory. If yes, test it in a real scenario — not mock data, not a toy project — for one week. At the end of the week, ask whether it solved the pain point well enough to earn a permanent place in your stack. If not, discard it.
The “real scenario” requirement is important. Testing a tool on mock data tells you almost nothing about whether it fits your actual workflow. Testing it on something that genuinely moves the needle for you — while keeping the stakes low enough that a failure isn’t catastrophic — gives you real signal.
This framework is what keeps Herk’s core stack lean. His S-tier is three tools: Claude Code, VS Code (as the IDE for Claude Code), and Glido. His A-tier is six: Codeex, Claude Chat, Hermes Agent, Perplexity, and Grok. That’s it for daily and weekly drivers. Everything else is either a specialist called in for specific tasks — Apify for web scraping actors, GPT Image 2 for creator images, Fal.ai as an API router for image and video models (his description: “open router but for image and video”), HeyGen for avatars, ElevenLabs for voice cloning and voice agents, Open Router for model routing, Claude Design for team design systems and landing pages — or it’s in the experimenting tier, which currently holds Gemini, Ollama, and Manus.
For builders who want to keep Claude Code agents running continuously against a stable project directory, keeping your Claude Code agent running 24/7 covers the infrastructure side of that problem.
What This Means for How You Build
The directory-first principle has a few concrete implications that are worth spelling out.
First, your CLAUDE.md file — or whatever memory file your primary agent reads — is more important than which agent reads it. Invest in making it accurate, well-structured, and comprehensive. That file is the accumulated intelligence of your project. It should be written to be readable by any agent harness, not optimized for one tool’s specific parsing behavior.
Second, keep your scripts and skills in standard formats. If your automation scripts are tightly coupled to Claude Code’s CLI conventions, they won’t run cleanly under Codeex or Hermes without modification. Write them to be portable. Shell scripts, Python scripts, standard APIs — these survive tool transitions. Proprietary plugin formats don’t.
Third, think about your project directory as the thing you’re actually building, not the tool you’re building it in. The tool is the current best harness for the job. The directory is the job itself. When you frame it that way, the question of which tool to use becomes much less fraught. You’re not committing to a platform. You’re choosing a harness for today.
Remy doesn't write the code. It manages the agents who do.
Remy runs the project. The specialists do the work. You work with the PM, not the implementers.
This is also where the abstraction layer question gets interesting. Remy, MindStudio’s spec-driven app compiler, takes a similar source-of-truth approach: you write an annotated markdown spec, and the full-stack application — TypeScript backend, SQLite database, auth, deployment — gets compiled from it. The spec outlives any particular generated output, the same way a well-structured project directory outlives any particular agent harness.
For teams building multi-agent systems where multiple agents need to collaborate on the same codebase, running a multi-agent engineering team with heartbeat scheduling shows how this directory-sharing pattern scales up to CEO, engineer, and QA agent roles operating on the same project.
The Northstar Question
There’s one more piece of Herk’s framework that the directory principle depends on: knowing what you’re actually trying to build.
He calls this the northstar question. His northstar for YouTube is to test tools, form opinions, and share what’s interesting. That northstar requires him to experiment broadly, jump on announcements, and maintain a wide stack. It’s why his experimenting tier exists and why he keeps Manus and Ollama around even though he rarely uses them.
Your northstar is probably different. If you’re building a specific product or running a specific business, most new AI tools are distractions from the path to that goal. The right response to a new tool announcement is usually to save the link, not to spend a week learning it. You reach for the saved link only when you hit a specific roadblock that the tool might solve.
Platforms like MindStudio handle a version of this problem at the infrastructure level — 200+ models, 1,000+ integrations, and a visual builder for chaining agents and workflows — so you don’t have to maintain separate API connections for every model you might want to use. The multi-model orchestration layer becomes someone else’s problem, and you stay focused on the actual work.
The directory principle and the northstar question are two sides of the same coin. The directory gives you the technical flexibility to switch tools without rebuilding your project. The northstar gives you the judgment to know when switching is actually worth it. Together, they’re the answer to the overwhelm that comes from living in a space where something new and apparently essential drops every week.
Most of it isn’t essential. Your directory is. Build accordingly.
