the Context Layer: give AI the context it needs without giving it everything

AI systems become more useful when they understand the person, project, history, & constraints around a task. today, the common way to provide that understanding is also the source of the problem: copy more private data into more applications, prompts, vendor databases, vector stores, & agent sessions.

that trade differs from sustainable. people should not have to choose between an assistant that knows nothing & an assistant that can read everything.

the Context Layer is a proposed application-layer protocol for a different model. a person keeps a user-owned context vault containing source events, derived claims, summaries, provenance, identity bindings, & policies. apps & agents do not receive an open-ended vault connection. they make a purpose-bound request. a policy boundary evaluates it. a semantic proxy releases the minimum useful context as a short-lived bundle. sensitive operations leave receipts. any new memory suggested by an agent returns as a proposal rather than silently becoming truth.

in one sentence:

the Context Layer lets useful context move while keeping authority, provenance, & disclosure boundaries attached.

this project is currently a proposal & interactive architecture demonstrator. it differs from yet a production vault, deployed standard, completed security system, or claim that every named integration already exists.

the missing layer in today's AI stack#

most modern AI stacks have several well-developed layers:

networks & transports move bytes.
application apis expose data & actions.
agent protocols connect models to tools or other agents.
models interpret information & generate outputs.
user interfaces turn those outputs into workflows.

what is often missing is a durable contract for the context between them.

when context has no independent contract, every app invents its own memory model. a chat transcript becomes a profile. a profile becomes a retrieval index. a retrieval index becomes an implicit permission grant. an extracted guess becomes a durable fact. a helpful automation becomes an action whose inputs & authority are hard to reconstruct later.

the result is a set of recurring failures:

problem	common behavior today	Context Layer response
context fragmentation	the same person or project is reconstructed separately in every app	normalize sources into a user-controlled context model with provenance
coarse access	an integration receives an entire mailbox, drive, or memory store	require a purpose, requested fields, recipient, retention window, & policy decision
prompt overexposure	raw notes are pasted into a model because extracting the relevant part is difficult	use a semantic proxy to redact, alias, compress, & route task-specific facts
lost provenance	a summary survives after its source & confidence are forgotten	keep source references & derivation metadata attached to claims
stale or contradictory memory	the latest generated summary overwrites older nuance	version summaries & preserve contradictory branches until they are resolved
silent writeback	an agent observation becomes memory without review	treat writeback as a proposal requiring validation & policy approval
private discovery leakage	external search or matching services inspect a full private profile	run matching behind an inbound discovery proxy & release only a minimum reveal
invisible automation	users cannot tell which context caused an action	write reviewable receipts for policy decisions, model calls, tools, bundles, & external actions

the Context Layer does not solve these problems by building a bigger shared database. it solves them by making movement itself explicit.

a tour of the protocol#

the architecture has seven stages. they form a continuous path, but each stage has a distinct responsibility.

1. capture source events#

context begins as events: a message arrived, a file was imported, a browser page was clipped, a meeting ended, a payment completed, a voice note was recorded, or a device reported a signal.

capture does not immediately declare what an event means. it records what happened & where it came from. source tagging adds the app, account, device, URL, author, transport, timestamp, integrity data, confidence, & whether a user confirmed the source.

this distinction matters. a source event is evidence. an interpretation is a claim derived from that evidence.

2. normalize & extract without erasing origin#

email, Matrix events, ActivityPub activities, browser clips, files, & agent messages all have different shapes. normalization maps them into stable event records. deduplication can recognize that two channels carried the same underlying event while preserving both sightings as provenance.

extraction then derives entities, relationships, claims, time ranges, locations, commitments, embeddings, & possible contradictions. derived records keep links back to the source events that support them. confidence & validity are attributes, not afterthoughts.

the goal differs from to force the world's data into one universal ontology. the goal is to provide a small stable envelope that can carry typed domain data without losing evidence.

3. keep the vault as the authority boundary#

the user-owned context vault is the private authority boundary. it may be local-first, self-hosted, organization-hosted, or provided as a managed service, but the ownership contract stays the same: consumers request context; they do not receive unrestricted raw-vault reads by default.

the vault can contain:

raw source events & attachments
normalized records & extracted claims
a memory graph of entities & relationships
versioned summaries
contradictions & alternate branches
provenance & integrity records
identity & permission bindings
policy rules & consent state
scoped bundles & receipt references

'user-owned' therefore means more than where bytes are stored. it means the user, or an explicitly delegated authority, controls access, export, correction, deletion, key recovery, & policy.

4. turn access into a request & a decision#

an external agent should not ask, 'can i see the memory?' it should submit an egress request that says:

what task is being performed?
which context fields or claim types are needed?
who is requesting them?
which model, tool, agent, or organization will receive them?
what actions might follow?
how long may the context be retained?
does the request permit onward disclosure?
which receipt must be produced?

the policy boundary evaluates identity, scope, purpose, consent, expiration, requested action, sensitivity, & current user rules. its result can be allow, deny, allow with reduced scope, or require approval.

consent differs from a checkbox that permanently legalizes every future use. in this model, consent is bound to a purpose, recipient, scope, & time window.

5. use proxies to reveal less#

the semantic proxy is the outbound gate. it can:

remove fields unrelated to the task
redact confidential values
replace identities with stable aliases or pseudonyms
compress many source records into a few task-level claims
route different fields to different recipients
preserve provenance handles without exposing raw source payloads

the discovery proxy performs the inverse pattern for inbound matching. an opportunity feed, public relay, recruiter, marketplace, or other external system can ask whether a private profile matches a condition. the query is authenticated, rate-limited, & evaluated inside the user's boundary. the response reveals the smallest useful next step, such as 'available for a paid prototype engagement,' rather than the underlying skills graph, private notes, or work history.

minimum reveal differs from perfect privacy. repeated yes/no queries can still leak information. that is why discovery needs identity checks, query budgets, correlation defenses, receipts, & escalation to user approval.

6. deliver a scoped context bundle#

the output is a scoped context bundle: a task-ready, short-lived packet containing only the approved material.

a bundle can carry:

approved facts & summaries
provenance references
purpose & task definition
instructions & behavioral constraints
allowed tools & actions
explicitly denied actions
expiration & retention rules
surface hints for cards, tables, maps, timelines, or workspaces
a receipt contract

for an agent, this is the difference between 'here is my entire memory' & 'draft this reply using the deadline & stakeholder, do not send it, do not mention the confidential budget note, & expire the context after 24 hours.'

the bundle is where policy becomes executable context.

7. make actions & writeback reviewable#

approved bundles can be consumed by a local agent, cloud model, workflow runner, voice interface, search surface, browser overlay, or self-assembling UI. the consuming surface should show enough policy & provenance state for a person to understand why information is present & what actions are available.

sensitive operations write receipts. a receipt records who or what acted, which policy decision authorized it, which bundle was used, what kind of operation occurred, when it happened, & whether it succeeded. input & output digests can support later integrity checks without storing sensitive payloads in the receipt itself.

receipts are evidence, not magic. a signed record can prove that a component reported an action; it cannot prove that the action was wise, that the source was true, or that no undisclosed side effect occurred. useful receipt systems still need trustworthy implementations, readable summaries, retention policy, & audit tooling.

finally, an agent's new observation returns as a proposed memory update. the system can check its sources, compare it with existing claims, score contradictions, & request user approval. only then can it become durable context.

a concrete example#

imagine that an email says:

can you send the launch timeline by friday? do not disclose the budget delta yet.

the Context Layer flow could look like this:

capture: record the email as a private source event with sender, account, timestamp, & message identity.
extract: derive two claims: a timeline is requested by friday, & a budget detail is restricted.
request: an email-drafting agent asks for the context needed to draft a reply.
policy: permit the deadline & stakeholder; deny the confidential budget note; allow drafting but not sending; set a 24-hour expiry.
proxy: produce a concise task summary & retain opaque provenance handles.
bundle: deliver the approved facts, email_draft tool permission, 'do not send' instruction, expiry, & receipt requirement.
interface: show a draft with preview, edit, & approve controls.
receipt: record bundle creation, model use, & draft generation.
writeback: if the agent suspects the deadline moved to thursday, store that as a proposal requiring a source or user confirmation, not as an automatic correction.

the assistant remains useful. the budget note never needed to leave the vault. the user can see what happened.

who this is for#

people using several AI products#

individuals should not have to rebuild their preferences, projects, relationships, & history inside every assistant. a portable Context Layer can let them switch models or interfaces while retaining control over the source material & disclosure rules.

agent & application developers#

developers need a predictable input contract. scoped bundles give agents structured facts, instructions, tool limits, & expiry instead of a pile of unbounded retrieved text. receipts & proposed writebacks also make evaluation & debugging more concrete.

product teams building AI-enabled workflows#

teams can use the layer to separate context governance from each product surface. a search view, dashboard, voice interface, & automation can consume the same approved bundle while presenting different interfaces.

organizations with audit or privacy obligations#

purpose binding, provenance, short-lived access, user approval, & receipts map well to environments where data use must be explainable. the Context Layer differs from itself a compliance certification, but it creates better places to enforce & test organizational controls.

open-protocol & decentralized-web communities#

open social, messaging, storage, & agent protocols move information across independent systems. Context Layer adapters can add a user-owned decision boundary before those systems receive private context, without replacing their native transport or data models.

marketplaces & discovery systems#

private matching can support opportunities, collaborators, services, or communities without publishing a complete personal graph. the discovery profile is aimed at exactly this class of use case.

what it can work with#

the Context Layer is designed to sit above existing protocols, not compete with them.

web & messaging sources#

HTTP apis, email, files, browser events, audio, device signals, Matrix rooms, ActivityPub activities, AT Protocol records, Nostr events, & application-specific webhooks can all be represented through capture adapters. the adapter's responsibility is to preserve source identity, timing, integrity information, & native semantics.

ActivityPub, for example, defines client-to-server & federated server-to-server social interactions over activitystreams. AT Protocol has its own self-authenticating identity, repositories, & lexicon schemas. Nostr uses signed events distributed through relays. Matrix defines JSON-over-HTTP apis & federated room state. Context Layer should map these systems into source & provenance records; it should not flatten away their security or consistency models.

agent protocols#

Model Context Protocol [MCP] standardizes how AI hosts connect to resources, prompts, & tools. Context Layer can expose an approved bundle as an MCP resource or require a Context Layer request before a sensitive MCP tool executes. MCP remains the tool & resource protocol; Context Layer supplies the user-owned context policy around it.

agent2agent [A2A] standardizes collaboration between independent agents. a Context Layer bundle can be carried as structured task data or an artifact, with recipient & retention constraints bound to the remote agent. A2A remains the agent communication protocol; Context Layer defines which private context the task may receive.

storage & content addressing#

local databases, encrypted object stores, & content-addressed systems can hold vault or receipt data. IPFS can provide verifiable content identifiers & portable references, but public IPFS differs from private storage: unencrypted content & provider metadata can be exposed. raw private vault material should not be published to a public content-addressed network merely because its address is a hash.

models, agents, & voice systems#

local models, cloud models, codex-style coding agents, goose-style local agents, workflow engines, & custom runtimes can consume scoped bundles. the current project also includes a local demonstration that creates an OpenAI Realtime WebRTC session for a voice walkthrough. that demo illustrates a user interface; it does not read from or write to a production vault.

payment & metering#

payment protocols such as x402 can be used by an application to require payment for a service or agent action. a Context Layer request could carry a payment requirement or receipt reference, but payment authorization is separate from permission to disclose private context. paying for an operation must never imply blanket access to the vault.

'works with' in this proposal means there is a coherent adapter mapping. it does not mean the current static demonstrator ships production adapters for every system listed above.

what the Context Layer differs from#

clear boundaries are more useful than ambitious labels. the Context Layer differs from:

a replacement for HTTP, TLS, Matrix, ActivityPub, AT Protocol, Nostr, MCP, A2A, or IPFS
a universal identity provider or a new authentication standard
a particular graph database, vector database, model, or cloud vendor
a promise that semantic redaction is infallible
a way to bypass the source system's terms, permissions, or access controls
a guarantee that a signed receipt describes a correct or safe action
a license for autonomous agents to write permanent memory
a production implementation in its current repository form

it is a contract for context objects, decisions, bundles, & evidence at the boundary between private memory & external computation.

design principles#

the proposal can be judged by a small set of principles:

useful without total access. a task should receive enough context to succeed without receiving unrelated private material.
provenance survives transformation. summaries & claims remain traceable to evidence, even after compression.
purpose is part of authorization. who, what, why, how long, & which action are evaluated together.
disclosure is reducible. policy can narrow a request rather than only allow or deny everything.
discovery reveals the minimum. matching happens inside the private boundary whenever possible.
writes are proposals first. generated observations do not silently become durable truth.
sensitive operations leave evidence. receipts are portable, readable, & append-only at the logical level.
interfaces show authority state. users can see provenance, permissions, expiry, & pending approvals where decisions happen.
protocols compose. Context Layer adapters preserve the native semantics & security model of the system they connect.
failure closes the gate. missing identity, ambiguous purpose, expired policy, invalid signatures, & unavailable receipt storage do not produce broader access.

what exists today#

the current project contains:

a public editorial explanation of the problem & proposed layer
a deterministic synthetic request-to-receipt walkthrough
a progressive architecture explorer that presents one layer at a time
a machine-readable navigation manifest & AI-oriented index
an optional server-side guide restricted to same-page protocol navigation

these artifacts prove that the concepts can be explained & reviewed as one flow. they do not yet prove production security, interoperability, durable storage, cryptographic receipts, policy correctness, or real adapter behavior.

the next implementation milestone should be intentionally smaller than the diagram: define & validate the core objects [ContextRequest, PolicyDecision, ScopedContextBundle, & Receipt], implement one local vault, connect one real source adapter & one agent consumer, then prove that raw vault data cannot cross the boundary in conformance tests.

the practical test#

every context-driven interaction should be able to answer three questions:

what context is involved?
who gets to use it, for what purpose, & for how long?
what receipt proves the decision & resulting operation?

if an AI product cannot answer those questions, it does not yet have a context architecture. it has data access.

the Context Layer is an attempt to make the better architecture portable.