The Agent Isn't the Thing You Design

Somewhere in your org right now, someone is drawing a box labeled "Agent" on a whiteboard. Then six more boxes around it, also labeled "Agent," with arrows. The boxes are the fun part to draw and the least interesting part to run.

Jake Van Clief has a video called "Agents are the wrong abstraction layer," and the title is most of the argument. The long version is Interpretable Context Methodology (ICM, arXiv, March 2026), which Van Clief built out of a content production system and wrote up with David McDermott. My day job is pipelines and cloud config at a regulated financial firm, about as far from content production as you can get. I kept nodding anyway. ICM lands where AIEOS keeps landing: the context is what you design and govern. The agent just reads it.

Agents are overused, and we lean on them too hard

Van Clief's line in a Short called "Stop building AI companies" is "Agents are infrastructure, not a company."

Inside an enterprise the same disease shows up differently. The vendor pitch is "deploy our agent." The internal pitch is "we built an agent for X." Both put the agent at the center of the design, so the agent's framework becomes the thing you govern and the thing you explain to Risk. Most frameworks bring their own idea of memory and tool permissions, and their own logs in their own format.

Van Clief refuses the premise. So do I. Models get swapped, and so do harnesses (Claude Code today, Copilot CLI tomorrow, whatever ships next spring). The part that survives each swap is versioned, reviewable context that tells any competent model what the job is and what rules apply. Put the engineering there and the agent question gets boring. Boring is what a regulated platform team wants.

The whole idea fits in one sentence

If the prompts and context for each step already live as files in a well-organized folder tree, one agent reading the right files at the right moment can do the job a multi-agent framework would do.

Numbered folders are stages, so 01-research/ runs before 02-draft/. Each stage has a CONTEXT.md that is its contract: inputs to load, steps to follow and where the output goes. One stage's output folder is the next stage's input. Scripts handle the mechanical parts that never needed a model in the first place.

references/  (stable rules, Layer 3), read by every stage

01-research/  CONTEXT.md --> output/
                             |
              +--------------+   next stage's input
              v
02-draft/     CONTEXT.md --> output/
                             |
              +--------------+   next stage's input
              v
03-review/    CONTEXT.md --> output/

edit surface: a person can fix anything in an output/ folder
before the next stage runs

One agent, three stages. Each stage reads its contract plus the shared rules and writes to a folder the next stage reads. Anything in an output folder can be fixed before the next stage runs. Folder names are illustrative.

Context loads in five layers. At the top sits an orientation file the agent always reads (about 800 tokens in the reference workspace). Below it come routing, the stage contract, stable reference material and finally the working files for this run. The agent reads down and stops once it has enough. Van Clief reports a typical stage pulling 2,000 to 8,000 tokens against 30,000 to 50,000 for one monolithic prompt. Those are his numbers from one model family. I'd read them as a direction, and I'd still take the direction.

My favorite rule in the README is the smallest one: every output is an edit surface. A person can open any intermediate file and fix it, and the next stage picks up the fix. Nobody had to build a human-in-the-loop feature.

The loop is a text editor.

His short version is that one model "can become as many agents as you need" if the data is structured right. I think he's right for most enterprise workflows. They run in sequence, a person or a check reviews each step and nothing about them needs real concurrency. Van Clief and McDermott name the cases where ICM fits badly: real-time multi-agent collaboration, high-concurrency systems and complex automated branching. Those cases exist. They're rarer than the vendor decks suggest.

Start from the folder. Make the framework justify itself.

It's GitOps for prompts

I spend my working days in FluxCD, where the rule is simple: if you want the cluster changed, change the file in git and let the reconciler catch up. ICM is that rule applied to model behavior. The folder holds desired state and the agent plays reconciler.

If the output comes back wrong, fix the contract it read, commit and rerun. Arguing with the agent in a chat window gets you a different answer and no record of why. Every intermediate artifact sits on disk where git diff can see it (Van Clief calls it a glass-box workflow). Anyone who has tried to piece together a multi-agent run from its logs at 2 a.m. knows why that matters.

Mapping it onto AIEOS

AIEOS is my personal project for governing AI-assisted software delivery in a regulated shop. It splits the delivery lifecycle into layers, from strategy and product through release and reliability, plus cross-cutting ones like security and peer review, and each layer gets a kit.

The idea under all of it is traceability. Every SLO target or scope boundary should trace back to an upstream artifact somebody approved. People who never touch the agent should still be able to read what it was told and what it did. Auditors need that. So does the on-call engineer who inherits the thing next March.

Each kit splits its work across separate files, and the split lines up with an ICM workspace closely:

The closest match is one I didn't plan. In ICM, Layer 3 (stable knowledge the model absorbs as rules) and Layer 4 (this run's input) sit in different folders with different lifecycles. In AIEOS the same split comes from freeze-before-promote. Once the architecture doc is frozen, it's an input, and the execution plan built on top of it can't move it. Different mechanism, same instinct: keep the rules and the scratchpad apart.

My one real disagreement

ICM's review gates are manual by design. For a content pipeline that's right, since somebody wants to read every draft anyway. On my team a manual review cadence is an anti-pattern. If a check can't run in the pipeline, it won't survive the third reorg.

So the AIEOS version of "every output is an edit surface" becomes "every output is a reviewable surface, and a pipeline does most of the reviewing." In AIEOS the judging is already mechanical: validators return PASS or FAIL, and a person approves and freezes what passes. The ICM layout gives the check an obvious place to run. A policy check can read a markdown file in a folder just as well as I can.

Testing it on my own work

I've been building an ICM documentation package one work unit at a time: a start-here guide, workspace quick starts, stage references and a worked example workspace. Twenty work units in, the hard part has been my own conventions. The decision log is past 130 entries. My guess is that the numbered-stage model gets awkward the first time two stages want to run concurrently against the same repo. I haven't tested that yet, and I'll write it up when I do.

If you've been drawing the six-boxes diagram, try drawing a folder tree instead. Then decide which one you'd rather get paged about.

Sources: Interpretable Context Methodology repo, Van Clief and McDermott, arXiv 2603.16021, AIEOS governance foundation. The "Agents are the wrong abstraction layer" video title and both Van Clief video quotes are as reported by Araptus.