No production firefight today. Instead I spent the afternoon reading an open-source agent harness end to end, and the conversation it kicked off ended up being the most useful thing I did all week — less about the code, more about where the line sits between “the model decides” and “the code decides.”

the thing i was reading

It’s a harness built on one slogan: everything is a plugin. The model adapter, the tool registry, the session log, even the agent loop itself — all plugins mounted onto a shared context, nothing privileged, everything swappable from config. It’s big (a couple hundred packages) and unusually disciplined. The whole point of the design is that one provider swap propagates through a whole family: point the filesystem and shell capabilities at a remote sandbox and your Bash, your PTY, and your language server all move with them, no forks.

My first reaction was skeptical — this sounds like architecture-astronaut stuff. Why not just make everything an MCP tool? Or better, why not just a markdown file with a few examples telling the model what to do?

the part that actually clicked

The answer that made it make sense: plugin, MCP, and markdown aren’t competitors. They’re the same thing — a contract between a function provider and a consumer — at three different binding times.

• markdown few-shots: contract bound at inference time (the model reads it and decides)
• MCP: contract bound at connection time (a wire protocol to reach a tool in another process)
• plugin: contract bound at compile/boot time (in-process, resolved before anything runs)

Once you see it that way, the “why not just markdown” question dissolves. Markdown is inert — it can’t open a socket or hold an abort signal or guarantee a crashed session resumes exactly. Something has to run the markdown and host the MCP client. That something is the harness, and you can’t build it out of the things it hosts. The real argument isn’t plugin-vs-markdown; it’s “how much of your runtime needs to be deterministic code, and how much can float up to the model.”

the frozen/fluid line

That’s the idea I want to keep. Every capability sits somewhere on a spectrum from frozen (deterministic code, always the same answer) to fluid (the model decides at inference time). And you can literally see the line drawn inside a real system:

• fully frozen: text search delegates to a shipped ripgrep binary; a literal string-replace edit tool. The model chooses whether to call it; the behavior is fixed.
• frozen heuristic: a “model-free” history pruner sitting right next to an LLM-based summarizer — the same job (shrink the context) done two ways, and the deployment picks which.
• the migration mechanism: a “code mode” where instead of the model calling ten tools over ten round-trips, it writes one program that calls them as function bindings, and a deterministic runtime executes it. For the length of that program, the model’s intent is frozen into code.
• fully fluid: the loop’s model call itself, deciding the next move.

The interesting bet — and I think it’s right — is that the boundary moves but never vanishes. New, ambiguous, rare work is model-decided. The moment something is hot and its behavior has stabilized, the economically correct move is to freeze it into deterministic code and stop paying the inference tax. And the cost argument is what makes this permanent: even if hardware gets absurdly fast, the ratio between an LLM computing 2+2 and an ALU computing 2+2 doesn’t shrink, because both ride the same hardware. Physics keeps a frozen core cheaper, forever.

the brain analogy i keep coming back to

Here’s where it got fun. The counter-argument was: isn’t the deterministic core also learned? You don’t start knowing 2+2. You learn the addition algorithm, and then it’s automatic. It all starts fluid and freezes into a script. So why won’t the model eventually control everything, even the small functions?

I think that’s directionally true — and it’s exactly how a good harness is meant to work: fluid at the frontier, frozen at the core, with a live boundary that migrates. But two differences matter:

1. The brain freezes into the same substrate; a machine can freeze into a better one. When you “just know” 2+2, that’s a cached neural pattern — still fallible, same wetware. A machine can offload 2+2 to something that is exactly right, always. So a machine’s frozen core can be more correct than its fluid frontier. Yours never is.

2. The brain freezes itself; these systems (today) are frozen by humans. A developer decided text-search should be ripgrep. The model doesn’t yet notice a recurring pattern and promote it to a permanent tool on its own. That auto-promotion — the model freezing its own hot paths — is the missing piece, and it’s the actual near-future step. The “code mode” above is half of that bridge already built.

So the frozen core isn’t the opposite of “it all starts from a simple model.” It’s the fossil record of it. Every deterministic tool in the catalog is a behavior that was once figured out fluidly and then paid to freeze — same as your addition algorithm. The architecture’s real job is to make that fossilization cheap, and eventually to let the model do the freezing itself, at runtime, instead of a human doing it at build time.

When that closes the loop, “the model controls everything” and “everything is a frozen plugin” stop being opposites. They become the same picture a moment apart: the model owns the frontier, and owns what gets frozen behind it.

Good day to read code instead of restart a JVM.