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
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.
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.
Directive routing
Owner-classified directives are selected by project, task type and client. Required safety instructions cannot be filtered out or silently rewritten.
Compact responses
Bring back only what matters. Deterministic, non-billing token estimates measure the real tool definition, request, transport, response and selected-context components.
Agent Recipes
Reusable, versioned recipes can be selected explicitly. They are inert templates: never scheduled, executed or automatically loaded.
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.
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.
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.
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.
- 01Task boot
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.
- 02Delta refresh
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.
- 03Task closeout
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.
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.
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.
| Client | Supported mode | Write boundary |
|---|---|---|
| Codex | Full read/write | Scoped tools and owner-approved work |
| Claude Code | Full read/write | Scoped tools and owner-approved work |
| OpenCode | Full read/write | Scoped tools and owner-approved work |
| Claude Web | Read/write | Approval for write and delete actions |
| ChatGPT Pro | Read-only | Plan-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.
Reversible means reversible
Archive is reversible. Restore returns archived work to active use through its supported owner path.
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.
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.
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.
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.
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.
The private workspace and Drew's Digest directory require owner access. This public reference contains architecture, release posture, limits and fictional examples only.