The New Engine: The Context Protocol

← Part I: The Paradigm Flip | Part III: The Bootstrap Spiral → | Part IV: The Living Kernel →

Part I argued that compensatory structures -- meetings, specs, approvals, UIs -- evaporate when agents replace humans on the main execution path. The paradigm flips. The translation layer disappears.

But what replaces it?

Not nothing. When the compensatory structures evaporate, what remains is the need for context -- the raw material those structures were built to transport. Meetings existed to share context. Documents existed to store context. Approvals existed to verify context was understood. The structures were the plumbing. Context was the water.

Remove the plumbing designed for human-speed flow, and you need new plumbing designed for agent-speed flow. That's the context protocol.

The Three Layers

Today's agent systems have three layers, in varying states of existence.

Skills are procedures. "Here's how to create a blog post: write markdown, add frontmatter, run the build." A skill encodes the steps. It's static, written by humans, triggered on demand. Most agent frameworks have this layer -- Claude Code has .claude/skills/, Cursor has rules, Copilot has instructions.

Context is facts. "This project uses monospace fonts, no emojis, the date format is YYYY-MM-DD." Context encodes what is true about the environment. It's partially implemented today -- CLAUDE.md files, .cursorrules, system prompts. But these are static, manually maintained, loaded at session start and never updated.

Memory is experience. "Last time we upgraded this dependency, it broke the build. The user always wants bilingual posts. Excerpts over 150 characters get truncated on the homepage." Memory encodes what happened before and what was learned from it.

Most systems have the first layer. Some have fragments of the second. Almost none have the third.

The skill is the skeleton. Context is the muscle. Memory is the nerve. Most agents today are skeletons with partial muscle and zero nerve.

Context Is Not a Database

The immediate objection: isn't this just a database? Can't Postgres handle all of this?

Partially. Postgres is a fine storage engine for the bits. But context has three properties that make it fundamentally different from data in a table.

Relevance is not a predicate. A database answers "give me all rows where service = 'auth'." The result is deterministic. Every row either matches or doesn't. Context relevance is different. When an agent is debugging a payment failure, the relevant context might include an auth migration from last week, a rate limit change mentioned in passing, a staging config discrepancy, and a decision made three months ago to deprecate v1 tokens. None of these share a foreign key. None would match a SQL WHERE clause you could write in advance. Relevance depends on what the agent is trying to do, not on the structure of the data. This is a recommendation problem, not a query problem.

Context has provenance and decay. A database row is a fact -- it's there or it isn't. Context is an assertion with metadata: who said it, when, with what confidence, and under what conditions it becomes invalid. The same fact asserted by a monitoring agent 30 seconds ago is high-confidence context. The same fact from a design doc written six months ago is almost worthless. Context has a half-life that depends on its type. Architectural decisions decay slowly. Runtime observations decay fast. The database stores the bits; it doesn't understand what "stale" means for a particular type of assertion.

Context is heterogeneous. A database has a schema. Context spans code diffs, test failure traces, architectural decisions and their rationale, running service metrics, conversation history between agents, and system topology. These don't share a schema. They don't even share a modality. The context system needs to unify these into a single queryable surface, ranked by relevance to the current task.

Postgres is to the context system what the filesystem is to Git. Git uses the filesystem to store blobs. But the value -- branching, merging, history, distributed collaboration -- lives in the protocol layer above. You wouldn't say "the filesystem meets the requirements for version control."

Same here. Postgres stores the bits. The context protocol gives them meaning, relevance, provenance, and liveness.

The Four Operations

A context protocol has four operations. Everything else is implementation detail.

Publish. An agent completes a task and publishes what it learned. Not a document. Not a message. A structured assertion with confidence, provenance, and invalidation conditions. "marked v12 breaks custom heading IDs without a plugin. Confidence: 1.0. Source: build failure at scripts/build.js:47. Invalidated by: marked major version change."

Query. Before acting, an agent describes its intent and asks what it should know. Not a keyword search. Not a SQL predicate. A semantic query: "I'm about to upgrade dependencies in this project. What should I know?" The system returns relevant past experiences, ranked by similarity, recency, and confidence. The agent didn't ask for a specific fact. It described what it's trying to do, and the system figured out what's relevant.

Subscribe. An agent registers standing interest in a domain. "Notify me when anything about the auth service changes." When any agent publishes to that domain, subscribers get updated without polling. This is pub/sub applied to knowledge, not events.

Invalidate. An agent declares a previous assertion superseded. "My earlier claim about auth latency is no longer valid after the deploy." Without invalidation, you get what we have with documentation today -- a graveyard of stale assertions that actively mislead.

Every context entry has a lifecycle: born, active, challenged, superseded, archived. Without this lifecycle, context becomes documentation. And documentation rots.

The Experience Problem

Skills aren't enough. Here's why.

Consider the blog-creator skill. It encodes the procedure: write markdown, add frontmatter, build. But watch what happens across sessions:

Session 1: Agent uses the skill. User corrects: "make it bilingual." Agent adds EN/ZH divs. Session ends. Learning lost.

Session 2: Agent uses the same skill. Creates English-only post. User says "make it bilingual" again. Same correction. Same cost. No memory.

Session 3: Same thing.

The skill encodes the steps. It doesn't encode that this particular user always wants bilingual content, that excerpts should be under 150 characters, that the references section should go at the end. You could update the skill manually. But that's the human-bandwidth bottleneck again -- the human must notice the pattern, decide it's worth encoding, write the update, and maintain it. A compensatory structure.

With experience extraction:

Session 1: User corrects. The system extracts: "user prefers bilingual EN/ZH posts. Confidence: 0.7. Evidence: user correction."

Session 2: Context layer injects the preference before the skill executes. Agent creates bilingual post without being told. User doesn't correct. Confidence: 0.7 becomes 0.9.

Session 3: Confidence 0.95. Effectively a learned constraint.

The skill stays generic. The context accumulates specificity. Clean separation. The procedure doesn't bloat with edge cases. The context layer carries the personalization.

This is the compiler analogy. Skills are source code -- static, written by humans, version-controlled. Context is runtime state -- dynamic, accumulated during execution, machine-maintained. Experience is profiling data -- captured from past runs, informing optimization of future runs. You wouldn't hardcode profiling data into source code. You wouldn't throw away runtime state between executions. But that's exactly what agent systems do today.

Proactive Context: The Missing Loop

The hardest problem isn't storage or retrieval. It's this: the agent doesn't know what it doesn't know.

A database waits for queries. A skill waits for triggers. But an agent about to make a mistake doesn't know to ask "have I made this mistake before?" The context protocol's real job isn't data management. It's closing the gap between what the agent is about to do and what it should know before doing it.

Two loops, not one. Injection before action and extraction after action. Both must be automatic. If either requires the agent to explicitly decide to do it, it won't happen consistently -- for the same reason developers don't update documentation.

Injection works by intercepting intent. Before the agent edits package.json, the system asks: "given what this agent is about to do, what context should it know?" It encodes the intent as an embedding, retrieves semantically similar past experiences, checks standing subscriptions, evaluates confidence and staleness, and injects the relevant context. The agent now knows that the last marked upgrade broke heading IDs -- not because someone told it, but because the protocol surfaced a relevant experience.

Extraction works by distilling sessions. When the agent finishes a task, a lightweight process reads the session and extracts: what was learned, what was surprising, what preferences were expressed, what failed and why. These become new context entries, published automatically. No human involved.

This is architecturally similar to hooks -- code that runs before and after tool calls. The difference is the hook doesn't execute a shell command; it queries the context store and injects relevant results into the agent's prompt.

From Telling to Knowing

Part I described the Florence tipping point -- when agent-to-agent transactions dwarf human-to-software interactions. The context protocol determines whether that scale is intelligent or amnesiac.

Today, agents communicate via messages. Agent A sends Agent B a text blob: "The auth service uses JWT with 15-minute expiry." Agent B receives it, uses it, session ends, knowledge gone. If a third agent needs the same fact later, nobody knows it was ever established. Every agent interaction is a first date.

This is "telling" -- the same model human organizations use. Meetings, emails, handoffs. Push-based, point-to-point, ephemeral. The compensatory structure.

The alternative is "knowing." Agent A completes a task and publishes what it learned to the shared context store. Agent B doesn't receive a message. It subscribes to relevant context changes and its local state updates automatically. Agent C, spawned three days later, queries the store and inherits the accumulated knowledge of every agent that came before it.

No messages. No documents. No "here's what I found." Just state transitions propagating through a shared substrate.

The difference between telling and knowing is the difference between Florence and Tokyo. In Florence, everyone knows everyone. Information travels by conversation. The mayor can walk across the city and talk to every shopkeeper. In Tokyo, nobody knows the full picture. But the subway system, the power grid, the telecommunications network -- the infrastructure -- maintains the coherence that no individual could. The city works not because its residents understand it, but because the substrate does.

Agent organizations need the same transition. From "agents telling each other things" to "the substrate knowing things that any agent can query."

What Exists, What's Missing

Primitive forms of the context protocol already exist:

CLAUDE.md, .cursorrules -- static context files agents read on startup. Manual, stale the moment they're written. But directional.

MCP (Model Context Protocol) -- Anthropic's protocol for giving agents access to tools and data sources. Solves tool discovery, not context propagation. A start.

Test suites -- the Ralph Wiggum loop demonstrated that a test suite can simultaneously be the spec, the validator, and the acceptance criteria. This is context encoded as executable assertions. Powerful but narrow.

Git history -- the entire evolution of a codebase, queryable by time. Underused as a context source.

What's missing:

Experience extraction -- auto-distilling learnings from sessions into structured assertions.

Semantic retrieval -- querying by intent ("what should I know before modifying this?"), not by keyword.

Context propagation -- pushing relevant context to agents before they act, without being asked.

Cross-agent sharing -- Agent A's learning available to Agent B, across sessions, across time.

Confidence and decay -- context that knows when it's stale, with provenance tracking.

Invalidation -- superseding outdated assertions so they stop misleading.

The Incremental Path

Grand protocols don't get adopted. Incremental tools that solve immediate pain do.

Layer 1: Memory file. An append-only JSONL file where the agent writes one-line learnings after each session. Loaded next session via system prompt. No semantic search. No invalidation. But it solves "Session 1 learning lost by Session 2" immediately. This works today with zero infrastructure.

Layer 2: Semantic retrieval. Each learning gets embedded. Before each task, query the log by semantic similarity to the current task description. Top-5 relevant experiences get injected. Now the agent doesn't just remember -- it remembers what's relevant.

Layer 3: Provenance and decay. Each entry gets a confidence score that decays with time. New entries can explicitly supersede old ones. Stale context stops polluting retrieval results.

Layer 4: Cross-agent propagation. Multiple agents share the same context store. Agent A's experiences are queryable by Agent B. Subscriptions enable proactive notification. Invalidation propagates across all subscribers.

Layer 1 is a JSON file. Layer 4 is the context protocol. But each layer is independently useful. The protocol emerges from the pattern, not the other way around.

What This Means

Part I argued that compensatory structures evaporate when agents replace humans on the main path. Part II argues that what replaces them is not nothing -- it's context infrastructure. The protocol that lets agents accumulate intelligence over time instead of starting from zero every session.

Skills tell agents how. Context tells agents what. The context protocol is what tells agents what happened before -- and makes that knowledge available to every agent that comes after.

Without it, every agent interaction is a first date. With it, agents inherit the accumulated intelligence of every session that preceded them. The substrate remembers what no individual agent could.

The document evaporates. The state graph remains.

References

• The New Engine: The Paradigm Flip -- on compensatory structures and the paradigm flip
• Model Context Protocol (MCP) -- Anthropic's protocol for tool and data source access
• The Ralph Wiggum Loop -- on agents running autonomously in loops
• CLAUDE.md -- primitive context files for Claude Code