Agentic Context Engineering Without The Agent Swarm.

Ryan “RyMac” McKinney · USMC · 15 August 2026 · 6 minute read

Agentic context engineering is deciding what an AI can see when it is taking actions rather than just answering a question. The stakes go up, because a wrong answer is annoying and a wrong action costs you a client. Almost every guide solves this with more agents. That is the part I disagree with.

What changes when the AI acts instead of answers

When it answers, you read it and catch the mistake.

When it acts, it already sent the email.

So the question stops being "did it understand me" and becomes "did it have everything it needed before it moved."

The standard answer, and why it fails small operations

Open any guide on this and you get a diagram. A researcher agent hands to a writer agent, which hands to a critic, which hands to a publisher.

It looks like a team. Here is what it is.

Add a 9th agent and you have not added a teammate. You have added a 9th place for the truth to get dropped on the floor.

And the measured data is not kind to the swarm. Across a large set of multi-agent setups, results ranged from 70% worse at the bottom end to 81% better at the top. I give you both numbers because giving you one is how people get taken apart in public.

The 81% is real. It shows up when the work is genuinely parallel and there is an engineering team maintaining the thing. If that is you, build the swarm.

The version for everybody else

Most small operations are not doing parallel work. They are doing one job after another, badly filed. You may hear that called sequential work. Then they buy concurrency, which simply means paying for more than 1 worker at the same time, to fix something that was never a speed problem. It was a filing problem.

1 worker with a good map never has to hand anything to anybody. It goes and looks.

~/business/
├── CLAUDE.md          <- the map. 11 lines. always read first
├── Context.md         <- the desk. what we're doing today
└── ops/
    ├── clients/
    ├── offers/
    ├── sops/
    └── archive/

The map is read first, every time. It sends the agent to 1 file. That file names the folder holding the job. The agent opens that folder and acts from what is in it.

When the job changes, the file changes. Nothing has to agree with anything else, because there is only 1 worker. You may hear the opposite called a coordination problem. It simply means your robots are disagreeing with each other.

The test that tells you which one you need

Ask yourself: do the pieces of this job need to agree with each other?

If yes, you do not want 2 of them working at the same time and then arguing about whose version is right. You may hear that called reconciling. You want them going one after the other, off 1 file that holds the truth.

If the answer is no, run them in parallel. 3 things happening at once with no overlap is faster.

In my own businesses the honest answer has been no almost every time.

Where this comes from

The method is Interpretable Context Methodology, ICM. Jake Van Clief and David McDermott wrote the paper. Folder structure as agent architecture, which is exactly what the name says. Jake teaches it himself over at Clief Notes.

Every ICM Folder System I have built, the free ones and the ones people paid for, is on 1 page. Take the 1 that matches where you are.