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 sequential work, badly filed, and they bought concurrency to fix an organising 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. There is no coordination problem because there is nobody to coordinate with.

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 them running in parallel and reconciling later. You want them sequential, against 1 shared source of truth.

If genuinely no, and 3 things can happen at once with no overlap, parallel is faster and you should use it.

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.

The plain-English breakdown lives here: Interpretable Context Methodology in plain English. The broader idea is in the context engineering post.