Memory Boundaries: Personal, Shared & Sandbox

Status — Design contract v1 (locked 2026-10-13). The personal and shared layers are available today; the task sandbox and the unified scope metadata are in development. Every claim on this page carries its status — see what is enforced today.

Every memory product has to answer one question precisely: what can an agent write, and where may that data travel? If the answer depends on convention rather than a verifiable contract, the first cross-agent accident is only a matter of time.

Awareness makes the boundary explicit at three layers — personal, shared, and sandbox — with a read/write matrix, a single legal direction for data flow, and fail-closed enforcement points.

The three layers

Layer	What it is	Where it lives	Default visibility	Lifecycle
Personal	Your long-term memory — the core asset	Local `.awareness/{memories,knowledge,...}` (Markdown + SQLite index); cloud `memories` with owner ACL	Only you (+ members you explicitly add)	Permanent (evolves with growth / archive)
Shared	① Team / organization memory ② Public knowledge (KaaS) ③ (future) multi-agent shared board	① Cloud multi-tenant + memory membership ② Published knowledge + organization knowledge policies ③ Planned	Team members / knowledge consumers / authorized agents	Governed by retention policies
Sandbox	Per-task / per-agent-run scratch scope	In development — designed as an isolated per-task store	Only that task / that agent run	TTL after the task ends (default 7 days)

The read/write matrix

Reader \ Data	personal	shared	sandbox
Your session (default)	✅ Read / Write	✅ Read (within authorization) + Write (explicit share only)	✅ Read / Write (your own task)
Sandboxed task agent	✅ Read-only (bounded context)	✅ Read (within authorization)	✅ Read / Write (this task only)
Other agents / external callers	❌ fail-closed	✅ Read (authorized)	❌

The important asymmetry: a sandboxed agent may read your personal memory to do its job — it can never write it.

One legal direction

      promote                    share
sandbox ────────▶ personal ────────────▶ shared
                     ▲                     │
                     └──── consume ────────┘

Sandbox never writes personal automatically. The only path is an explicit promote, carrying provenance (task_id, agent_role, source runtime) and producing an audit event.
Personal never enters shared automatically. Sharing is always an explicit action governed by the existing authorization model (memory membership / organization policies).
Shared can be consumed into personal with an explicit action (for example, importing the result of a knowledge retrieval).

The planned promotion tool is awareness_sandbox_promote — the name deliberately avoids collision with the unrelated card-extraction "promotion" concept.

Fail-closed enforcement

Trigger	Expected behavior
Sandbox context tries to write personal	Rejected with a structured error (including promotion guidance); the attempt is audited
Promotion without provenance	Rejected; the error states which field is missing
Historical data without a `scope` field	Treated as personal; never cleared or lossy-migrated
Concurrent promotions of the same item	Exactly-once (idempotency key / CAS); duplicates return "already promoted"
TTL clock drift / timezone	Storage timestamps in UTC; cleanup is re-entrant and idempotent
Policy change revokes sharing	Existing two-way reconciliation applies — no side channel

These are the acceptance criteria the sandbox implementation must satisfy before it ships.

Status: what is enforced today

Capability	Status	Notes
Personal memory isolation (cloud)	✅ Available	Per-memory owner ACL; nobody else sees it unless explicitly added
Personal memory isolation (local)	✅ Available	Files live on your own disk under `.awareness/`
Explicit team sharing	✅ Available	Memory membership + organization knowledge policies
Public knowledge (KaaS)	✅ Available	Published knowledge with policy-driven retention
Project-level separation	✅ Available	Project workspaces — see the axes table below
Task sandbox layer	🚧 Design-locked, in development	Daemon slice first, then cloud; no shipped-date claims
Unified `scope` metadata	🚧 Design-locked, in development	Follows the sandbox implementation; default `personal` keeps existing installs behavior-identical

We publish this table because an enterprise boundary is only worth what is actually enforced. If you need the sandbox layer for a specific compliance story, contact us — we will tell you precisely where it stands.

Three different axes: scope vs workspace vs agent_role

These three fields are routinely confused. They are orthogonal:

Field	Answers	Values	Example
`scope`	How far may this data travel?	`personal` · `shared` · `sandbox`	A draft insight stays `personal` until explicitly shared
`workspace_id`	Which project does this belong to?	A workspace root	The same personal memory can belong to the `client-x` workspace
`agent_role`	Who wrote this? (provenance, not permission)	A role label (`reviewer`, `external_task`, …)	An agent's event carries `agent_role=reviewer`

One card can simultaneously be scope=personal, workspace_id=client-x, agent_role=reviewer — one owner, one project, one author. None of the three implies the others, and changing one never silently changes another.

What this means for enterprise buyers

Personal memory is private by default. Only you can read the memories in your personal layer — additional members only when explicitly added.
Sharing is always an explicit action. Every item visible to your team was deliberately shared; revocation removes visibility.
Task runs are isolated and auditable — in development. Agent work products land in a sandbox; promotion into your memory requires you (or your policy) to approve, with a full audit trail.

The first two are enforced today. The third is the contract this page specifies — we mark it as in development rather than sell it early.

Roadmap

Slice	Scope	Status
A · Local daemon	`scope` metadata, write guard, recall filter, sandbox store, promotion + audit	Next
B · Cloud	`scope` columns, API filters, sharing semantics, audit events	After backend stabilization
C · Documentation	This page	✅ Published

Contact

Enterprise evaluation, DPA, or self-hosted deployment: everest9812@gmail.com