Folders, not Frameworks

In June of 2024, the engineering team at Octomind published a post titled "Why we no longer use LangChain for building our AI agents."

"Frameworks are typically designed for enforcing structure based on well-established patterns of usage, something LLM-powered applications don't yet have."

This echoes strongly an opinion that I have about the state of agent building: while building AI solutions is still in this much flux, a constructed abstraction layer doesn't save you time, it costs you time (especially in the long run). Why? Because every requirement has to be translated into the framework's worldview before it can be implemented. "Once we removed it," they wrote, "we no longer had to translate our requirements into LangChain appropriate solutions."

The Hacker News thread piled on. Hundreds of comments from teams describing the same experience: frameworks that were supposed to give them stability instead gave them a treadmill. Six months in, they were rewriting. A model update changed how tool-calling worked, they were rewriting again.

The pattern in those threads is consistent enough to be a tell: teams reach for a framework (LangChain, CrewAI, Semantic Kernel, AutoGen) to wire their AI work together, and six months later they're somewhere between mid-rewrite and post-rewrite. The framework was supposed to give them stability. It gave them a layer that needed maintaining as the AI ground shifted.

This series is going to argue that the frameworks are operating at the wrong abstraction layer for most of the work non-developers actually need AI to do. There's a simpler, more durable thing that handles the work most teams want to do, and we've been using it for 50 years. Folders.

Note: This series assumes you've already decided to build a workflow. If you're earlier than that (still asking whether to invest engineering effort in an AI workflow at all), there's a separate three-layer test for that question. See Should you build that AI workflow? for the framing there.

The wrong abstraction layer

A framework is appropriate when the patterns it's enforcing are stable enough to enforce. The whole point of an abstraction is to take a pattern that's been settled and let everyone benefit from the consensus. SQL is a great abstraction because databases are stable. Web frameworks are good abstractions because HTTP request-response cycles haven't fundamentally changed since the late 1990s. AI agent patterns are not in that state.

The shape of what an agent is changes every few months. Tool-calling protocols change. Model capabilities expand. The thing you wrote six months ago to coordinate three model calls and a vector database is being subsumed today by a single foundation model that handles the whole task as one prompt. The framework you built around the old shape is now an obstacle. You're not getting leverage from it; you're paying maintenance on it.

ICM, or Interpretable Context Methodology, created by Jake Van Clief and documented across his GitHub repo, 2026 paper, and YouTube channel claims that orchestrating AI agents is a file organization problem, not a code problem. You don't need a framework to coordinate a multi-step workflow. You need a folder of plain-English markdown files, organized in a way an agent can read.

To make AI agent work well you need three things:

The right instructions
The right tools
The right data.

Frameworks solve this with code: chains, agents, tool routers, callback hooks. ICM solves it with folders and files.

A folder structure says "here are the steps."
A markdown file says "here's what this step does."
An agent reads the folder, follows the structure, runs the work.

There's no framework code in the middle. When the next model from Anthropic, OpenAI, or Google ships, your folder still works, because the folder is just text, and any model that can read text can run it. Folders don't break when models update. Markdown doesn't go stale when an SDK changes its tool-calling format. The structure of your work (what the steps are, what each step does, what each step produces) survives provider churn, framework deprecations, and the half-life of every clever wrapper library. The thing you write today is the thing your agent reads in three years, even if every other piece of the stack has been replaced.

The reason this hasn't been the obvious answer all along is that, until recently, it didn't quite work. You needed an agent harness that could read a folder, follow markdown instructions, execute multi-step work, and pause for human review at the right points, without a developer in the loop.

What prevented a lot of the above paragraph from completing successfully was the phase "execute multi-step work". As agent harnesses like OpenAI's Codex and Anthropic's Claude Code and now Cowork came online and gained widespread adoption in late 2025 (see Matt Shumer's article Something big is happening) the execution surface that runs the folder is finally consumer-ready. Which means the folder is finally a serious answer.

The 60/30/10 rule

Van Clief says in his videos: production AI systems break down roughly into 60% traditional code, 30% rule-based logic, and 10% actual AI model calls.

The 60% is the unglamorous part: File handling, network requests, database queries, authentication, logging, etc. None of this is AI. It's just the shape of any production system, and the rules of good engineering for it haven't changed because models got smarter. You write it once and it keeps working.

The 30% is rule-based orchestration. Routing decisions ("if the user asked about pricing, send them to the sales workflow"), security checks ("verify this request came from a known source before doing anything irreversible"), session management and workflow state. None of this needs to be done by an AI either. A case statement is faster, cheaper, and more reliable than asking a model to make the same routing decision a thousand times a day.

The 10% (the actual AI calls) is the generative, interpretive, judgment-shaped work: writing a draft, summarizing a meeting, extracting structured information from messy text, or producing a recommendation. This is where the model earns its keep, where you genuinely need a model and not a script.

The implication of the rule is that the value in production AI systems lives almost entirely in the 90% around the model calls: the structure, the routing, the interface between the model's output and the rest of your system. That's where the durable work lives. The 10% (the actual prompt) is the cheapest thing to redo when models change. The 90% is what you've actually built.

This matters for ICM because ICM is the 90%. It's the file structure, the routing tables, the contracts between stages. The model calls are the leaves of the tree, and they're meant to be replaceable. The tree is what's durable.

If files are the answer, the obvious next question is how an AI agent actually knows what to do with a folder of markdown. That's Part 2: the layered context model that makes file-based orchestration work without overwhelming the agent or the reader.

Three takeaways

Frameworks are operating at the wrong abstraction layer for most agent work. The complaint is about being locked behind opinionated abstractions while the underlying patterns are still in flux, not about code quality. The Octomind post and the Hacker News thread it sparked make that case from teams who shipped in production and then ripped the framework back out.
The 60/30/10 rule. The value in production AI systems lives in the structure around the model calls, not the calls themselves. Don't invest in the wrong third, and don't mistake the 10% for the work.
Folders are the durable layer. A folder of markdown survives model updates, framework deprecations, and SDK churn. Anything you build in a framework is one breaking change away from a rewrite; anything you build in plain text still reads cleanly in three years.

Sources

Octomind: Why we no longer use LangChain, June 13, 2024. The canonical "we ripped it out" post; argues frameworks are wrong when patterns are still in flux. (Note: Octomind has since rebranded to OctoClaw, which mirrors the post at octoclaw.ai; the original octomind.dev URL remains live.)
Hacker News discussion: community pile-on, lots of teams describing the same experience.
The 60/30/10 rule originates in ICM's source material; full attribution on the About page.