The contest moved above the agent, onto the layer that orchestrates the fleet. But the layer that actually wins isn’t the orchestrator — it’s the governed memory underneath it, the one thing a harness can’t own about itself.
In the essay Harness Orchestration: The Layer Above the Agent, Egor Pushkin names an agentic architecture layer I had been circling without quite pinning down. His argument is simple and, I think, correct: the interesting contest is no longer the harness, the scaffolding that turns a model into a working agent. That layer is crowding and commoditizing in real time. The contest has moved up, onto the meta-harness — the layer that drives many agents and many harnesses at once, and does it as one governed session.
The essay’s best move is its last one. After cataloguing the seven organs — the components every orchestrator keeps reinventing (an adapter to wrap different agent CLIs, a router to pick one, isolation to sandbox them, a coordinator, a governor, a work source, a loop) — it lands on a single line about where durable advantage actually sits: the layer that wins owns governed state across harnesses, because that is the one thing a harness, by construction, cannot own about itself. A harness governs itself. Only the layer above it can govern the fleet.
I read that and my first instinct was to plant a flag: ENGRAM, the memory system I’ve been building, is a meta-harness. It manages multiple harnesses of any vendor, shares memory with them, and aggregates what they learn.
Then I looked at the arrow, and the arrow points the wrong way.
The arrow points the wrong way
A meta-harness, in the essay’s own definition, drives harnesses. It reaches down and calls their command-line interfaces: it wraps them behind one adapter, routes a task to whichever one should run it, spawns each in an isolated work-tree, and turns the plan-act-verify crank until the goal is met. The orchestrator is the caller. The harness is the callee. Every one of the seven organs assumes that direction.
ENGRAM runs the other way around. It doesn’t spawn Claude Code or Codex or Aider; it is reached by them, over an MCP server, when they want to remember something or recall something. It never picks which harness runs, never sandboxes an execution, never owns the loop. Line ENGRAM up against the four organs that actually constitute an orchestrator (adapter, router, isolation, loop) and it scores a clean four zeros. If ENGRAM were trying to be a meta-harness, that scorecard would be an indictment.
It isn’t trying to be one. And the reason the mistake is worth writing down is that correcting it moves ENGRAM to a better seat, not a lesser one.
The eighth — and it’s not an organ
The essay is careful to note that underneath the seven organs sits something it declines to call an eighth organ, because it isn’t a peer — it’s the substrate the others all write to. The run journal. The checkpoints. The append-only log that lets a crashed orchestrator resume the fleet instead of losing it, and lets a human ask “what happened” and get a real answer. The essay’s own words: an orchestrator that persists its runs has already started building the substrate, and that substrate is the most direct bridge to Layer 3 — the destination where work itself becomes durable, governed, executable state.
That is the seat. ENGRAM is not one of the seven organs. It is the governed, associative, cross-vendor memory those organs write to and read from — horizontal to the orchestrators, underneath all of them. And that is precisely the seat the essay names as the moat. “Governed state across harnesses” is not a modest corner of the map; it’s the whole prize. A harness can’t own memory about the fleet for exactly the reason the essay gives: a harness sees only itself. The layer that sees across every harness, on the one dimension that most needs to be shared and governed — what the fleet knows — is a different layer, and it’s the one worth owning.
So I’ll state the claim the way it should be stated. ENGRAM is not a meta-harness. It is the layer above the meta-harnesses on the dimension of memory: the governed knowledge substrate that any orchestrator, of any vendor, can read and write.
The coordination is the memory
Here is where the substrate stops being a passive log and starts being an architecture.
The field coordinates agents the way distributed systems always have — task boards, mailboxes, message passing, and now emerging standards like A2A for agent-to-agent chatter. Those are real and useful. But there is another way to coordinate a team, and it falls out of the memory layer for free. If every agent writes what it finds into one associative store, and every agent reads from that same store under governed scope, then directing the team is just writing and reading memory. There is no separate coordination channel to stand up, because the coordination is the memory.
I wrote a version of this in my last post and undersold it as an implementation detail. It isn’t a detail; it’s the differentiator. Where A2A standardizes the messages agents send each other, a governed memory substrate offers something A2A doesn’t: shared associative recall, with the access rules enforced at the moment of reading. An orchestrator fans work across a handful of harnesses; each remembers its findings in its own isolated scope; the orchestrator recalls across all of them; and when a piece of work closes, ownership of what was learned hands off cleanly to whoever needs to keep it. No board. No mailbox. The team is coordinated because it shares a memory, and the memory knows who is allowed to see what.
It’s worth naming what this resembles. A brain doesn’t coordinate its regions by passing messages down a bus — cognition is the shared associative substrate itself, each region writing to and reading from the same networked memory, no single neuron holding the thought. A fleet of agents on a shared store works the same way: no one agent holds the whole picture, the picture is the pattern across the memory they all touch. The difference (the one biology never had to solve) is that this memory has to know who’s allowed to recall what. That’s the whole reason it must be governed, not merely shared.
Two planes of governance
One honest distinction, because it’s the place a careful reader of the essay will push back, and they’d be right to.
When the essay says governor, it means enforcement at the tool-call boundary: spend caps, permission gates, risk escalation — a hard stop around what an agent is about to do, not a polite request in a prompt. ENGRAM does not do that, and shouldn’t pretend to. What ENGRAM governs is a different resource entirely: what an agent may know (which memories it can recall, share, or hand to the next agent) enforced fail-closed, with explicit revocable grants and agents that have to be opted in before anything can be shared to them at all.
Call them two planes. The action plane governs what an agent may do and spend. The knowledge plane governs what an agent may know and pass on. A governed fleet needs both, and they compose rather than compete: a hook-based governor at the tool call, a memory governor at the recall. I’m building the second one. I’m happy to let the orchestrators own the first, and I think the cleanest version of this whole stack is the one where those two planes are held by two different components that were each designed for their own job.
Why this is the position I want
Three reasons, and then I’ll stop.
The essay’s headline forecast is consolidation — most of today’s orchestrators die or merge, the harness becomes a commodity adapter, the orchestrator becomes the product. If ENGRAM were an orchestrator, that forecast would be a threat. Because ENGRAM is the memory substrate beneath the orchestrators, the same forecast is a tailwind: every orchestrator that survives is a potential reader of the same governed store, and every one that gets archived costs me nothing. A substrate that any harness can call is a build-once, reuse-everywhere layer by construction.
The advantage is structural, not benchmark-able. Models are rented; you can swap one for a better one next quarter. A governed runtime that holds state across harnesses is owned, and a competitor can’t copy it off a leaderboard, because the thing of value isn’t a score — it’s the accumulated, governed, cross-agent memory and the rules under which it moves.
And the direction of travel is the right one. Today the agents being coordinated write code, because code has the tightest feedback loop in knowledge work. But none of this is about code. A memory substrate that lets a fleet of coding agents share what they learn, under governance, is the same substrate a fleet of research or operations or compliance agents will need the moment those domains get a feedback loop worth trusting. The orchestrators climb out of the repository; the memory layer climbs with them.
So I’ll take the essay’s advice and invert my own pitch. Don’t bet on a harness — they’re replaceable, and that’s the point. Don’t even bet on being the orchestrator; that quadrant is a knife fight. Bet on the one layer a harness cannot own about itself, and build it so that every harness, of every vendor, is better for reading from it.
That layer is memory. Governed, shared, and owned.
Igor's Musings About Technology 