Every time a new model or agent framework drops, I feel the urge to burn everything down and rebuild.
New tool, new “agent,” same problem:
my workflows, prompts, and SOPs end up glued to the tool instead of the work.
What finally started working was flipping the mental model:
The folder is the app. The AI is just the worker that knows how to navigate it.
Under the hood I’m using a simple architecture that does two things:
Separates what should be code, what should be rules, and what actually needs AI
Structures everything so any model can plug in later without a rebuild
I think of it as 60 / 30 / 10 on top of a 3‑layer workspace.
Step 1: 60 / 30 / 10 – decide where AI actually belongs
For every task, I force it into one of three buckets:
60% – Automations (no AI at runtime)
Same input → same output every time.
Scripts, API calls, cron jobs, database writes.
AI can help write the script, but the script runs it.
30% – Rule engines (templates / decision trees)
Clear if/then logic, multiple branches, but all map‑able.
Triage, routing, form logic, templated replies.
Once the tree exists, it runs without “thinking.”
10% – Prompts (actual AI work)
Summaries, syntheses, ambiguous inputs, creative drafting, nuanced judgment.
This is the only layer where I want the model to “think.”
If I can’t decide, I decompose the task until each step is clearly one of those three.
That alone kills a ton of “let’s just build an agent” impulses.
Step 2: 3‑layer folder architecture
Once tasks are classified, everything lives in a single workspace:
Layer 1 – The map (router)
One root markdown file, e.g. _router.md or WORKSPACE.md:
Explains the business / project in plain language
Lists folders and what they’re for
Defines naming conventions (this is your “schema”)
Has a routing table:
“If task = X, read these files, skip those, write output here, load these skills.”
When I start a session I don’t paste giant prompts.
I say: “Read _router.md and follow it.”
Layer 2 – Task workspaces by layer
Under the root I split by the 60/30/10 buckets:
automations/
rule-engines/
prompts/
vault/
Each task gets its own folder with a README.md that:
Describes the task
Defines input → output
Documents rules / decision trees or prompt contract
Specifies where to put outputs
Examples:
automations/weekly-metrics/
rule-engines/support-triage/
prompts/meeting-summary/
Same model, totally different behavior depending on which folder it’s “standing in.”
Layer 3 – Actual work + naming rules
Inside each task folder are just files:
Scripts, schedules, templates, system prompts, examples, outputs
All named predictably, e.g.:
2026-03-16_clientA_onboarding_SOP_v1.md
support-triage_decision-tree_v2.md
meeting-summary_system-prompt_v1.1.md
Because naming rules live in Layer 1, the model can find what it needs:
“Find the latest *_system-prompt_v* for meeting-summary and run the test cases.”
No databases, no orchestration framework. Just folders, markdown, and a strict router.
Bonus: I turned this into a “Workspace Architect” project
To avoid doing this by hand every time, I’ve got a Claude project I call MWP Workspace Architect:
You drop in transcripts, SOPs, workflows, tool lists
It:
Extracts all the tasks
Classifies them into 60/30/10
Spits out the folder tree + _router.md + naming conventions
Generates per‑task READMEs in the right format
End result: one workspace any future model can plug into.
When a new model drops, I don’t rebuild. I just point it at the same folders.
Curious who else here is:
Using folder‑as‑app instead of agent frameworks, and
Explicitly separating automations / rule engines / prompts instead of throwing everything at “AI”?
If you’ve got your own flavor of this (or see holes in mine), I’d love to see how you’re structuring it.