Last week I read arXiv:2603.16021, “Interpretable Context Methodology: Folder Structure as Agentic Architecture” by Jake Van Clief and David McDermott, and had the strange experience of reading a paper that described my own content pipeline back to me — a pipeline I had grown out of necessity without ever naming it. The paper calls it Interpretable Context Methodology (ICM). This post is a summary of what it claims, an honest diff against how this very website is produced by an AI agent, and a checklist of the hardware and operating-system level optimizations I am running on my local model setup to make those runs fast and, more importantly, consistent.

What ICM actually says

The starting observation is refreshingly unglamorous: multi-agent frameworks (CrewAI, LangChain, AutoGen) solve coordination problems through code — context passing, memory, retries, step ordering. For complex, concurrent systems that overhead pays for itself. But for sequential workflows with a human reviewing each step, most of that machinery is scaffolding around a problem that does not exist.

ICM’s answer is to move the orchestration into the filesystem:

• Numbered folders are stages. 01_research/, 02_script/, 03_production/. The numbering encodes execution order; the folder boundaries enforce separation of concerns.
• Markdown files are the prompts. Plain-text contracts tell one agent which role to play at each step. No agent classes, no redeploy — editing a prompt is editing a file.
• Local scripts do the mechanical work. Fetching, moving, formatting, building: none of that needs a language model, so none of it gets one.

Five design principles sit on top of that: one stage one job; plain text as the interface; layered context loading; every output is an edit surface; and my favorite, configure the factory, not the product — you set up preferences, conventions and style once, and every run produces a new deliverable from the same configuration.

The core mechanism is a five-layer context hierarchy. Layer 0 is a global identity file (“where am I?”), Layer 1 routes tasks to stages (“where do I go?”), Layer 2 is the per-stage contract with explicit Inputs/Process/Outputs sections (“what do I do?”). Layers 3 and 4 carry content: reference material (voice guides, style rules — stable across runs, the factory) and working artifacts (this run’s inputs and outputs — the product). Each stage loads only what its contract declares, which keeps per-stage context at roughly 2,000–8,000 tokens instead of the 30,000–50,000 a monolithic prompt accumulates. That is not a micro-optimization: it directly sidesteps the “lost in the middle” degradation Liu et al. documented — models get worse as irrelevant material crowds the window.

Two more ideas stuck with me:

1. Review gates and the U-curve. Every stage output is a file, so the human reviews and edits at each boundary. Practitioner reports show a U-shaped intervention pattern: heavy editing at stage 1 (setting direction), light editing in the middle (execution is constrained by both anchors), heavy editing at the end (alignment work — tracing where the output drifted from earlier decisions).
2. The edit-source principle. Editing an output fixes one run; asking why the output needed that edit and fixing the prompt, contract or reference file fixes every future run. Recurring edits are not taste, they are bug reports against your own sources. In compiler terms: stop patching the binary, fix the compiler.

The authors ground all of this in lineage rather than novelty, and that is exactly why it works: McIlroy’s Unix pipeline principles, Feldman’s Make (files as both artifacts and coordination mechanism), multi-pass compilers with inspectable intermediate representations, Parnas’s modular decomposition, Knuth’s literate programming (the stage contract is simultaneously the instruction set and the documentation). The paper’s summary of what you get for free is observability: nothing was ever hidden, so there is nothing to explain. A glass box that was never a black box.

My pipeline through ICM’s eyes

Here is the interesting part: my website content pipeline — the one that produced every article-level change on this site — is an ICM workspace that grew by accident. The handbook (agent.md) plus ai-project/ maps onto the paper almost line for line:

My setup	ICM equivalent
agent.md handbook (role, folders, rules)	Layer 0 identity + Layer 1 routing
ai-project/skills/*.md (manage-content, build-website, compact-history)	Layer 3 reference material / stage procedures
ai-project/data/ (CV, invoices)	Layer 3 domain inputs
ai-project/todo/NN_*.md, worked in filename order	Numbered stages with task contracts
ai-project/history/ (compacted task + decision logs)	Audit trail / condensed intermediate representations
ai-project/artifacts/*.zip	Stage outputs / deliverables
hugo build	The “local script that needs no AI”
Maintainer reviews and commits, agent never commits	Review gate at the final boundary

Several things I did for purely practical reasons turn out to be load-bearing in the paper’s terms. State management is the filesystem: a task file existing in todo/ means pending, moving it to history/ with a date prefix means done — no database, no status field, exactly Make’s trick. The compaction step in my history skill exists because raw chat logs are enormous; condensed outcomes are what the next session reads. That is precisely the paper’s point that stage outputs should be condensed, structured intermediate representations so the next stage’s Layer 4 stays small. And the skills referencing each other (manage-content → build-website → compact-history) are prompt chaining at the filesystem level — AI Chains with folders instead of function calls.

The local-model angle: making it fast and consistent on real hardware

There is a practical reason I care about ICM’s context scoping beyond output quality: it is what makes running this pipeline on a local model viable at all. My agent runs on a GMKtec EVO-X2 — AMD’s Ryzen AI Max+ 395 (“Strix Halo”): 16 Zen 5 cores / 32 threads, a 40-compute-unit Radeon 8060S iGPU on RDNA 3.5, and up to 128 GB of 8-channel LPDDR5X-8000 shared between CPU and GPU — running Arch Linux with an unsloth Dynamic GGUF (UD-IQ4_XS) of Qwen 3.8 Flash Next served through llama.cpp.

A monolithic 40k-token agent prompt on shared-memory hardware is exactly where you feel every weakness: huge KV cache, slow prefill, thermal ramp, inconsistent time-to-first-token. ICM’s discipline of delivering 2–8k focused tokens per stage keeps decode in the fast zone — and short, scoped stages make it realistic to pin sampling parameters per stage, which is half of “consistent results.”

The checklist that got this box from “flaky demo box” to “boring production tool”:

• Weights resident, not paging. Update BIOS/EC first (on these boards that is what unlocks the UMA allocation — up to ~96 GB of the unified pool can be presented as VRAM). Serve with all layers offloaded (-ngl 99); for anything larger than the VRAM split, keep it mmap’d but pinned with --mlock, and use zram instead of disk swap so a page fault never becomes a storage stall.
• Backend choice matters on gfx1151. The Vulkan backend of llama.cpp is currently the path of least resistance on Strix Halo; ROCm/HIP works with recent releases (older stacks needed a HSA_OVERRIDE_GFX_VERSION fudge). Benchmark both once and then stop thinking about it.
• Flash attention + quantized KV cache (--flash-attn, --cache-type-k q8_0 --cache-type-v q8_0). Agent sessions accumulate context across tool calls; this keeps the growing attention cost and VRAM footprint flat.
• Keep the server warm, exploit prefix caching. Run llama.cpp’s server as a systemd service so the model stays resident across pipeline stages. Because ICM stages share stable Layer 0–2 boilerplate (handbook + routing + contract preamble), prompt/prefix caching means that context is prefilled once and reused at every stage — TTFT drops to near zero for the structural part of every call. The folder structure literally pays for itself in cache hits.
• Power and thermal consistency beats peak speed. Use GMKtec’s performance mode (the box sustains around 120 W, 140 W peak per spec), set amd-pstate EPP to performance or at least power-profiles-daemon to high-performance — and do not run TLP alongside it. Thermal throttling does not just make runs slower; it makes them different: timeouts fire, background compaction gets interrupted, token/s variance bleeds into wall-clock estimates. Stand the box vertically, keep the intakes clear, pick a fan curve that holds clocks instead of chasing silence during inference windows.
• Process hygiene. Pin the inference server’s threads (taskset) away from the cores the agent’s shell tools hammer; enable transparent huge pages for the weight mappings; keep models on NVMe so even a cold reload is seconds, not minutes.
• Treat sampling like a build system. Temperature 0 and a fixed seed for mechanical stages (compaction, verification, anything that greps or restructures); save the modest temperature for drafting prose. Pin the GGUF file hash and server version like you would pin dependencies — “works on my box” is only acceptable when your box is documented.

The marketing number on GMKtec’s page — a 235B model at ~11 tokens/s on the 128 GB variant — tells you where the ceiling is: memory bandwidth, roughly 256 GB/s theoretical on LPDDR5X-8000. You cannot buy more bandwidth with tuning; what tuning buys you is that every byte of it goes into tokens instead of into paging, re-prefills, throttling recovery and context you never needed. Which is, once again, exactly what the folder structure was already doing at the prompt level.

Conclusion

The paper’s quiet thesis is that the oldest ideas in systems programming — do one thing, pipe text between steps, let files be both artifacts and coordination state — are the right substrate for agent orchestration, because they make the system inspectable by default and steerable without a developer. My todo/ folder turned out to be a multi-pass compiler for website content; the paper gave me the vocabulary to see it, and five concrete fixes to make it better. And on the hardware side, the same philosophy applies one layer down: scope your context, pin your sources, stabilize your thermals — consistency is mostly the discipline of removing variance you did not know you were letting in.

The protocol is open source under MIT (RinDig/Interpretable-Context-Methodology-ICM), and includes a workspace-builder that generates new workspaces from a questionnaire. If you maintain an agent-managed content pipeline of your own, I would genuinely be curious whether your folder structure looks like mine — mine only needed a paper to admit it.

(◣_◢)