---
schema_version: "newruntime-agent-readable-v0.1"
type: "tectonic_shift"
slug: "shared-context-infrastructure"
title: "Client-local memory -> shared context infrastructure"
description: "Context is shifting from private memory inside one AI client into a governed layer between agents, IDEs, documents, and tools."
status: "published"
before_state: "Each AI client keeps its own incomplete project memory"
after_state: "Shared context layer with provenance, governance, and portability"
stage: "emerging"
confidence: "medium"
magic_decay_stage: "demo"
first_seen: "2026-07-21"
last_verified: "2026-07-21"
related_posts: ["unabyss-shared-context-layer","ghostwriter-agent-memory-poisoning"]
topics: ["context-engineering","agent-memory","mcp"]
source_urls: ["https://unabyss.com/","https://www.producthunt.com/products/unabyss"]
routes: {"html":"https://newruntime.com/shifts/shared-context-infrastructure/","markdown":"https://newruntime.com/shifts/shared-context-infrastructure.md","json":"https://newruntime.com/shifts/shared-context-infrastructure.json"}
source_format: "markdown"
---

# Client-local memory -> shared context infrastructure

When Claude, Codex, Cursor, and other clients work on the same project, the
human often becomes the manual sync layer. This shift captures another option:
context lives as standalone infrastructure, and clients connect to it with
different permissions.

## Evidence

Unabyss shows an early product signal: the context layer can move outside a
single client and be connected through an MCP-compatible surface.

## Risk

A shared context layer amplifies both usefulness and risk. The GhostWriter piece
shows the other side of persistent memory: if memory can be poisoned, it cannot
be treated as an ordinary prompt dump.