Private AI memory / v1.5 deployed / Brisbane

Give every approved AI client
the right context.

Cloud Memory keeps decisions, active projects and hand-offs in one private record. The next chat can continue the work without receiving the whole archive.

v1.5
Deployed and live
5
Approved client paths
Setup
First Agent Rule pending
An abstract network of memory cards, archive folders and semantic connections
Context mapRecall · Projects · Directives · Hand-offs

01 / The purpose

AI should not forget the work when a chat ends.

Without a shared record, decisions drift, tasks lose their source and each new chat repeats old questions. Cloud Memory keeps the useful history together, short enough to use and under the owner's control.

Architecture

One protected record serves five approved clients.

D1 is the canonical record. Search, exports and readable notes are derived from it and cannot silently become a second source of truth.

01

Project Boot Packs

Versioned onboarding ties a project to its repository, Agent Rules, routed directives, eligible tasks and verification checklist—without copying source files, prompts or credentials.

02

Directive routing

Owner-classified directives are selected by project, task type and client. Required safety instructions cannot be filtered out or silently rewritten.

03

Compact responses

Bring back only what matters. Deterministic, non-billing token estimates measure the real tool definition, request, transport, response and selected-context components.

04

Agent Recipes

Reusable, versioned recipes can be selected explicitly. They are inert templates: never scheduled, executed or automatically loaded.

05

Portable Context Repository

An explicit, read-only export produces deterministic JSON and Markdown with safe paths, byte counts and digests. Its content-free manifest is assembled last.

06

Owner-reviewed proposals

An agent can propose a bounded change to a rule, map, Boot Pack or directive. Owner review is the write boundary; nothing applies on model authority.

07

Usefulness signals

Bounded signals record used, ignored, missing or later manually searched outcomes without prompts, queries or responses. Automatic loading remains disabled; any future enablement requires readiness gates and explicit owner opt-in.

08

Safe lifecycle and deletion

Tasks keep optimistic versions, idempotent retries and content-free evidence. Archived tasks and empty projects can be permanently deleted only after archive and guarded owner confirmation.

Core serviceDeployed / live

Owner setupFirst Rule pending

Context changesOwner acceptance

Automatic loadingDisabled

One-call task lifecycle

Boot. Refresh. Close out.

The deployed lifecycle uses an explicit one-call boot and closeout, an 800–1,200-token compact boot design and a sub-300-token routine closeout target.

  1. 01

    One call starts the work

    A task boot validates one task, starts one run and returns routed directives, project state, blockers, verification criteria and compact context. Zero or multiple valid choices stop for selection.

    Task boot
  2. 02

    Delta refresh brings back only changes

    Delta refresh uses the prior context version inside the same boot contract. Required safety or blocker information is never dropped to fit a budget.

    Delta refresh
  3. 03

    One call leaves the hand-off

    Closeout records done, review or blocked, one content-free evidence receipt and at most three concise, non-secret captures. Stable correlation IDs make a retry safe.

    Task closeout

Designed for the owner

See the work, its source and the decisions waiting for you.

The private dashboard keeps project health, tasks, proposals, Recipes and evidence reviewable on desktop and mobile. None of that private data appears here.

CM
PROJECT STATUSWork, with receipts.
REVIEW QUEUE
ACTIVEProject Atlas4 outstanding
Outstanding4In progress2Needs review1Complete7
IN PROGRESSVerify the mobile workflowCOMPLETEARCHIVE
REVIEWAccept the proposed directive changeREVIEWREJECT

Illustrative interface with fictional project data. No private Cloud Memory records are published on this site.

Five-client support

Shared context, with capability kept honest.

Connection alone is not readiness. Each client must refresh its catalogue and prove the actions its plan and approval model allow.

ClientSupported modeWrite boundary
CodexFull read/writeScoped tools and owner-approved work
Claude CodeFull read/writeScoped tools and owner-approved work
OpenCodeFull read/writeScoped tools and owner-approved work
Claude WebRead/writeApproval for write and delete actions
ChatGPT ProRead-onlyPlan-limited; no boot, closeout, proposals or usefulness writes

Safety, monitoring and rollback

A memory system has to fail visibly.

Source, migration, service health, client readiness, projection delivery and public-site status are separate gates. One cannot stand in as proof of another.

Archive and restore

Reversible means reversible

Archive is reversible. Restore returns archived work to active use through its supported owner path.

Permanent deletion

Irreversible means irreversible

A task or empty project can be permanently deleted only after archive and guarded confirmation. Permanent deletion is irreversible for record content; only a scrubbed tombstone remains for replay and audit safety.

Monitoring

Stale work cannot look healthy

Bounded health, migration, client and projection receipts keep failures and drift visible without publishing private records or secret-bearing diagnostics.

Rollback

Code and data recover separately

Worker code can roll back independently. Encrypted recovery and guarded database restore remain distinct, destructive procedures rather than routine tests.

Read-only projection

Obsidian is useful, not authoritative

One managed writer validates exact paths, sizes and digests. The manifest is committed last, so a partial run cannot replace the last complete read-only projection.

Portable by design

Exports do not write back

Portable context exports can be checked by path, size and digest, but they never import, apply, push or change canonical Cloud Memory state.

v1.5 is deployed and live, with one owner setup gate remaining. Authenticated service health, the exact 44-tool catalogue, guarded deletion and replay, deterministic export, projection health and the responsive private interface are verified. The owner account currently has zero Agent Rules, so setup correctly returns a bounded state and task boot returns BOOT_PACK_MISSING without creating a run or loading context. Creating the first Rule and completing the Pack, boot, delta, usefulness and closeout canary remain pending. This page therefore does not claim full rollout or write verification.

Privacy boundary

The records stay private.
The design can be explained.

This page explains the architecture without exposing memories, directives, tasks, project names, operational identifiers, prompts, queries, responses or source conversations.

Authentication
Owner identity and scoped authorisation
Original data
Owner-scoped rows in Cloudflare D1
Derived systems
Rebuildable search, exports and read-only notes
Public surface
Architecture, limits and fictional examples only

Community Edition

Run the public edition in your own accounts.

Community Edition is a separate v1.0 codebase with its own public repository and setup guide. It does not include the private v1.5 features, operating evidence or owner data described on this page.

Cloud Memory · Drew's Digest

Stop restarting the story.
Carry forward only what helps.

Open Drew's Digest ↗

The private workspace and Drew's Digest directory require owner access. This public reference contains architecture, release posture, limits and fictional examples only.